Issue: Bite #30C.1 — Improve /admin/authentication/ UX
Branch: 699-bite-30c1---improve-adminauthentication-ux
Baseline SHA: 7ac3e2546f35e56a7d6ca491c47f2cf091e76475

1. 699-bite-30c1-improve-admin-authentication-ux.patch
2. 699-bite-30c1-fix-authentication-admin-e2e-card-locators.patch

• All local tests pass.
• make local-check passes.
• Complete Playwright suite passes.

Bite 30C.1 is primarily a presentation, navigation, and account-administration UX change. Manual verification should focus on proving that Authentication Accounts, People, and Actors are now clearly represented as distinct concepts while preserving the multi-Actor account model introduced by Bite 30C.

Identify these accounts before beginning:

• Application Administrator with a GLOBAL Actor, preferably the normal local bootstrap-admin.
• Multi-tenant ordinary Person account with one Authentication Account and at least two tenant Actors.
• Single-tenant ordinary Person account.
• Disposable ordinary account that can safely be deactivated/reactivated and receive a reset token.

For the multi-tenant account, the ideal fixture is the account used during Bite 30C testing, such as:

[email protected]

The important condition is:

one Authentication Account
    |
    +-- one global Person
    |
    +-- Tenant A Actor
    |
    +-- Tenant B Actor

• Sign in as Application Administrator.
• Open /admin/authentication.
• Allow the Authentication Accounts to finish loading.
• Scroll through several Accounts.

• Page loads without an Internal Server Error.
• Accounts are displayed as cards, not as the old flat Accounts table.
• Each card clearly separates:
  • Authentication Account
  • Person
  • Actors
  • Account-level actions
• Cards are visually readable and do not overlap.
• Long logins or Actor keys do not break the layout.
• No duplicate Account cards appear.
• No unexpected 500 requests appear in DevTools.

The hierarchy should read approximately:

Authentication Account
  [email protected]
  Account active

Person
  Person Name
  Email: [email protected]
  Open Person

Actors
  Tenant A
    Actor display name
    Actor: actor-key
    Tenant Actor · Primary

  Tenant B
    Actor display name
    Actor: actor-key
    Tenant Actor

Use an ordinary Person account.

• Locate the Account.
• Compare the Account login, Person identity, and Actor identity.

The three concepts are visibly distinct:

Authentication Account
    login

Person
    human's name
    human's email

Actors
    tenant context
    Actor display name
    Actor key

Verify specifically:

• Account login is shown under Authentication Account.
• Person name is shown under Person.
• Person email is shown under Person.
• Actor display name is shown under Actors.
• Actor key is explicitly labeled Actor:.
• The Actor is not presented as though it were the Person.
• The Person is not presented as though it were the Authentication Account.

This distinction is the central purpose of Bite 30C.1.

Use the multi-tenant Person account.

• Search for the Account by login.
• Inspect the complete Account card.

• Exactly one Authentication Account card appears for that login.
• The Person appears exactly once in the Person section.
• Both tenant Actors appear in the Actors section.
• Each Actor identifies the correct tenant.
• Each Actor has its own Actor key.
• Tenant A and Tenant B Actors are visually distinct.
• The Account is not duplicated once per Actor.

For example:

Authentication Account
  [email protected]

Person
  Marina Oliveira
  Email: [email protected]

Actors
  Byte 28A Manual Test (...)
    Marina Oliveira
    Actor: <tenant-a-actor>
    Tenant Actor · Primary

  default
    Marina Oliveira
    Actor: <tenant-b-actor>
    Tenant Actor

Using the same multi-tenant Account:

• Where a tenant has a display name different from its ID, both are clear.

For example:

Byte 28A Manual Test (<tenant-id>)

• A tenant whose name and ID are the same does not display unnecessary duplication.
• GLOBAL Actors use:

Application-wide

rather than pretending to belong to a tenant.

Inspect a multi-Actor Account.

• The primary Actor is labeled:

Tenant Actor · Primary

or, for an application Actor:

Global Actor · Primary

• Non-primary Actors do not receive the Primary label.
• Active Actors show Active.
• Inactive Actors, if available in your data, show Inactive.
• Account active/inactive state is visibly separate from Actor active/inactive state.

The UI should make it possible to understand:

Account state != Actor state

without having to infer it.

Locate the Application Administrator Account.

The card should look conceptually like:

Authentication Account
  <administrator-login>

Person
  No Person linked

  Application-level Accounts may intentionally
  exist without a Person.

Actors
  Application-wide
    <administrator actor>
    Actor: <actor-key>
    Global Actor

Verify:

• No Person linked is explicitly displayed.
• No fabricated Person name or email is shown.
• There is no misleading Open Person button.
• Actor tenant label says Application-wide.
• Actor is labeled Global Actor.
• Application Administrator is not visually represented as an ordinary tenant Person.

Use an ordinary Person Account with an available Open Person button.

For the strongest test, first select a tenant other than the tenant associated with the Account's primary Person projection.

• Note the Person name.
• Note the tenant shown below the Open Person button.
• Note your currently selected application tenant.
• Click Open Person.

• ERS opens /people/<person-id>.
• The displayed Person is the Person named on the Authentication Account card.
• The selected tenant changes to the tenant identified underneath the Open Person button when necessary.
• The Person page loads successfully.
• No 404, 403, or Internal Server Error occurs.
• The Person does not resolve to a record belonging to another tenant.

Then:

• Navigate back to /admin/authentication.
• Confirm the Authentication Account still displays normally.

Promotion blocker: Open Person opens the wrong tenant's Person or changes tenant without opening the corresponding Person.

Enter the Account's exact login in the Actor/Account filter.

• Correct Account card appears.
• Unrelated Accounts are filtered out as expected.
• [ x Clearing the filter restores the Account list.

Use a distinctive Person name.

Search using:

• Full Person name.
• A meaningful partial Person name.

• Authentication Account belonging to that Person appears.
• Search does not require knowing the Actor key.

Search using the Person's email, rather than the Authentication Account login.

For example:

Authentication login:
[email protected]

Person email:
[email protected]

• Searching the Person email finds the Account.
• The Person email is visibly distinguishable from the Account login.

Search using:

• Actor display name or nickname.
• Actor key.

• Correct Authentication Account appears.
• The matching Actor is visible inside that Account.
• The entire Account remains the unit being displayed; the UI does not create a separate pseudo-account for the Actor.

Using a multi-tenant Account:

Search using:

• Tenant display name, for example Byte 28A Manual Test.
• Tenant ID, if different.

• Account containing an Actor for that tenant appears.
• Tenant display name search works.
• Tenant ID search works.
• [ x Correct Actor/tenant association is visually obvious.

Search for a deliberately impossible value, such as:

zzzz-no-account-30c1

• No stale Account card remains visible.
• UI displays a useful empty-state message similar to:

No authentication accounts match this actor/account filter.

• Clearing the filter restores the Account list.

Inspect a multi-Actor Account.

The card footer should make clear:

[x] Password and activation controls apply to
the Authentication Account as a whole.

Verify:

• Deactivate / Activate appears at Account level.
• Issue reset token appears at Account level.
• These controls are not shown as though they belong to an individual Actor.
• There is only one set of Account controls even when the Account has multiple Actors.

This distinction is critical now that one Account may control several Actors.

Use a disposable Account, preferably one with two Actors.

• Record both Actors displayed on the card.
• Click Deactivate.
• Confirm Account status changes to:

Account inactive

• Refresh /admin/authentication.
• Confirm the same Account and Actors remain visible.
• Click Activate.
• Refresh again.

• Deactivation affects the Authentication Account, not only one displayed Actor.
• Neither Actor disappears merely because the Account was deactivated.
• Person identity remains attached.
• Reactivation restores Account status.
• No duplicate Account or Actor appears.

Use an active disposable Account with at least one active Actor.

• Locate the Account.
• Click Issue reset token.

• Reset token is issued.
• Token is associated with the Authentication Account rather than a particular Actor.
• Application Administrator remains authenticated.
• Page remains /admin/authentication.
• Account card remains visible.
• Person and all Actors remain unchanged.
• No duplicate Account appears after refresh.

You do not need to repeat the complete password-reset lifecycle if your full Playwright/local suite passed; this manual test is primarily verifying that the new card-level control is correctly placed and usable.

Locate the Account currently being used to administer /admin/authentication.

• Deactivate is disabled for the current Account.
• The control does not appear to belong to one particular Actor.
• Other eligible Accounts still have usable activation controls.

Because this bite is explicitly a UX improvement, perform a visual review rather than relying entirely on functional automation.

• Account header is visually distinct.
• Person and Actors are easy to scan.
• Multiple Actor cards do not overlap.
• Actor keys wrap appropriately.
• Tenant names are readable.
• Buttons remain visible.
• Status badges are understandable.
• Information hierarchy is obvious without inspecting raw IDs.

• Person and Actors stack cleanly.
• Actor cards remain readable.
• Buttons wrap rather than overlap.
• Long login/email values do not force horizontal scrolling of the entire application.

• Search for an Account.
• Clear the filter.
• Open a Person.
• Navigate back to Authentication Administration.
• Refresh the page.
• Navigate to another admin page.
• Return to /admin/authentication.

• Account information remains consistent.
• Person name/email remain populated.
• Tenant names remain populated.
• Multiple Actors remain visible.
• No duplicate cards appear.
• No stale Person or Actor information from another Account appears.

Keep DevTools open during the preceding tests.

• No unexpected JavaScript exception.
• No unexpected HTTP 500.
• /api/v1/auth/accounts succeeds.
• Person navigation succeeds.
• Account activation/deactivation succeeds when tested.
• Reset-token issuance succeeds when tested.
• No Actor/Account hydration error appears.

Bite 30C.1 is ready for promotion when all of the following are true:

• All local automated tests pass.
• /admin/authentication renders Account cards cleanly.
• Authentication Account, Person, and Actor identities are visually distinct.
• Ordinary Accounts show the correct global Person name and email.
• Multi-tenant Accounts show one Account, one Person, and all tenant Actors.
• Actors show human-readable tenant names.
• GLOBAL Actors show Application-wide.
• Application Administrator without a Person clearly shows No Person linked.
• Open Person opens the correct Person in the correct tenant.
• Search works by Account login.
• Search works by Person name.
• Search works by Person email.
• Search works by Actor key/name.
• Search works by tenant name/ID.
• Account-level controls are clearly Account-level.
• Disposable Account deactivate/reactivate works without disturbing Actor bindings.
• Reset-token issuance works from the new Account card.
• Current administrator cannot deactivate their own Account.
• Layout remains legible at narrower browser widths.
• Refresh/navigation does not duplicate or corrupt displayed identity information.
• No unexpected browser-console errors or HTTP 500s occur.

Do not promote Bite 30C.1 if any of these occur:

• An Actor is still visually presented as though it were the Person.
• A Person is presented as though it were the Authentication Account.
• A multi-tenant Person appears as multiple Authentication Accounts.
• A multi-tenant Account shows only its primary Actor and hides the others.
• Actors display the wrong tenant.
• An Application Administrator is falsely shown as having a Person.
• Open Person opens the wrong Person or wrong tenant.
• Search cannot find an Account by its Person identity or Actor identity.
• Account activation/password controls appear to operate on only one Actor.
• Deactivating an Account removes or corrupts its Person/Actor associations.
• Cards duplicate after refresh.
• The page produces unexpected 500 responses or hydration errors.

If all of these checks pass, Bite 30C.1 is ready for promotion.