Repository navigation
Group FileMaker rolodex fields by topic, most important first - #2665
Merged
Merged
Conversation
maebeale
marked this pull request as ready for review
October 13, 2026 02:12
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>
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
force-pushed
the
maebeale/fm-rolodex-fields-rearrange
branch
from
October 13, 2026 13:43
a3921fa to
346d779
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 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.
RolodexIDnames the person. Primary/worksite come first, tagged beside the linked FileMaker ID; thePrimary*IDfields aren't repeated as rows. Address lines prepend FileMaker's separateStreetNounless the street line already starts with it.PORTAL_COUNTERPARTS) are orange and name their counterpart, here and in the field reference's "Records pointing here" list.zc*/zg*/zs*calc fields and any undocumented columns land here, so nothing is hidden.people; phones and addresses mirrorContactMethod/Address.PORTAL_FIELDS, e.g. FirstName → people.first_name) are orange, with the column on hover.FIELD_GROUPS. Tables without it render as before, as one unlabeled list.FmRolodexheader comment is grouped exactly once.🤖 Generated with Claude Code