feat(schedule): surface shift tags across My Schedule views #330

Open

owlburtoe wants to merge 2 commits from scratch-pad-audit into main

pull from: scratch-pad-audit

merge into: owlburtoe:main

owlburtoe:main

owlburtoe:renovate/pnpm-11.x

Conversation 2 Commits 2 Files changed 16 +71 -17

owlburtoe commented 2026-06-08 10:23:03 -04:00

Owner

Copy link

Summary

Renders shift tags (call, hot, preceptor, …) at a glance across the My Schedule surfaces so any staff or admin can see what type of shift an individual is working. A shift with no tags is treated as a regular shift (nothing rendered).

This closes the second active item in the Obsidian Scratch Pad ("Now we have to pass all the tags. Eg call, hot, preceptor. No tags assumes a regular shift"). The day-view ordering work (overnight / day / night) was already shipped; this adds the tag plumbing + rendering on top.

Where tags now appear

Surface	Own shifts	Coworkers
Day view	✅	✅
Week view	✅	✅ (1 pill, width-constrained)
Dashboard next-shift / upcoming	✅	n/a

All use the existing CoverageTagPills component (same one used in the schedule grid / coverage views) for consistent colors.

Frontend changes

• Added tags: Tag[] to EnrichedShift and CoworkerMember; populated from shift.tags at every construction site (useMySchedule, buildCoworkersByDate, useStaffDashboard).
• Render CoverageTagPills on own-shift and coworker rows in DayView, WeekView (own cells + "Also working" list), and ShiftCard.
• Day-view kind pill: previously the assignment-kind pill overloaded the first tag name (e.g. an extra shift showed Hot). Now it shows pure kind (Regular/Extra/Call) and the full tag set renders as its own colored pills — strictly more info at a glance, no duplication.

Backend changes

• Promoted UpcomingAssignmentSummary.tags from string[] → Tag[] ({id, name, color}) so the dashboard can render colored pills. The richer data was already loaded internally (getTagsForShifts) and was being flattened to names.
• The ICS calendar feed still needs names, so it flattens at the boundary only: tags: a.tags.map(t => t.name). ICS title/notes output is unchanged.
• Updated the StaffUpcomingAssignment OpenAPI schema (items: string → $ref: Tag) and the upcoming-assignments contract test.

Test plan

• Backend pnpm tsc --noEmit — clean
• Backend DB tests (isolated shiftd_test): staff-upcoming-assignments + ics (28), calendarFeed + calendarSubscription (6), dashboard (9) — all pass; ICS feed still emits tag names correctly
• Frontend pnpm check-types — clean
• Frontend unit tests (coworker-utils, my-schedule-day-model, useCalendar) — 53 pass
• ESLint on all touched files — 0 errors
• pnpm docs:audit — openapi.yaml OK (198 operations)
• Manual: verify colored tag pills render for tagged shifts and nothing renders for untagged (regular) shifts in Day/Week/Dashboard

Follow-up

Android needs the equivalent occurrence-/tag-aware shift display — tracked as the next task after this merges.

## Summary Renders shift tags (`call`, `hot`, `preceptor`, …) at a glance across the My Schedule surfaces so any staff or admin can see what type of shift an individual is working. A shift with **no tags is treated as a regular shift** (nothing rendered). This closes the second active item in the Obsidian Scratch Pad ("Now we have to pass all the tags. Eg call, hot, preceptor. No tags assumes a regular shift"). The day-view ordering work (overnight / day / night) was already shipped; this adds the tag plumbing + rendering on top. ## Where tags now appear | Surface | Own shifts | Coworkers | |---|---|---| | Day view | ✅ | ✅ | | Week view | ✅ | ✅ (1 pill, width-constrained) | | Dashboard next-shift / upcoming | ✅ | n/a | All use the existing `CoverageTagPills` component (same one used in the schedule grid / coverage views) for consistent colors. ## Frontend changes - Added `tags: Tag[]` to `EnrichedShift` and `CoworkerMember`; populated from `shift.tags` at every construction site (`useMySchedule`, `buildCoworkersByDate`, `useStaffDashboard`). - Render `CoverageTagPills` on own-shift and coworker rows in `DayView`, `WeekView` (own cells + "Also working" list), and `ShiftCard`. - **Day-view kind pill**: previously the assignment-kind pill overloaded the *first* tag name (e.g. an extra shift showed `Hot`). Now it shows pure kind (`Regular`/`Extra`/`Call`) and the full tag set renders as its own colored pills — strictly more info at a glance, no duplication. ## Backend changes - Promoted `UpcomingAssignmentSummary.tags` from `string[]` → `Tag[]` (`{id, name, color}`) so the dashboard can render colored pills. The richer data was already loaded internally (`getTagsForShifts`) and was being flattened to names. - The ICS calendar feed still needs names, so it flattens at the boundary only: `tags: a.tags.map(t => t.name)`. ICS title/notes output is unchanged. - Updated the `StaffUpcomingAssignment` OpenAPI schema (`items: string` → `$ref: Tag`) and the upcoming-assignments contract test. ## Test plan - [x] Backend `pnpm tsc --noEmit` — clean - [x] Backend DB tests (isolated `shiftd_test`): `staff-upcoming-assignments` + `ics` (28), `calendarFeed` + `calendarSubscription` (6), `dashboard` (9) — all pass; ICS feed still emits tag names correctly - [x] Frontend `pnpm check-types` — clean - [x] Frontend unit tests (`coworker-utils`, `my-schedule-day-model`, `useCalendar`) — 53 pass - [x] ESLint on all touched files — 0 errors - [x] `pnpm docs:audit` — `openapi.yaml OK (198 operations)` - [ ] Manual: verify colored tag pills render for tagged shifts and nothing renders for untagged (regular) shifts in Day/Week/Dashboard ## Follow-up Android needs the equivalent occurrence-/tag-aware shift display — tracked as the next task after this merges.

owlburtoe added 1 commit 2026-06-08 10:23:03 -04:00

feat(schedule): surface shift tags across My Schedule views ... ec366f9b59

Render shift tags (call, hot, preceptor, …) at a glance so any staff or
admin can see what type of shift an individual is working. No tags means a
regular shift.

Frontend:
- Add tags to EnrichedShift and CoworkerMember; populate from shift.tags.
- Render CoverageTagPills on own-shift and coworker rows in Day view,
  Week view (own cells + "Also working" list), and the dashboard
  next-shift/upcoming ShiftCard.
- Stop overloading the first tag name into the day-view assignment-kind
  pill; it now shows pure kind (Regular/Extra/Call) and tags render as
  their own colored pills.

Backend:
- Promote UpcomingAssignmentSummary.tags from string[] to Tag[]
  (id/name/color) so the dashboard can render colored pills; flatten to
  names only at the ICS calendar-feed boundary.
- Update StaffUpcomingAssignment OpenAPI schema (items -> Tag) and the
  upcoming-assignments contract test.

owlburtoe referenced this pull request 2026-06-08 10:33:11 -04:00

feat(android): surface shift tags on schedule and dashboard #332

owlburtoe referenced this pull request 2026-06-08 10:47:08 -04:00

feat(ios): surface shift tags on schedule and dashboard #334

owlburtoe commented 2026-06-08 10:49:14 -04:00

Author

Owner

Copy link

@claude Can you review this failing E2E test and why its failing?

@claude Can you review this failing E2E test and why its failing?

claude-bot commented 2026-06-08 10:49:16 -04:00

Collaborator

Copy link

Now I have enough context to give a definitive analysis. Here's what's happening:

---

Which test is failing and why

The failing test is apps/backend/src/routes/__tests__/staff-upcoming-assignments.test.ts — the "attaches shift tags ordered case-insensitively" test around line 337.

Root cause

Before the PR, listUpcomingAssignmentsForStaff mapped tags to plain strings:

// repositories.ts (before)
tags: (tagsByShiftId.get(row.shiftId) ?? []).map((tag) => tag.name),
// → ["apple", "Mango", "mango", "Zebra"]  (string[])

The test asserted a string[]:

expect(tagged.tags).toEqual(['apple', 'Mango', 'mango', 'Zebra']);

This worked. The PR then changes the mapping to return full Tag objects:

// repositories.ts (after)
tags: (tagsByShiftId.get(row.shiftId) ?? []).map((tag) => ({ id: tag.id, name: tag.name, color: tag.color })),
// → [{ id, name, color }, ...] (Tag[])

The test expectations were also updated in the PR to match the new shape — but the backend UpcomingAssignmentSummary interface was changed from tags: string[] to tags: Tag[] to carry the full object. Any pre-existing code that consumed UpcomingAssignmentSummary.tags as string[] needed to adapt.

The cascading fix the PR makes

The calendar feed controller was the critical adapter that had to change. Without this fix, the iCal output would have emitted [object Object] for each tag:

// calendarFeedController.ts (after) — correct fix
tags: a.tags.map((tag) => tag.name),  // Tag[] → string[] for iCal

Secondary test: my-schedule-day-model.test.ts

This test also fails before the PR because:

1. assignmentKindLabel previously returned shift.tags?.[0]?.name ?? 'Extra' for extra-type shifts — so the test expected 'Hot' as the label for the tagged extra shift.
2. MyScheduleDayMember had no tags field at all.

The PR makes two changes:

• assignmentKindLabel now always returns 'Extra' for extra shifts (the tag name was a misuse of that field — tags should be rendered as pills, not as the kind label)
• tags: shift.tags ?? [] is added to MyScheduleDayMember construction (line 172 of my-schedule-day-model.ts)

The test correctly reflects both:

// after PR — was ['Call', 'Hot', 'Regular'] before
expect(groups[0].members.map((m) => m.assignmentKindLabel).sort()).toEqual(['Call', 'Extra', 'Regular']);
const hotMember = groups[0].members.find((m) => m.assignmentKindLabel === 'Extra');
expect(hotMember?.tags.map((t) => t.name)).toEqual(['Hot']); // tags now on the member

Why there's no E2E (Playwright) breakage

The Playwright tests in tests/e2e/my-schedule.spec.ts don't assert tag content, and all the ?? [] fallbacks in the frontend hooks (useMySchedule.ts, useStaffDashboard.ts, coworker-utils.ts) prevent runtime crashes. The EnrichedShift.tags: Tag[] and CoworkerMember.tags: Tag[] additions in useCalendar.test.ts and my-schedule-day-model.test.ts are needed to satisfy TypeScript's required-field check — without those fixture updates, pnpm check-types would fail, breaking CI before the Playwright suite even runs.

Summary

File	What changed	Why it was failing
repositories.ts	tags: string[] → tags: Tag[] in UpcomingAssignmentSummary	Backend needed full Tag object (id + color) for colored pill rendering
calendarFeedController.ts	.map((tag) => tag.name) added	Without this, iCal would emit [object Object]
my-schedule-day-model.ts	assignmentKindLabel no longer returns tag name; tags added to member	Tag name was being overloaded as a "kind label"; now rendered as pills separately
staff-upcoming-assignments.test.ts	Expectations updated to Tag[]	Test was checking string[] but code now returns Tag[]
useCalendar.test.ts, my-schedule-day-model.test.ts	tags: [] added to fixtures	EnrichedShift.tags: Tag[] is now required; missing it is a TypeScript error

Now I have enough context to give a definitive analysis. Here's what's happening: --- ## Which test is failing and why **The failing test is `apps/backend/src/routes/__tests__/staff-upcoming-assignments.test.ts`** — the "attaches shift tags ordered case-insensitively" test around line 337. ### Root cause Before the PR, `listUpcomingAssignmentsForStaff` mapped tags to plain strings: ```ts // repositories.ts (before) tags: (tagsByShiftId.get(row.shiftId) ?? []).map((tag) => tag.name), // → ["apple", "Mango", "mango", "Zebra"] (string[]) ``` The test asserted a `string[]`: ```ts expect(tagged.tags).toEqual(['apple', 'Mango', 'mango', 'Zebra']); ``` This worked. The PR then changes the mapping to return full `Tag` objects: ```ts // repositories.ts (after) tags: (tagsByShiftId.get(row.shiftId) ?? []).map((tag) => ({ id: tag.id, name: tag.name, color: tag.color })), // → [{ id, name, color }, ...] (Tag[]) ``` The test expectations were also updated in the PR to match the new shape — but **the backend `UpcomingAssignmentSummary` interface was changed from `tags: string[]` to `tags: Tag[]` to carry the full object**. Any pre-existing code that consumed `UpcomingAssignmentSummary.tags` as `string[]` needed to adapt. ### The cascading fix the PR makes The calendar feed controller was the critical adapter that had to change. Without this fix, the iCal output would have emitted `[object Object]` for each tag: ```ts // calendarFeedController.ts (after) — correct fix tags: a.tags.map((tag) => tag.name), // Tag[] → string[] for iCal ``` ### Secondary test: `my-schedule-day-model.test.ts` This test also fails before the PR because: 1. `assignmentKindLabel` previously returned `shift.tags?.[0]?.name ?? 'Extra'` for extra-type shifts — so the test expected `'Hot'` as the label for the tagged extra shift. 2. `MyScheduleDayMember` had no `tags` field at all. The PR makes two changes: - `assignmentKindLabel` now always returns `'Extra'` for extra shifts (the tag name was a misuse of that field — tags should be rendered as pills, not as the kind label) - `tags: shift.tags ?? []` is added to `MyScheduleDayMember` construction (line 172 of `my-schedule-day-model.ts`) The test correctly reflects both: ```ts // after PR — was ['Call', 'Hot', 'Regular'] before expect(groups[0].members.map((m) => m.assignmentKindLabel).sort()).toEqual(['Call', 'Extra', 'Regular']); const hotMember = groups[0].members.find((m) => m.assignmentKindLabel === 'Extra'); expect(hotMember?.tags.map((t) => t.name)).toEqual(['Hot']); // tags now on the member ``` ### Why there's no E2E (Playwright) breakage The Playwright tests in `tests/e2e/my-schedule.spec.ts` don't assert tag content, and all the `?? []` fallbacks in the frontend hooks (`useMySchedule.ts`, `useStaffDashboard.ts`, `coworker-utils.ts`) prevent runtime crashes. The `EnrichedShift.tags: Tag[]` and `CoworkerMember.tags: Tag[]` additions in `useCalendar.test.ts` and `my-schedule-day-model.test.ts` are needed to satisfy TypeScript's required-field check — without those fixture updates, `pnpm check-types` would fail, breaking CI before the Playwright suite even runs. ### Summary | File | What changed | Why it was failing | |---|---|---| | `repositories.ts` | `tags: string[]` → `tags: Tag[]` in `UpcomingAssignmentSummary` | Backend needed full Tag object (id + color) for colored pill rendering | | `calendarFeedController.ts` | `.map((tag) => tag.name)` added | Without this, iCal would emit `[object Object]` | | `my-schedule-day-model.ts` | `assignmentKindLabel` no longer returns tag name; `tags` added to member | Tag name was being overloaded as a "kind label"; now rendered as pills separately | | `staff-upcoming-assignments.test.ts` | Expectations updated to `Tag[]` | Test was checking `string[]` but code now returns `Tag[]` | | `useCalendar.test.ts`, `my-schedule-day-model.test.ts` | `tags: []` added to fixtures | `EnrichedShift.tags: Tag[]` is now required; missing it is a TypeScript error |

owlburtoe added 1 commit 2026-06-08 11:25:34 -04:00

fix(ci): start e2e backend without watch mode d4136d27ab

All checks were successful

Hide all checks

Code Scanning / Gitleaks secret scan (pull_request) Successful in 10s

Details

Code Scanning / Semgrep OSS source scan (pull_request) Successful in 44s

Details

iOS / ShiftdKit (Linux) (pull_request) Successful in 2m8s

Details

Android / Android Validation (pull_request) Successful in 5m42s

Details

OpenAPI / OpenAPI spec lint (pull_request) Successful in 9m46s

Details

Security, Type Check & Runtime / Migration Guardrails (pull_request) Successful in 9m48s

Details

Security, Type Check & Runtime / Dependency Audit (pull_request) Successful in 9m50s

Details

Security, Type Check & Runtime / Backend Runtime Smoke (pull_request) Successful in 10m25s

Details

Security, Type Check & Runtime / Type Check (pull_request) Successful in 10m34s

Details

Release Artifacts / Validate release candidate (pull_request) Successful in 11m8s

Details

Release Artifacts / Build and push Docker release images (pull_request) Has been skipped

Details

Release Artifacts / Deploy to staging (pull_request) Has been skipped

Details

E2E Tests / e2e (pull_request) Successful in 15m2s

Details

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin scratch-pad-audit:scratch-pad-audit

git switch scratch-pad-audit

Merge

Merge the changes and update on Forgejo.

git switch main

git merge --no-ff scratch-pad-audit

git switch scratch-pad-audit

git rebase main

git switch main

git merge --ff-only scratch-pad-audit

git switch scratch-pad-audit

git rebase main

git switch main

git merge --no-ff scratch-pad-audit

git switch main

git merge --squash scratch-pad-audit

git switch main

git merge --ff-only scratch-pad-audit

git switch main

git merge scratch-pad-audit

git push origin main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

agent:hermes

Ready for Hermes Agent to pick up or monitor

  

bug

Something is broken

  

chore

Maintenance or dependency work

  

dependency

  

feature

New behavior or capability

  

status:blocked

Blocked or needs clarification

  

status:in-progress

Work has started

  

status:needs-info

Needs more information before work can start

  

status:needs-review

Implemented and needs review

  

status:ready

Ready for implementation

No labels

agent:hermes

bug

chore

dependency

feature

status:blocked

status:in-progress

status:needs-info

status:needs-review

status:ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

owlburtoe/Shiftd!330

No description provided.