[maebeale]

🤖 suggested review level: 5 Inspect 🔬 changes what every registrant location chart and filter counts, plus the search grammar in every filter box

Registrant location charts and filters now use where people work (their registered org's address), falling back to where they live. Along the way, every search box in the portal ends up speaking the same language.

Where a registrant is

• RegistrationLocations is the one source, per registration: org linked on the registration → the address picked on that registration's affiliation → the org's oldest active address → the one address that stands for the registrant
• Address::STANDING — active work → latest-edited active personal → active other → inactive personal → inactive work
  • Work and personal swap below the active line on purpose: a current work address is the sharpest thing we know, a retired one the stalest
  • Written once in Ruby and compiled into the ORDER BY; AddressDecorator sorts its loaded association by the same list
  • Retired addresses count, so nobody falls off the map for having only a stale one
• A row carries every field an address uses to say where it is — city, county, state, country, locality, zip, school district, the three LA districts

Filters

• City/State/County/Country go in together through one located_in(**fields) / matching(**fields), so they describe one address
• Attendees page: the City box becomes a prefixed "Where they work" box (city: austin locality: "Outside CA"), which is also what makes locality / zip / district / LA districts filterable at all
  • A visible dropdown wins over the same field typed in the box
  • A bare city param still works, now as a removable chip
• Attendees filter dropdowns read the address tables directly (two grouped queries) instead of building a row per registration across the whole reportable population

One search grammar

Several words	all have to match (was: either, on the people index)
--	either — now works in every box, including the roster keyword search
"..."	phrase
city: etc.	prefixes, on the contact and work-location boxes

• Every box carries the same help icon, generated from the same constants
• New prefixes: locality:, district:, la_council:, la_supervisorial:, la_spa:, and type: for work/personal/mailing — SearchCop ANDs prefixes onto one joined row, so type: personal city: austin is how you search a personal city alone
• Search reads live addresses only. The standing chain is right for showing someone, wrong for finding them — an admin holding an old address would be told nobody lives there. It also costs a correlated subquery per person where a plain join does now
• Organizations index Address box joins the shared search (keeps its LA district columns as integers; commas become spaces so a pasted "Los Angeles, CA" still reads as two words)
• Person.search_by_params(contact_info:) deleted — every index reaches ContactSearchable from the URL param, so it was a second, older meaning for the same word

Split out of #2842 (org-answer refactor). Label/doc wording follow-up in #2845.

Features seed (optional)

• Added a features seed (optional)

🤖 Generated with Claude Code

[maebeale]

🤖 From Claude: These scopes pluck the current relation's ids and resolve locations in Ruby, so the work-else-home rule lives only in RegistrationLocations. Fine at one event's scale; worth knowing if they get used on a large cross-event relation.

[maebeale]

🤖 From Claude: City, state and county deliberately arrive in one call rather than as chainable scopes: chained, each one independently matched any of the registration's location rows, so a registrant registered under orgs in Portland OR and Seattle WA matched City=Seattle + State=OR (the old shared addresses join ruled that out). A County value whose state contradicts the State filter resolves to none for the same reason.