First Name, Last Name & Company — How They Sync Across the Platform¶

Audience: Event Operators, Show Admins, Support, QA, Developers Apps/Services: openstackid (IDP) · summit-api · Registration Lite · My Orders/Tickets · Event Site · Show Admin Answers the FAQ: "Why does Registration Lite ask me for my company every time, even when I'm logged in and we already have it?" — and the broader question of where these three fields live and what updates what, when. Verified against code: 2026-06-07 (summit-api origin/main cfc76424a · registration-lite v7.0.6 · my-orders-tickets v1.0.13 · event-site · openstackid · summit-admin). File:line citations in the Developer Appendix.

[[platform-overview]] | [[auth-flows]] | [[registration-modes-guide]]

TL;DR¶

First name, last name, and company exist in five places, not one: the IDP profile, the summit-api Member, the per-show Attendee, the Order owner, and (by reference) the Ticket owner.
The IDP profile is the identity-level source of truth. It flows down into summit-api (Member → Attendees) via background sync.
Registration and "My Orders" can flow back up: owner data entered at checkout is pushed to the Member and on to the IDP.
The "company every time" behavior is intentional. Registration Lite pre-fills your first/last name from your IDP login but deliberately leaves company blank so you re-state your current company at each registration. Because that value is written back to your profile (§3), re-asking actively keeps your company current instead of silently propagating a stale pre-fill. See §5.

1. The five places these fields live¶

#	Where	What it represents	Field names (technical)	Who edits it
1	IDP profile (openstackid)	Your one identity across every event	`first_name`, `last_name`, `company`, `job_title`	The user (Event Site profile, IDP profile page); also written back by registration — see §3
2	Member (summit-api)	summit-api's local mirror of your IDP identity	`FirstName`, `Surname`, `Company`	Synced from the IDP (not edited directly)
3	Attendee (summit-api, per show)	Who is attending this event	`FirstName`, `Surname`, `Company` (+ `CompanyID`)	Registration, My Orders, Show Admin
4	Order owner (summit-api, per order)	Who placed/owns the order	`OwnerFirstName`, `OwnerSurname`, `OwnerCompany` (+ `OwnerCompanyID`)	Registration checkout, Show Admin
5	Ticket owner	The Attendee assigned to a ticket	→ points at an Attendee (#3)	(follows the Attendee)

Two things to internalize:

The Attendee is per-show. The same person at three events has one IDP profile + one Member, but three Attendee records. Editing one show's attendee does not touch the others.
Company is stored two ways everywhere: a free-text name and an optional company ID (a link to a known company record). Forms send the ID when you pick a company from a list, or the plain text when you type a new one.

2. The default direction: IDP → Member → Attendee (downward sync)¶

   ┌─────────────────────────┐
   │  IDP profile (identity)  │  first_name, last_name, company, job_title
   └────────────┬────────────┘
                │  (A) background sync: on login, and on profile change (RabbitMQ)
                ▼
   ┌─────────────────────────┐
   │  Member (summit-api)     │  FirstName, Surname, Company
   └────────────┬────────────┘
                │  (B) background sync: "member changed" → updates that member's attendees
                ▼
   ┌─────────────────────────┐
   │  Attendee (per show)     │  FirstName, Surname, Company
   └─────────────────────────┘

(A) IDP → Member. Your Member record is refreshed from the IDP in two situations: 1. When you log in to a summit-api–backed app (your identity is read from the token and written to your Member). 2. When your IDP profile changes — the IDP publishes a "user updated" message and summit-api consumes it to update the Member. (This push relies on the message broker being enabled in the environment; the login path always works.)

(B) Member → Attendees. When your Member is updated from the IDP, summit-api fires a background job that updates all of your attendee records to match — first name, last name, and company.

Read-time fallback: if an Attendee's own first/last/company is blank, summit-api shows the Member's value instead. So an attendee can look "filled in" even when its own fields are empty.

3. The reverse direction: registration & My Orders can write up to the IDP¶

This is the part most people don't expect. Data does not only flow downward.

  Registration checkout / My Orders edit
        │  owner_first_name, owner_last_name, owner_company
        ▼
  Order owner (summit-api)
        │  on reserve: copies name onto the Member, fires "member updated"
        ▼
  Member ──────────────►  IDP profile  (pushed via the external-user API)

When an order is reserved with owner first name / last name / company, summit-api sets those on your Member and then pushes first name, last name, and company to your IDP profile. (Verified: the company value is included in that push.)
The Event Site profile page edits your IDP profile directly (PUT /users/me), and it also reconciles order-owner differences back to the IDP.

Consequence: the company you type during registration does end up on your IDP profile. The reason you keep getting asked for it is not that it isn't saved — it's that Registration Lite doesn't read it back. See §5.

4. Who updates what — quick reference¶

You do this…	…it writes to	…and propagates to
Edit profile on the Event Site	IDP profile	→ Member → your Attendees (background)
Edit profile on the IDP directly	IDP profile	→ Member → your Attendees (background)
Register / reserve an order (Registration Lite)	Order owner	→ Member → IDP (name + company pushed up)
Edit owner/attendee in My Orders/Tickets	The Attendee (ticket owner) for that show	Stays on that show's attendee
Admin edits an Attendee in Show Admin	That show's Attendee only	Local to the show (no IDP write-back)
Admin edits an Order owner in Show Admin	That order's owner	Owner-data writeback paths apply as in §3
Admin edits a Member	No such screen — members aren't edited in Show Admin; identity is changed in the IDP/Event Site	—

Show Admin notes for operators: - On the Attendee form, picking a Member auto-fills first/last name but not company — company stays whatever was there. Company is a free-text box. - On the Order form, picking a Member auto-fills first name, last name, and company. - There is no "resync from IDP" button. Re-sync happens automatically on the user's next login or next IDP profile change.

5. Why Registration Lite asks for company every time¶

This is intentional, not a bug. Registration Lite pre-fills your name from your login but deliberately leaves company blank so you re-enter it each time. The intent (per product) is to capture your current company at every registration — people change employers, and a silently pre-filled old value would quietly push stale data onto the order, the attendee record, and — via the write-back in §3 — your profile. Re-asking keeps company current; and because what you enter is pushed back to your IDP profile, it actively keeps your canonical profile fresh rather than letting it drift.

What the code does on a fresh registration: - First name ← your IDP login (given_name claim). ✅ pre-filled - Last name ← your IDP login (family_name claim). ✅ pre-filled - Company ← intentionally starts empty, so you confirm it each time.

Company is pre-filled in one case: when you're editing an order that already exists (it reads that order's saved owner company) — there you're reviewing a specific past order, not stating your current affiliation.

The other surfaces behave differently on purpose — they are "review/maintain your record" screens, not "state who you are for this registration": - My Orders/Tickets pre-fills company from the ticket owner (and locks it once set). - Event Site profile pre-fills company from your IDP profile.

Note (developer): the "ask every time" behavior is a product decision (re-collect to stay current), recalled by JP — the code simply doesn't pre-fill the company field on a new registration. If product ever decides a pre-filled-and-confirm experience is preferable, seeding the field from the profile company claim is a one-line change in the personal-information component (see appendix). That is not the current intent.

6. Gotchas & support answers¶

"I updated my name on the Event Site but an old badge/attendee still shows the old name." The downward sync (IDP → Member → Attendees) runs on your next login or when the IDP change is processed; it isn't instantaneous, and an attendee that was manually edited keeps its own value (it won't be silently overwritten by a blank).
"Why does my company differ between two events?" Attendee company is per show and can be edited per show; it only matches your profile if it was synced and never locally overridden.
"I changed company at registration but my profile didn't update." It should — registration pushes owner name + company up to the IDP. If it didn't, check that the order actually reserved (the writeback happens on reserve) and that the environment's IDP write path is healthy.
Free-text vs. picked company. Typing a company name stores text; picking from a list stores a company ID. Reporting that groups by company ID will not group two differently-typed spellings of the same company.

7. Developer Appendix — verified citations¶

Verified 2026-06-07. summit-api read at origin/main cfc76424a.

Field storage - IDP User: first_name/last_name/company/job_title — openstackid/.../models User.php:154,160,327,333. Exposed as OIDC claims given_name/family_name/company/job_title (StandardClaims.php:35,41,218,224; UserService.php:136-137,154-155) and via GET /api/v1/users/{id} / /oauth2/users/me. - Member: FirstName/Surname/Company — summit-api/app/Models/Foundation/Main/Member.php:83,96,439. - SummitAttendee: FirstName/Surname/Company(name)/CompanyID — .../Attendees/SummitAttendee.php:60,66,157,163; member relation :132; read-time fallback to member :598-605,618-625,806-815. - SummitOrder: OwnerFirstName/OwnerSurname/OwnerCompany/OwnerCompanyID — .../Registration/SummitOrder.php:77,83,95,101; owner→Member :108.

Sync flows - IDP → Member (login): ResourceServerContext::registerExternalUser → MemberFactory::populateFromExternalProfile (MemberFactory.php:55-96, sets fields :69-73). - IDP → Member (profile change): IDP UserService.php:392 dispatches PublishUserUpdated to the message broker (gated by ENABLE_MESSAGE_BROKER); summit-api consumes via Jobs/PublishUserUpdated.php:44-56. - Member → Attendees: MemberDataUpdatedExternally (MemberService.php:450) → EventServiceProvider.php:168-184 → Jobs/UpdateAttendeeInfo.php:54-58 → AttendeeService.php:712-831 (updates :809-826). - Order reserve → Member → IDP (writeback, incl. company): SummitOrderService::reserve sets member name + dispatches MemberUpdated(id,email,first,last,company) (SummitOrderService.php:~1889-1913) → Jobs/UpdateIDPMemberInfo.php:handle → MemberService::updateExternalUser (:729-745) → external_user_api->updateUser(..., company_name).

Front-ends - Registration Lite — the puzzle: summit-registration-lite/src/components/personal-information/index.js — name prefilled :48-49; company hard-empty :78; only filled from reservation.owner_company :97. Submits owner data on reserve (POST .../orders). - My Orders/Tickets: prefill company from owner my-orders-tickets-widget/src/utils/ticketUtils.js:244-245; disabled-if-set components/TicketDetail/components/CompanyField/index.js:35; update PUT .../orders/all/tickets/{id} (actions.js:749-762). - Event Site: reads IDP profile GET /api/v1/users/me (user-actions.js:591,154); edits IDP via PUT /api/v1/users/me (:457-463); reconciles order owner → IDP in checkOrderData() (:588-603). - Show Admin: attendee form first/last/company summit-admin/src/components/forms/attendee-form/attendee-form.js:312-356 → PUT .../attendees/{id} (attendee-actions.js:519; member-select auto-fills name only :96-100); order owner purchase-order-form.js:442-461 → PUT .../orders/{id} (order-actions.js:644; member-select auto-fills name+company owner-input.js:30-46). No Member edit page; no resync action.

Created: 2026-06-07. Re-collecting company at each registration (§5) is intentional product behavior — to keep company current and the profile fresh — not a bug.