Skip to content

Group FileMaker rolodex fields by topic, most important first - #2665

Merged
maebeale merged 36 commits into
mainfrom
maebeale/fm-rolodex-fields-rearrange
Oct 13, 2026
Merged

maebeale merged 36 commits into
mainfrom
maebeale/fm-rolodex-fields-rearrange

Conversation

@maebeale

@maebeale maebeale commented Oct 13, 2026 •

Copy link
Copy Markdown
Collaborator

🤖 suggested review level: 3 Read 📖 display-only grouping, phone/address lookups and a field reference; the field-to-group mapping is a judgment call

A FileMaker rolodex record listed ~90 fields in raw import order. It now shows them in labeled sections, most useful first, so admins can make sense of a record at a glance.

  • Layout: cards sit two to a row on wide screens: Identity | Phones & addresses; Organization & affiliations (two rows tall) beside Sector & age group stacked on Record keeping; then Notes, Volunteering, Giving, Personal details, Mailing, Other fields.
  • Subcards: a card can split into titled subcards (a one-field subcard renders as a single row). Phones & addresses → Phones, Addresses, Mailing list. Organization & affiliations → Classification & status, Organization, Job affiliation, Facilitator affiliation (mirroring the portal's org and affiliation records). Job and Facilitator affiliation list the person's People-to-organizations and Personnel rows (title/role, program at organization, statuses).
  • Paired cards match: cards in a row stretch to the same height.
  • All phones and addresses listed: each subcard lists every phone/address whose RolodexID names the person. Primary/worksite come first, tagged beside the linked FileMaker ID; the Primary*ID fields aren't repeated as rows. Address lines prepend FileMaker's separate StreetNo unless the street line already starts with it.
  • Dead IDs (every archive table): any linked ID with no archive record is struck through (hover: "No FM record found"). A missing primary phone/address shows in its list as "Not found in FM data".
  • Related records: laid out in up to three columns. Tables the portal keeps its own records of (addresses, contact methods, comments, communications, affiliations, workshop logs, workshops, event registrations, payments, scholarships (FileMaker funding tied to a person), invoices, quotes — PORTAL_COUNTERPARTS) are orange and name their counterpart, here and in the field reference's "Records pointing here" list.
  • "In the portal" links are now full-size solid blue buttons.
  • Other fields: FileMaker's zc*/zg*/zs* calc fields and any undocumented columns land here, so nothing is hidden.
  • Blank fields hidden in cards: the blue field reference at the bottom still lists every field, grayed when blank, plus the tables linked in each direction.
  • Grouped to match the portal: email and best time to call sit in Identity, as they live on people; phones and addresses mirror ContactMethod/Address.
  • Importable fields: in the field reference, fields that copy straight into a portal column (PORTAL_FIELDS, e.g. FirstName → people.first_name) are orange, with the column on hover.
  • Opt-in for other tables: a table opts in by defining FIELD_GROUPS. Tables without it render as before, as one unlabeled list.
  • Coverage check: a spec asserts every field documented in the FmRolodex header comment is grouped exactly once.

🤖 Generated with Claude Code

@maebeale maebeale changed the title Group FileMaker rolodex fields by meaning Group FileMaker rolodex fields by topic, most important first Oct 13, 2026
@maebeale
maebeale marked this pull request as ready for review October 13, 2026 02:12
maebeale and others added 28 commits October 13, 2026 09:42
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The archive page listed ~90 rolodex fields in raw import order, so
names, contact details and facilitator history were scattered among
calc fields and login columns.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Classification and status describe someone's facilitator standing, and
the delete/duplicate flags describe the record, so they read better
beside those fields than beside a name.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Name beside contact and organization beside facilitator puts the
details admins look up together in one glance.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The rolodex row only points at the primary phone and address, so other
numbers and addresses were reachable only as bare IDs in related records.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Admins reading an archive record couldn't tell which fields exist but
are blank, or which other tables link to a person.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
They describe who someone serves, which is looked up on its own, not as
part of their facilitator history.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Email is how admins tell people apart; phones and addresses are the
lists they scan to reach someone.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The portal stores it on the person, alongside email, so grouping it
there makes mapping archive fields onto people straightforward.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Most of a rolodex record's ~90 fields are blank, which buried the filled
ones; the reference section keeps the full list so nothing is lost.
FileMaker stores some street numbers apart from the street line.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
So the primary and worksite ID fields above can be matched to the
readable number or address by eye.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A dead reference looked like a working link and led to 'No record
found'. Website moves to the organization, where the portal keeps it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Organization, job and facilitator affiliations are separate records in
the portal, so subcards make the archive map onto them. Primary phone
and address IDs read better beside the record they name, including when
FileMaker has no such record.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The organization card runs tall with its three subcards; stacking
sector and record keeping beside it fills the space.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
It classifies the whole person (donor, facilitator, ...), not their
facilitator affiliation.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Phones and addresses now appear in the cards, so the related-records
list mostly repeats them; highlighting the rest points at what's only
reachable there.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The stacked list ran long; columns keep it to a few rows. The same
yellow marks those tables in the field reference.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contact history, affiliations, workshops, events, money, fundraising
and the rest now sit together instead of in import order.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Those are the ones worth reconciling against portal records, so they
stand apart from tables only the archive holds.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…rparts

Orange alone answers the useful question (does the portal keep its own
records of this kind?), so phones and addresses join it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…else

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A funding row tied to a person is their scholarship request and award.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The portal derives both from a person's affiliations, so they read best
next to them.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…cards

Their organization links lived only as ID chips in related records.
Activities map to portal communications, so portal counterparts are now
named by what the portal UI calls them.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
maebeale and others added 8 commits October 13, 2026 09:43
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Shows at a glance which archive fields could move into the portal as-is,
with the target column on hover.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The FileMaker ID already lives on as the person's filemaker_code, so it
isn't a field to import.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
FileMaker keeps no second email, so nothing feeds email_2.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@maebeale
maebeale force-pushed the maebeale/fm-rolodex-fields-rearrange branch from a3921fa to 346d779 Compare October 13, 2026 13:43
@maebeale
maebeale merged commit 3c13620 into main Oct 13, 2026
3 checks passed
@maebeale
maebeale deleted the maebeale/fm-rolodex-fields-rearrange branch October 13, 2026 14:10
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