Behind the Fix: Why Your Work Queue Wasn't Surfacing Overdue Check-Ins
Behind the Fix: Why Your Work Queue Wasn't Surfacing Overdue Check-Ins
Version: v0.1.291
The Problem
If you've been using the Check-In module, you may have noticed that individual check-in cards correctly display a red Overdue badge when a tenancy started 7 or more days ago and no check-in report has been finalised. That visual cue works exactly as intended.
What didn't work was the Work Queue.
Under the hood, the Work Queue's awaitingCheckIn query was pulling every active tenancy with no finalised check-in — but treating them all identically. A tenancy that started yesterday and one that started three weeks ago both appeared at the same urgency level in the queue. The overdue signal visible on the card never made it into the prioritisation layer.
In short: the badge was cosmetic. The work queue was blind to how long an agent had actually been waiting.
Why It Matters
The Work Queue exists to surface the right task at the right time. When overdue check-ins are silently mixed in with brand-new ones, agents have no prompt to act on the oldest cases first. That creates risk:
- Condition disputes become harder to resolve the longer a check-in is delayed.
- Landlords and tenants lose confidence in the process.
- Compliance exposure increases as days without a documented check-in accumulate.
The Fix
1. Router — Compute Days Since Start
A daysSinceStart field is added to every row returned by the awaitingCheckIn query using PostgreSQL's EXTRACT function:
sql<number>`EXTRACT(DAY FROM (CURRENT_DATE - ${tenancies.startDate}::date))`.as('daysSinceStart')
This gives the Work Queue component a precise, database-computed age for each awaiting check-in — no client-side date arithmetic required.
2. Work Queue Component — Two Sub-Sections
With daysSinceStart available, the Work Queue splits awaiting check-ins into two clearly labelled groups:
| Sub-section | Condition | Urgency Variant |
|---|---|---|
| Check-In Overdue | daysSinceStart ≥ 7 | Urgent (red) |
| Awaiting Check-In | daysSinceStart < 7 | Standard |
Overdue items appear first, styled with the urgent red variant — consistent with the badge already shown on the card itself.
Before & After
Before v0.1.291
Work Queue — Awaiting Check-In
────────────────────────────────
• 14 Brunswick Street (started 21 days ago) [standard]
• 9 Maple Avenue (started 2 days ago) [standard]
• 33 Colston Road (started 9 days ago) [standard]
After v0.1.291
Work Queue — Check-In Overdue 🔴
────────────────────────────────
• 14 Brunswick Street (21 days overdue) [urgent]
• 33 Colston Road (9 days overdue) [urgent]
Work Queue — Awaiting Check-In
────────────────────────────────
• 9 Maple Avenue (started 2 days ago) [standard]
Files Affected
| File | Change |
|---|---|
src/lib/routers/dashboard.ts | Add daysSinceStart computed column to awaitingCheckIn query |
| Work Queue component | Split awaiting check-ins into overdue / pending sub-sections with appropriate urgency variants |
No Action Required
This is a backend query and UI component change. There are no configuration options to set, no data migrations required, and no changes to how check-in reports are created or submitted. The Work Queue will automatically reflect the correct prioritisation once the fix is deployed.