Bug #477
closed"Studies on the Board" Count on Schedule Page Does Not Update When Date Changes
0%
Description
Summary
On the Schedule page, the "N studies on the board" count shown under the page title does not update when the selected date is changed. It stays frozen at the count from the date that was loaded when the page first opened, even though the resource schedule grid and the Modality Utilisation figure below it both update correctly for the new date.
Impact
Medium severity. Staff glancing at the page summary to gauge how busy a given day is will see a stale, incorrect number once they've navigated away from the initially loaded date — for example the board can show 0 actual bookings for a date while the header still claims 2. This is misleading at a glance and could cause staff to misjudge a day's schedule load without checking the grid itself.
Environment
Clinq HMS demo environment, NSS Hospital (nssh.demo.clinq.health), Schedule page, CT modality, CT Scanner 01. Tested 20 October 2026.
Steps to Reproduce
- Go to Radiology > Schedule, with modality set to CT and date on Today (20/10/2026). Note the "N studies on the board" count at the top (2, matching the 2 bookings visible on the CT Scanner 01 grid: RAD-ORD-1-9 and RAD-ORD-1-8).
- Click the next-day arrow to move to 21/10/2026, then again to 22/10/2026.
- Compare the "N studies on the board" count against the actual bookings shown on the resource grid and the Modality Utilisation figure for that date.
Expected vs Actual
Expected: the "N studies on the board" count reflects the currently selected date, matching the number of bookings actually shown on the resource grid for that date.
Actual: the count stayed at "2 studies on the board" after navigating to both 21/10/2026 and 22/10/2026, even though the resource grid for both of those dates was completely empty (0 bookings, confirmed by "0/480 min · 0%" under Modality Utilisation). Navigating back to Today correctly showed "2 studies on the board" again, matching its 2 real bookings — so the header is only ever correct for whichever date first loaded the page, and goes stale on every date change after that.
Files
AV Updated by Alminta V. 23 days ago
- Status changed from New to Resolved
- Resolved By set to Alminta V.
S- Updated by SK - 12 days ago
- Assignee changed from Alminta V. to Roshni Harish.
- Resolved By changed from Alminta V. to SK -
Verified #477's fix (commit d90daed5, already on dev) against the live code - genuinely correct: the header count now reads from timeline (the one load() result actually scoped to the selected date), not the branch-wide queue/scheduled lists that never changed with the date. Confirmed with the existing regression tests.
While verifying, found and fixed a related gap the original fix left behind (same bug class, different trigger, commit 0a20c64a): the header was reading from the unfiltered timeline, while the resource grid it's supposed to describe renders filteredTimeline (narrowed by the "Machine" dropdown) - so picking a specific machine among several of the same modality left the header still counting every machine's bookings. Fixed by reading the count from filteredTimeline instead, added a regression test (confirmed red without the fix, green with it).
Full portal suite + typecheck pass on the merged dev tip. QA change-log updated. Assigning to Roshni for QA sign-off - worth re-checking both the original date-change scenario and the machine-filter scenario on the test box.
RH Updated by Roshni Harish. 9 days ago
- Status changed from Resolved to Closed