Skip to content

WAIT: Show combined primary + additional sectors on the recipients header#1837

Open
maebeale wants to merge 1 commit into
mainfrom
maebeale/recipients-sector-header
Open

WAIT: Show combined primary + additional sectors on the recipients header#1837
maebeale wants to merge 1 commit into
mainfrom
maebeale/recipients-sector-header

Conversation

@maebeale

Copy link
Copy Markdown
Collaborator

🤖 PR, suggested 👤 review level: 📖 Read — light-logic: a new dashboard read method + a view swap; no writes, no migration

Why

The recipients "Serves" strip read only the additional-sector answer (under a single normalized sector key), so a registrant's primary sector and their additional sectors weren't shown together.

What

  • EventDashboard#header_sectors_for(person) — combines the single-select primary and multi-select additional sector answers for the event, uniqued, primary first. Read straight from the form answers (so it's independent of the registration-derived is_primary profile tags, which legacy data marks all-primary), falling back to the person's profile sector tags when no sector answers are on file.
  • Recipients header renders them as chips with the primary starred, then the additional sectors alphabetically.
  • Dropped the now-unused HEADER_SECTOR_KEY / header_answer_key; HEADER_ANSWER_IDENTIFIERS is now age-group-only.

Verification

  • event_dashboard_spec (new #header_sectors_for cases incl. legacy identifiers + profile fallback) and events_spec green; rubocop clean.
  • Against seeded data the recipients header renders e.g. ★Disability Services, Fundraising/Donor Engagement — primary starred, additional following, uniqued.

The recipients "Serves" strip read only the additional-sector answer (and a
single normalized "sector" key), so a registrant's primary sector and the rest
of their additional sectors weren't shown together. EventDashboard now exposes
#header_sectors_for, which combines the single-select primary and multi-select
additional sector answers for the event — uniqued, primary first — read from
the form answers themselves (independent of the registration-derived is_primary
profile tags, which legacy data marks all-primary), falling back to profile
tags when no sector answers are on file. The header renders them as chips with
the primary starred, then the additional sectors alphabetically.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# named no sectors on a form.
def header_sectors_for(person)
ids = header_sector_ids_by_applicant[person.id]
return profile_sector_pairs(person) unless ids && (ids[:primary].any? || ids[:additional].any?)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 From Claude: Form answers are the authority here, not the profile is_primary tags — legacy/prod registrations were tagged all-primary by the old assign_tags, so reading tags would star every sector. Profile tags are only the fallback when the registrant named no sectors on a form.

@maebeale maebeale marked this pull request as ready for review June 22, 2026 06:31
@maebeale maebeale changed the title Show combined primary + additional sectors on the recipients header WAIT: Show combined primary + additional sectors on the recipients header Jun 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant