Promotion target: Bite 30I.3 → Bite 30I
Branch: 767-bite-30i3-support-access-lease-ux-and-auditability
Committed SHA: 6e9a4d289d8825e388e5d252034a9eb0b4852164

This manual suite validates the user-facing and auditability behavior introduced by Bite 30I.3 — Support Access Lease UX and Auditability after all local and CI automated tests have passed.

The suite specifically validates that:

• a GLOBAL Application Administrator can request a fixed-expiration, permission-scoped Tenant Support Access Lease through ERS UI;
• the request permission catalog is backend-owned and does not expose application-control-plane or Tenant Administrator authority;
• only the exact Tenant Administrator sees and can approve or terminate that Tenant's lease;
• a lease-backed Application Administrator remains the same APPLICATION-scoped Actor and receives only the explicitly approved Tenant permissions;
• the active Lease ID and expiration remain visibly attributable while the Administrator moves through Tenant workspaces;
• Support access lifecycle control is not available from the leased Tenant context;
• authorized Tenant requests are recorded as support_access.use against the exact Lease ID;
• denied Tenant requests made under an active lease are also attributable to that exact Lease ID;
• Tenant Administrators can inspect lease-specific support audit history without receiving general application-wide Audit Log access;
• the GLOBAL Application Administrator can filter the general Authorization Audit Log by Support Lease ID;
• support leases do not create a Person, Membership, Tenant Actor, Collaborator, or Role Grant for the Application Administrator;
• immediate termination removes Tenant authorization;
• terminated and expired-request history remains retained;
• a lapsed PENDING request is visibly expired, cannot be approved, and does not block a later request.

1. Use the ERS UI for every operation that the UI supports.
2. Do not manually type ERS deep-link URLs as a substitute for normal navigation.
3. Use the side navigation and the Administration context / Tenant selector.
4. DevTools is used only once, in Test 10, because the UI correctly hides Expenses when the lease does not contain expenses.read; an explicit denied request is required to verify denied support-audit attribution.
5. No SQL is required for normal execution of this promotion suite.
6. Do not infer Tenant scope from Person names, nicknames, or old fixture labels. Use ERS's displayed Tenant boundary, Tenant ID, and Support Lease ID as the authoritative evidence.
7. Do not infer a support lease from the presence of Tenant data alone. Use the top-bar Support access active banner and the displayed Lease ID.
8. A test is PASS only when every checkbox in its PASS criteria is satisfied.
9. Any condition explicitly marked PROMOTION BLOCKER blocks promotion of 30I.3 into Bite 30I until resolved.

Use three independent browser sessions so that approval/termination can occur without repeatedly signing the Application Administrator out.

Sign in as:

Login:    [email protected]
Password: Local-E2E-Administrator-28D!

Expected persistent authorization identity:

Role:  APPLICATION_ADMIN
Scope: APPLICATION
Global administration Tenant ID: *

The exact Actor Key may be bootstrap-admin or another already-existing GLOBAL Application Administrator Actor associated with [email protected]. Record the Actor ID and Actor Key during the preflight and use those recorded values for later comparisons.

Sign in as:

Login:    [email protected]
Password: Local-E2E-Administrator-28D!

Select:

Tenant A
Tenant ID: default

Expected role:

TENANT_ADMIN

Sign in as:

Login:    [email protected]
Password: Local-E2E-Administrator-28D!

Select:

Tenant B
Tenant ID: e2e-authz-admin-tenant
Tenant name: E2E Authorization Admin Boundary
Tenant code: E2EAUTHZADMIN

Expected role:

TENANT_ADMIN

Create a scratchpad and record these values exactly as ERS displays them.

Use these exact support reasons so that the test records are easy to recognize:

LEASE A reason:
Bite 30I.3 manual MAIN — support access UX and auditability

LEASE A termination reason:
Bite 30I.3 manual MAIN complete

LEASE B reason:
Bite 30I.3 manual EXPIRY — pending request must lapse

LEASE C reason:
Bite 30I.3 manual REPLACEMENT — lapsed pending no longer blocks

LEASE C termination reason:
Bite 30I.3 manual REPLACEMENT cleanup

From the repository root:

git branch --show-current
git rev-parse HEAD

Expected:

767-bite-30i3-support-access-lease-ux-and-auditability
6e9a4d289d8825e388e5d252034a9eb0b4852164

• [✔︎] Branch exactly matches 767-bite-30i3-support-access-lease-ux-and-auditability.
• [✔︎] HEAD exactly matches 6e9a4d289d8825e388e5d252034a9eb0b4852164.

PROMOTION BLOCKER: The branch or SHA does not match.

Use the normal local backend/frontend processes.

Typical commands from separate terminals:

make local-backend

and:

make local-frontend

Open ERS through the normal local browser URL.

• [✔] ERS loads normally.
• [√] Sign-in page is reachable.
• [√] No migration/startup error is present.

Do this using three separate browser sessions.

1. Sign in as [email protected].
2. Open Administration context.
3. Select Global administration.
4. Using the side navigation, click Authentication.
5. Find [email protected].
6. In Account identity boundary, record:
   • Actor ID as APP_ACTOR_ID;
   • Actor Key as APP_ACTOR_KEY.
7. Verify:

Person binding
None — no Person linked

8. Verify:

Tenant Actor bindings
None — no Tenant Actors linked

9. Verify:

Global Actor bindings
1

1. Sign in as [email protected].
2. Open the Tenant selector.
3. Select Tenant A (default).
4. Verify the selected Tenant is displayed.

1. Sign in as [email protected].
2. Open the Tenant selector.
3. Select E2E Authorization Admin Boundary (e2e-authz-admin-tenant).
4. Verify that Tenant is displayed.

• [√] Session A is authenticated as the Application Administrator.
• [√] Session A can select Global administration.
• [√] APP_ACTOR_ID is recorded.
• [√] APP_ACTOR_KEY is recorded.
• [√] Session B is authenticated as Tenant A Administrator.
• [√] Session B has Tenant A selected.
• [√] Session C is authenticated as Tenant B Administrator.
• [√] Session C has Tenant B selected.

This test suite must begin without an unexpired PENDING or effective APPROVED lease for the Application Administrator against Tenant A.

1. √ Select Global administration.
2. √ Using the side navigation, click Support access.
3. √ In Lease history, set:
   • Tenant = Tenant A;
   • Status = Pending.
4. √ Inspect the visible cards.
5. √ Change Status to Approved.
6. √ Inspect the visible cards.

Continue to Test 01.

In Session B:

1. Ensure Tenant A is selected.
2. Click Support access.
3. Find that lease.
4. Enter:

Preflight cleanup before Bite 30I.3 manual suite

in Immediate termination reason. 5. Click Terminate immediately. 6. Verify the lease becomes TERMINATED.

In Session B:

1. Ensure Tenant A is selected.
2. Click Support access.
3. Find the pending lease.
4. Click Approve support access.
5. After it becomes APPROVED, enter:

Preflight cleanup before Bite 30I.3 manual suite

6. Click Terminate immediately.
7. Verify the lease becomes TERMINATED.

• No unexpired PENDING Tenant A lease remains open for the Application Administrator.
• No effective APPROVED Tenant A lease remains open for the Application Administrator.

PROMOTION BLOCKER: The UI cannot bring the deterministic local fixture to a state where no open Tenant A lease remains.

Verify the 30I.3 Support access control plane is visible from Global administration, presents a backend-owned Tenant permission catalog, and does not offer application-control-plane authority as leaseable permissions.

Browser Session A

Login: [email protected]
Role: APPLICATION_ADMIN
Administration context: Global administration

1. √ In Session A, open Administration context.
2. √ Select Global administration.
3. √ Verify Global administration is displayed.
4. √ Inspect the side navigation.
5. √ Verify Support access is visible.
6. √ Verify Audit logs is visible.
7. √ Click Support access.
8. √ Verify the page heading is:

Support access

9. √ Verify the introductory text states that support access does not create:

Tenant Actor
Person
Membership
Collaborator
Role Grant

10. √ Verify the page contains:

Request Tenant support access

11. √ Verify the request form contains:
    • Tenant;
    • Fixed expiration;
    • Support reason / case;
    • Requested Tenant permissions.
12. √ Without choosing a Tenant or permission, verify Request support access is disabled.
13. √ Inspect the permission catalog.
14. Find:

√ Read people
√ people.read

15. Find:

√ Read reference data
√ reference_data.read

16. √ Verify the text says:

This catalog is supplied by the backend allowlist.
Control-plane and Tenant Administrator authority cannot be leased.

17. √ Scan the permission catalog and verify it does not offer:
    • authz.manage;
    • authz.read;
    • support_access_leases.request;
    • support_access_leases.approve;
    • support_access_leases.terminate;
    • TENANT_ADMIN;
    • wildcard *.
18. √ Verify Lease history is present.
19. √ Verify the history controls include:
    • Tenant;
    • Status;
    • Refresh.

The GLOBAL Application Administrator has a dedicated request/history workspace. Permission scope is chosen from an explicit Tenant-data allowlist; application-control-plane and Tenant Administrator authority are not leaseable.

• [√] Support access is visible in Global administration.
• [√] Request form is present.
• [√] people.read is present.
• [√] reference_data.read is present.
• [√] authz.manage is not offered.
• [√] No support_access_leases.* control-plane permission is offered.
• [√] No TENANT_ADMIN authority is offered.
• [√] Request button is disabled until required fields and at least one permission are selected.
• [√] Lease history is present.

PROMOTION BLOCKER: The request catalog exposes application-control-plane, wildcard, or Tenant Administrator authority.

Create the main Test Lease through the 30I.3 UI and verify its immutable request evidence.

Test 01 passed. Preflight confirmed no open Tenant A lease.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Navigate through the side menu to Support access.
2. √ Under Request Tenant support access, open Tenant.
3. √ Select Tenant A — the Tenant whose ID is default.
4. √ In Fixed expiration, set a time approximately 60 minutes in the future.
5. √ Make sure the selected expiration is at least 45 minutes in the future so the suite has sufficient time.
6. √ Copy the displayed expiration to your scratchpad as LEASE_A_EXPIRES.
7. √ In Support reason / case, enter exactly:

Bite 30I.3 manual MAIN — support access UX and auditability

8. √ Under Requested Tenant permissions, select only:
   • Read people — people.read;
   • Read reference data — reference_data.read.
9. √ Verify expenses.read is not selected.
10. √ Verify people.create is not selected.
11. √ Click Request support access.
12. √ Wait for Lease history to refresh. 13.√ Locate the newest card whose reason is:

Bite 30I.3 manual MAIN — support access UX and auditability

14. √ Verify the card status is:

PENDING

15. √ Record the displayed Lease ID as LEASE_A_ID.
16. √ Verify:

Tenant ID: default

17. √ Verify Application Actor is the same existing Application Actor associated with APP_ACTOR_ID.
18. √ Verify Support reason exactly matches the requested reason.
19. √ Verify Immutable permission scope contains exactly:
    • people.read;
    • reference_data.read.
20. √ Verify Fixed expiration corresponds to LEASE_A_EXPIRES.
21. √ Verify Approved by is —.
22. √ Verify Terminated by is —.
23. √ Verify no Approve support access button is offered to the Application Administrator.
24. √ Verify no Terminate immediately control is offered to the Application Administrator.

One retained PENDING lease is created for exactly Tenant A and the existing GLOBAL Application Administrator Actor. The request fields are visible as retained evidence.

• [√] One PENDING Lease A exists.
• [√] LEASE_A_ID is recorded.
• [√] Tenant ID is default.
• [√] Application Actor is the existing Application Actor.
• [√] Reason is exact.
• [√] Permission set contains exactly people.read and reference_data.read.
• [√] Fixed expiration matches the requested expiration.
• [√] Application Administrator cannot approve the request.
• [√] Application Administrator cannot terminate the pending request.

PROMOTION BLOCKER: Requesting support access creates a different Actor or grants permissions not explicitly selected.

Verify 30I.3 surfaces the existing 30I.2 open-lease conflict and exposes request audit evidence.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Remain on Support access.
2. √ Re-enter/select the same Tenant A values if the form no longer contains them.
3. √ Use a future expiration.
4. Enter any reason, for example:

Bite 30I.3 manual duplicate-open-lease probe

5.√ Select people.read. 6. √ Click Request support access. 7. √ Verify ERS displays an error equivalent to:

An open Tenant Support Access Lease already exists for this Application Administrator and Tenant

8. √ In Lease history, verify no second open Tenant A lease was created.

9. √ Find the LEASE_A_ID card.
10. √ Click Review audit trail.
11. √ Verify the table heading:

Lease audit trail

12. √ Verify an event exists with:

Decision:  AUTHORIZED
Operation: support_access_leases.request

13. √ Verify the operation shows permission:

support_access_leases.request

14. √ Verify the Request column shows:

POST /api/v1/authz/support-access-leases

15. √ Verify the audit Actor corresponds to the existing Application Administrator Actor.

• [√] Duplicate open request is rejected.
• [√] No second open Tenant A lease is created.
• [√] Lease A audit trail is visible to the GLOBAL Application Administrator.
• [√] support_access_leases.request is recorded as AUTHORIZED.
• [√] Request method/path are retained.

PROMOTION BLOCKER: A duplicate open lease is silently created, or the successful request has no lease-specific audit event.

Verify lease history and lifecycle authority are exact-Tenant scoped.

Browser Session C

Login: [email protected]
Tenant: E2E Authorization Admin Boundary
Tenant ID: e2e-authz-admin-tenant
Role: TENANT_ADMIN

1. √ Ensure Tenant B is selected.
2. √ Verify the selected Tenant is E2E Authorization Admin Boundary.
3. I√ nspect side navigation.
4. √ Verify Support access is visible.
5. √ Click Support access.
6. √ Verify the page displays a Tenant boundary corresponding to Tenant B.
7. √ Verify the displayed Tenant ID is:

e2e-authz-admin-tenant

8. √ Verify Request Tenant support access is not displayed.
9. √ Inspect Lease history.
10. √ Verify LEASE_A_ID is not present.
11. √ Verify the reason:

Bite 30I.3 manual MAIN — support access UX and auditability

is not present. √ 12. Inspect side navigation. √ 13. Verify general Audit logs is not offered to this Tenant Administrator.

Tenant B Administrator sees only Tenant B support-access history and cannot request leases or inspect Tenant A's Lease A.

• [√] Tenant boundary is Tenant B.
• [√] Tenant B Administrator has no request form.
• [√] Lease A is absent.
• [√] Tenant B Administrator does not have general Audit Logs navigation.

PROMOTION BLOCKER: Tenant B Administrator can see, approve, terminate, or audit Tenant A's Lease A.

Verify the exact Tenant Administrator receives the request with enough immutable evidence to make the approval decision.

Browser Session B

Login: [email protected]
Tenant: Tenant A
Tenant ID: default
Role: TENANT_ADMIN

1. √ Ensure Tenant A (default) is selected.
2. √ Click Support access in side navigation.
3. √ Verify the page displays Tenant A's Tenant boundary.
4. √ Verify:

Tenant ID: default

5. √ Verify Request Tenant support access is not displayed.
6. √ Locate LEASE_A_ID.
7. √ Verify status:

PENDING

8. √ Verify Application Actor corresponds to the recorded Application Administrator Actor.
9. √ Verify the support reason is exactly:

Bite 30I.3 manual MAIN — support access UX and auditability

10. √ Verify Fixed expiration corresponds to LEASE_A_EXPIRES.
11. √ Verify Immutable permission scope displays:
    • label Read people and code people.read;
    • label Read reference data and code reference_data.read.
12. √ Verify no expenses.read permission is present.
13. √ Verify Approve support access is visible.
14. √ Click Review audit trail.
15. √ Verify the support_access_leases.request audit event from Test 03 is visible.
16. √ Verify the page does not offer a cross-Tenant Tenant filter; the Tenant boundary is fixed by the selected Tenant Administrator context.
17. √ Verify general Audit logs is not present in side navigation.

• [√] Exact Tenant A Administrator sees Lease A.
• [√] Request evidence is complete.
• [√] Immutable permission scope is understandable by label and code.
• [√] Approval action is available.
• [√] Lease-specific audit trail works.
• [√] General application Audit Logs access is absent.

PROMOTION BLOCKER: A Tenant Administrator must guess the requested permission scope, or receives general application audit authority.

Verify exact-Tenant approval, approval audit attribution, and immutable expiration.

Test 05 passed.

Browser Session B

Login: [email protected]
Tenant ID: default

1. √ On Support access, locate LEASE_A_ID.
2. √ Re-confirm its status is PENDING.
3. √ Re-confirm its Fixed expiration matches LEASE_A_EXPIRES.
4. √ Click Approve support access.
5. √ Wait for the lease card to refresh.
6. √ Verify the effective status becomes:

APPROVED

7. √ Verify Approved by is no longer —.
8. √ Record the displayed approving Actor ID as LEASE_A_APPROVER.
9. √ Verify the Fixed expiration did not change and still matches LEASE_A_EXPIRES.
10. √ Verify the immutable permission scope remains exactly:
    • people.read;
    • reference_data.read.
11. √ Verify Approve support access is no longer displayed.
12. √ Verify the Immediate termination reason field is now displayed.
13. √ With the termination-reason field empty, verify Terminate immediately is disabled.
14. √ Open Lease audit trail if it is not already open. 15.√ Verify the audit trail contains both:

support_access_leases.request
support_access_leases.approve

16. √ Verify the approval event is AUTHORIZED.
17. Verify the approval request shows:

POST /api/v1/authz/support-access-leases/<LEASE_A_ID>/approve

• Lease A becomes APPROVED.
• Approver Actor is recorded.
• Fixed expiration is unchanged.
• Permission scope is unchanged.
• Approval audit event is present.
• Termination requires a reason.

PROMOTION BLOCKER: Approval extends the lease expiration, changes permissions, or lacks approver/audit provenance.

Verify an approved lease creates a selectable Tenant support context without creating a Tenant Actor.

Browser Session A

Login: [email protected]
Start in: Global administration

1. √ Refresh Session A's ERS browser window so the account's available contexts are reloaded.
2. √ Verify Global administration remains available.
3. √ Open Administration context.
4. √ Verify a Tenant A context is now available. 5.√ Verify Tenant B is not newly available merely because Tenant A Lease A was approved.
5. √ Select Tenant A.
6. √ Wait for the workspace to load.
7. √ Verify the Administration context shows Tenant A.
8. √ In the top bar, verify a visible amber panel says:

Support access active

10. √ Verify that panel displays LEASE_A_ID. 11.√ Verify the panel displays an expiration corresponding to LEASE_A_EXPIRES.
11. √ Inspect side navigation.
12. √ Verify Support access is hidden while this lease-backed Tenant context is selected.

The existing Application Administrator Account gains a temporary selectable Tenant context backed by LEASE_A_ID. ERS visibly identifies the lease on every workspace page.

• Tenant A becomes selectable only after approval.
• Tenant B is not granted by Tenant A Lease A.
• Support access active is visible.
• Displayed Lease ID equals LEASE_A_ID.
• Displayed expiration matches Lease A.
• Support access lifecycle navigation is hidden in the lease-backed context.

PROMOTION BLOCKER: The lease is active but the UI does not disclose the Lease ID, or a lease for Tenant A authorizes Tenant B.

Verify lease-backed Tenant operation remains separate from Global administration and a control-plane denial does not destroy the active lease.

Browser Session A

Login: [email protected]
Administration context: Tenant A through LEASE_A_ID

1. √ Verify the top bar still shows Support access active with LEASE_A_ID.
2. √ Verify Support access is not present in side navigation.
3. √ Inspect the side navigation for Audit logs. 4.√ If Audit logs is visible, click it.
4. √ Verify the global audit data does not load in the leased Tenant context.
5. √ The allowed denial presentation is:

Access forbidden
Your current authorization context does not permit this operation.

7. √ Verify the top bar still shows Support access active with LEASE_A_ID.
8. √ Click People in side navigation.
9. √ Verify People loads normally again under the same lease.
10. √ Re-verify the same LEASE_A_ID remains displayed.

If Audit logs is already hidden in Step 3, treat that as equivalent control-plane suppression and continue with Steps 7–10.

• Lease-backed context cannot read the global Audit Log Viewer.
• A denied control-plane attempt does not terminate or lose Lease A.
• People remains usable afterward under the same Lease ID.

PROMOTION BLOCKER: Selecting a leased Tenant grants global Audit Log access, or a denied control-plane action causes the valid lease to disappear.

Verify Tenant data access works through the lease, stays within Tenant A, and the page exposes the exact lease provenance.

Browser Session A

Login: [email protected]
Administration context: Tenant A through LEASE_A_ID

1. Click People in side navigation.
2. Wait for the page to finish loading.
3. Locate People tenant boundary.
4. Verify it identifies Tenant A.
5. Verify:

Tenant ID: default

6. Verify the badge:

Tenant Support Access Lease

7. Verify:

Support Lease ID: <LEASE_A_ID>

8. Verify the People directory and filters load.
9. Verify at least one Tenant A Person record is displayed if the local fixture contains People.
10. Do not use a Person's nickname as Tenant evidence; use the People tenant boundary.
11. Verify New Person is absent because Lease A does not include people.create.
12. Verify the top bar still displays Support access active with LEASE_A_ID.

• People loads under Tenant A.
• Tenant ID default is explicit.
• LEASE_A_ID is explicit.
• Read-only scope is respected: no people.create UI.
• Lease remains visible after navigation.

PROMOTION BLOCKER: People data loads without Tenant/Lease provenance, or unleased write authority appears.

Create one deliberate denied support request so that 30I.3 denied-audit attribution can be verified.

Lease A intentionally does not contain expenses.read. Correct UI behavior therefore hides the Expenses side-navigation item. Because the UI prevents the forbidden action, DevTools is used once to generate a controlled denied request.

Browser Session A

Login: [email protected]
Administration context: Tenant A through LEASE_A_ID

1. √ Verify Support access active shows LEASE_A_ID.
2. √ Inspect side navigation.
3. √ Verify Expenses is not displayed.
4. √ Verify People remains displayed.

5. Open browser DevTools → Console.
6. Paste this entire block without editing it:

const response30i3 = await fetch(
  "/api/v1/expenses?page=1&pageSize=1",
  {
    credentials: "include",
    headers: {
      "X-Tenant-ID": "default"
    }
  }
);

const payload30i3 = await response30i3.json().catch(() => null);

console.log({
  status: response30i3.status,
  ok: response30i3.ok,
  payload: payload30i3
});

7. √ Verify the console result contains:

status: 403
ok: false

8. √ Verify the error code is:

forbidden

9. √ Close DevTools.
10. √ Return to ERS.
11. √ Verify the top bar still shows Support access active with LEASE_A_ID.
12. √ Click People.
13. √ Verify People still loads under Lease A.

• Expenses is not offered in the UI.
• Forced Expenses request receives HTTP 403.
• Lease A remains active afterward.
• People remains authorized afterward.

PROMOTION BLOCKER: The request succeeds without expenses.read, or the denied request destroys an otherwise valid lease.

Verify exact-Tenant audit review includes lifecycle events plus actual authorized/denied support use.

Browser Session B

Login: [email protected]
Tenant ID: default

1. √ Click Support access.
2. √ Find LEASE_A_ID.
3. √ Verify it remains APPROVED.
4. √ Click Review audit trail.
5. √ Verify lifecycle events include:
   • support_access_leases.request;
   • support_access_leases.approve.
6. √ Find at least one event with:

Operation: support_access.use
Decision:  AUTHORIZED
Permission: people.read

7.√ Verify its Request column identifies a People request, such as:

GET /api/v1/people

or a People request path with query parameters omitted from the displayed path. 8. √ If reference_data.read generated an additional authorized event, verify it is also attributed to Lease A; this additional event is allowed but not required for PASS. 9. √ Find an event with:

Operation: support_access.use
Decision:  DENIED
Permission: expenses.read

10.√ Verify its Request column identifies:

GET /api/v1/expenses

11. √ Verify the audit events show the Application Administrator's existing Actor identity rather than a synthetic Tenant Actor.

• Authorized people.read support use is audited.
• Denied expenses.read support attempt is audited.
• Both are part of LEASE_A_ID's lease audit trail.
• Request method/path are visible.
• Actor identity remains the Application Administrator Actor.

PROMOTION BLOCKER: Support actions cannot be attributed to the exact lease, permission, decision, and request path.

Verify first-class supportLeaseId audit attribution is visible and filterable from the global Authorization Audit Log Viewer.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Open Administration context.
2. √ Select Global administration.
3. √ Verify the Support access active banner disappears because the selected context is no longer the leased Tenant context.
4. √ Click Audit logs in side navigation.
5. √ Verify heading:

Audit Log Viewer

6. √ Under Authenticated authorization context, verify Selected Tenant ID is:

*

7. √ In Support Lease ID, enter LEASE_A_ID.
8. √ Leave Operation as:

All sensitive and authorization events

9. √ Leave Decision as All decisions.
10. √ Click Apply Filters.
11. √ Verify one or more results are shown.
12. In the result rows, verify:

Support Lease: <LEASE_A_ID>

13. √ Verify lifecycle operations for Lease A are included, including request and approval.
14. √ Change Operation to:

Support-authorized request

15. √ Change Decision to:

Denied

16. √ Keep Support Lease ID = LEASE_A_ID.
17. √ Click Apply Filters.
18. Verify the resulting denied row includes:
    • raw operation support_access.use;
    • permission expenses.read;
    • Support Lease = LEASE_A_ID;
    • request GET /api/v1/expenses;
    • decision DENIED.
19. √ Change Decision to Authorized and apply filters.
20. √ Verify an authorized support row includes:
    • raw operation support_access.use;
    • permission people.read;
    • Support Lease = LEASE_A_ID;
    • decision AUTHORIZED.
21. √ Click Reset.

• Support Lease ID is an explicit filter.
• Lease A events are returned when filtering by LEASE_A_ID.
• Audit rows display the Support Lease ID.
• Authorized and denied support use can be distinguished.
• Permission and request path evidence are visible.

PROMOTION BLOCKER: Global audit cannot isolate activity by Support Lease ID.

Re-verify the permanent identity boundary after request, approval, and Tenant use.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Click Authentication in side navigation.
2. √ Find [email protected].
3. √ Verify Actor ID still equals recorded APP_ACTOR_ID.
4. √ Verify Actor Key still equals recorded APP_ACTOR_KEY. 5.√ In Account identity boundary, verify:

Person binding
None — no Person linked

6. √ Verify:

Tenant Actor bindings
None — no Tenant Actors linked

7. √ Verify:

Global Actor bindings
1

8. √ Verify no new Tenant A Actor is listed for the account.
9. √ Verify no Person has appeared merely because Lease A was requested/approved/used.

• Actor ID unchanged.
• Actor Key unchanged.
• No Person binding.
• No Tenant Actor binding.
• x ] Exactly one Global Actor binding.

PROMOTION BLOCKER: Support access materializes permanent Tenant identity for the Application Administrator.

Verify global history filtering works and lifecycle buttons remain restricted to the exact Tenant Administrator.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Click Support access.
2. √ In Lease history, set Tenant to Tenant A.
3. Set Status to:

Approved

4. √ Verify LEASE_A_ID is displayed.
5. √ Verify its reason and permission scope are unchanged.
6. √ Verify the Application Administrator still does not have:
   • Approve support access;
   • Terminate immediately.
7. √ Change Tenant to Tenant B.
8. √ Verify LEASE_A_ID disappears.
9. C √ hange Tenant back to Tenant A.
10. √ Change Status to Pending.
11. √ Verify LEASE_A_ID is not shown as PENDING.
12. √ Set Status back to Approved.
13. √ Verify LEASE_A_ID returns.

• Tenant filter isolates Tenant A history.
• Status filter distinguishes APPROVED from PENDING.
• Global Application Administrator cannot perform Tenant approval/termination actions.

PROMOTION BLOCKER: The global requester can approve or terminate its own lease.

Verify explicit immediate termination, required reason, retained termination evidence, and unchanged fixed expiration.

Before terminating the lease:

1. √ In Session A, select Tenant A through LEASE_A_ID.
2. √ Click People.
3. √ Verify Support access active still displays LEASE_A_ID.
4. √ Leave this browser window open on People.

Browser Session B

Login: [email protected]
Tenant ID: default

5. √ Click Support access.
6. √ Find LEASE_A_ID.
7. √ Verify it is APPROVED.
8. √ Verify Immediate termination reason is displayed.
9. √ With the reason field empty, verify Terminate immediately is disabled.
10. Bite 30I.3 manual MAIN completeEnter exactly:

Bite 30I.3 manual MAIN complete

11. √ Bite 30I.3 manual MAIN completeClick Terminate immediately.
12. √ Wait for the lease card to refresh.
13. √ Verify status:

TERMINATED

14. √ Verify Terminated by is no longer —.
15. √ Record it as LEASE_A_TERMINATOR.
16. √ Verify Termination reason is exactly:

Bite 30I.3 manual MAIN complete

17. √ Verify Fixed expiration still corresponds to LEASE_A_EXPIRES.
18. √ Verify the immutable permission scope still contains exactly:
    • people.read;
    • reference_data.read.
19. √ Click Review audit trail.
20. √ Verify an AUTHORIZED event exists for:

support_access_leases.terminate

21. √ Verify the request path identifies:

POST /api/v1/authz/support-access-leases/<LEASE_A_ID>/terminate

• Termination cannot be submitted without a reason.
• Lease becomes TERMINATED.
• Terminator Actor is recorded.
• Termination reason is retained.
• Fixed expiration remains unchanged.
• Permission scope remains unchanged.
• Termination audit event is present.

PROMOTION BLOCKER: Termination changes request evidence or is not attributable to the terminating Tenant Administrator.

Verify terminated Lease A no longer authorizes Tenant A and the Application Administrator's Global context survives.

Browser Session A was deliberately left open on Tenant A People before Test 15 terminated Lease A.

1. √ Return to Session A.
2. √ Refresh the browser.
3. √ Wait for ERS to reload the Account's available Administration contexts.
4. √ Verify the workspace no longer presents Tenant A as an active lease-backed context for Lease A.
5. √ Verify Support access active with LEASE_A_ID is no longer displayed.
6. √ Verify Global administration remains available.
7. √ Select Global administration if ERS does not automatically fall back to it.
8. √ Open Administration context.
9. √ Verify Tenant A is no longer listed as an active support context, assuming no other active Tenant A lease exists.
10. √ Verify Session A remains signed in.

• Terminated Lease A no longer provides Tenant A authorization.
• Lease banner disappears.
• Tenant A lease option disappears.
• Authentication session remains valid.
• Global administration remains available.

PROMOTION BLOCKER: A terminated lease continues authorizing Tenant requests or the termination destroys the Application Administrator's account session.

Verify termination does not delete or rewrite historical support evidence.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Click Support access.
2. √ In Lease history:
   • Tenant = Tenant A;
   • Status = Terminated.
3. √ Verify LEASE_A_ID is displayed.
4. √ Verify the original support reason remains:

Bite 30I.3 manual MAIN — support access UX and auditability

5. √ Verify the original fixed expiration still matches LEASE_A_EXPIRES.
6. √ Verify immutable permissions still show exactly:
   • people.read;
   • reference_data.read.
7. √ Verify Approved by remains populated.
8. √ Verify Terminated by remains populated.
9. √ Verify termination reason remains:

Bite 30I.3 manual MAIN complete

10.√ Verify there is no Delete action for the lease. 11. Click Review audit trail. 12. √ Verify the retained history includes: - support_access_leases.request; - support_access_leases.approve; - authorized support_access.use for people.read; - denied support_access.use for expenses.read; - support_access_leases.terminate. 13. √ Navigate through side menu to Audit logs. 14. √ Filter by LEASE_A_ID. 15. √ Verify the same lifecycle/support-use evidence remains discoverable after termination.

• Terminated lease remains visible.
• Request evidence remains immutable.
• Approval evidence remains.
• Use evidence remains.
• Termination evidence remains.
• No delete action exists.
• Global audit filter continues finding the terminated lease's events.

PROMOTION BLOCKER: Termination removes audit history or rewrites immutable request fields.

Verify the 30I.3 UX for a PENDING request whose immutable expiration passes before approval.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Click Support access.
2. √ Confirm no open Tenant A lease currently exists.
3. √ Under Request Tenant support access, select Tenant A (default).
4. Set Fixed expiration to approximately 2 minutes in the future.
   • Choose a value that is at least 90 seconds ahead to avoid crossing the minute boundary while filling the form.
5. √ Record the displayed expiration as LEASE_B_EXPIRES.
6. √ Enter exactly:

Bite 30I.3 manual EXPIRY — pending request must lapse

7. √ Select only:

Read people
people.read

8. √ Click Request support access.
9. √ Find the new card.
10. √ Verify it is PENDING.
11. √ Record its ID as LEASE_B_ID.

Browser Session B

12. √ Ensure Tenant A (default) is selected.
13. √ Click Support access.
14. √ Find LEASE_B_ID.
15. √ Before its expiration time, verify Approve support access is visible.
16. √ Do not approve it.

17. √ Wait until the local clock is at least 15 seconds past LEASE_B_EXPIRES.
18. √ In Session B, click Refresh in Lease history.
19. √ Find LEASE_B_ID.
20. √ Verify the badge is:

EXPIRED

21. √ Verify the card also states:

Expired request

22. √ Verify the explanatory message says the pending request passed its immutable expiration and can no longer be approved.
23. √ Verify Approve support access is no longer available.

Browser Session A

24. √ Return to Global administration → Support access.
25. √ Set:
    • Tenant = Tenant A;
    • Status = Expired.
26. √ Verify LEASE_B_ID is displayed.
27. √ Verify the original reason, expiration, and people.read scope remain visible.

• Lease B starts as PENDING.
• Lease B is initially approvable by exact Tenant Admin.
• After its fixed expiration it is displayed as EXPIRED.
• Expired request cannot be approved.
• Historical request evidence remains visible.
• Expired status filter finds it.

PROMOTION BLOCKER: A lapsed PENDING request can still be approved.

Verify lapsed PENDING Lease B no longer blocks a later request for the same Application Administrator and Tenant.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Navigate to Support access.
2. √ Under Request Tenant support access, select Tenant A.
3. √ Set Fixed expiration to approximately 30 minutes in the future.
4. √ Enter exactly:

Bite 30I.3 manual REPLACEMENT — lapsed pending no longer blocks

5. √ Select only:

Read people
people.read

6. √ Click Request support access.
7. √ Verify the request succeeds.
8. √ Find the new PENDING lease.
9. √ Record it as LEASE_C_ID.
10. √ Verify LEASE_C_ID is different from LEASE_B_ID.

Browser Session B

11. √ Ensure Tenant A is selected.
12. √ Click Support access.
13. √ Find LEASE_C_ID.
14. √ Verify it is PENDING.
15. √ Click Approve support access.
16. √ Verify it becomes APPROVED.
17. In Immediate termination reason, enter:

Bite 30I.3 manual REPLACEMENT cleanup

18. √ Click Terminate immediately.
19. √ Verify it becomes TERMINATED.
20. √ Click Review audit trail.
21. √ Verify Lease C includes request, approval, and termination events.

• Expired Lease B does not block Lease C.
• Lease C has a distinct ID.
• Lease C can be approved by exact Tenant Admin.
• Lease C can be terminated with a reason.
• Lease C history is retained.

PROMOTION BLOCKER: Lapsed PENDING history permanently blocks future support requests.

Verify Tenant B still cannot see any Tenant A manual leases after the complete lifecycle/audit exercise.

Browser Session C

Login: [email protected]
Tenant ID: e2e-authz-admin-tenant

1. √ Ensure E2E Authorization Admin Boundary is selected.
2. √ Click Support access.
3. √ Verify Tenant boundary:

Tenant ID: e2e-authz-admin-tenant

4. √ Set Status to All statuses.
5. √ Click Refresh.
6. √ Verify none of these Lease IDs are visible:
   • LEASE_A_ID;
   • LEASE_B_ID;
   • LEASE_C_ID.
7. V√ erify none of these reasons are visible:
   • Bite 30I.3 manual MAIN — support access UX and auditability;
   • Bite 30I.3 manual EXPIRY — pending request must lapse;
   • Bite 30I.3 manual REPLACEMENT — lapsed pending no longer blocks.
8. √ Verify Request Tenant support access is absent.
9. √ Verify general Audit logs remains absent from side navigation.

• Tenant B cannot see Tenant A lease history.
• Tenant B cannot request Application Administrator support access.
• Tenant B Tenant Administrator still lacks general application audit access.

PROMOTION BLOCKER: Any Tenant A lease or audit evidence leaks into Tenant B's Support access workspace.

Finish the suite in a clean, promotion-reviewable state and re-check permanent identity.

Browser Session A

Login: [email protected]
Administration context: Global administration

1. √ Refresh Session A.
2. √ Select Global administration.
3. √ Open Administration context.
4. √ Verify Tenant A is not currently available as an active support context after Lease A and Lease C were terminated and Lease B expired.
5. √ Verify Support access active is not displayed.
6. √ Click Authentication.
7. √ Find [email protected].
8. √ Verify Actor ID still equals APP_ACTOR_ID.
9. √ Verify Actor Key still equals APP_ACTOR_KEY.
10. √ In Account identity boundary, verify:

Person binding
None — no Person linked

11. Verify:

Tenant Actor bindings
None — no Tenant Actors linked

12. Verify:

Global Actor bindings
1

13. Click Support access.
14. Set Tenant filter to Tenant A and Status to All statuses.
15. Verify retained manual history includes:
    • Lease A — TERMINATED;
    • Lease B — EXPIRED;
    • Lease C — TERMINATED.
16. Verify no effective APPROVED manual lease remains.

• No active support lease remains from this suite.
• Global administration remains available.
• Application Actor identity is unchanged.
• No Person or Tenant Actor binding exists.
• Manual history remains retained.
• No effective approved manual lease remains.

PROMOTION BLOCKER: The suite leaves permanent Tenant identity or an unintended active support lease.

Promote Bite 30I.3 into Bite 30I only if every item below is true.

• GLOBAL Application Administrator can open Support access.
• Request form uses exactly one Tenant, fixed expiration, required reason, and explicit permission selection.
• Permission catalog is backend-owned in presentation and excludes application-control-plane/Tenant Administrator authority.
• Duplicate open requests are rejected visibly.

• Tenant A Administrator sees Tenant A requests.
• Tenant B Administrator cannot see Tenant A requests.
• Only exact Tenant Administrator can approve.
• Approval does not extend expiration.
• Approval does not alter permission scope.

• Approved lease produces a selectable Tenant support context.
• Top bar displays Support access active, Lease ID, and expiration.
• People explicitly displays Tenant boundary and Support Lease ID.
• Unleased write/actions are not exposed.
• Support lifecycle control is not available in the lease-backed context.
• Global control-plane requests remain denied in the leased Tenant context.
• Denials do not destroy an otherwise valid lease.

• Request event is attributable to the Lease ID.
• Approval event is attributable to the Lease ID.
• Authorized people.read support use is attributable to the Lease ID.
• Denied expenses.read attempt is attributable to the Lease ID.
• Request method/path are visible.
• Tenant Admin can review lease-specific audit.
• Tenant Admin does not receive general application Audit Logs access.
• Global Audit Log Viewer filters by Support Lease ID.
• Support Lease ID is displayed in global audit results.

• Application Administrator Actor ID remains unchanged.
• Application Administrator Actor Key remains unchanged.
• No Person is linked.
• No Tenant Actor is linked.
• Exactly one Global Actor binding remains.

• Termination requires a reason.
• Exact Tenant Admin can terminate immediately.
• Termination removes Tenant authorization.
• Application Administrator's login session remains valid.
• Terminated lease record remains retained.
• Request/approval/use/termination audit remains retained.

• Lapsed PENDING request displays as EXPIRED.
• Lapsed PENDING request cannot be approved.
• Lapsed PENDING request remains historical.
• Lapsed PENDING request does not block a later request.

Do not promote Bite 30I.3 to Bite 30I if any of the following occurs:

• Application Administrator can request wildcard, TENANT_ADMIN, authz.manage, or other application-control-plane authority through a support lease.
• Wrong Tenant Administrator can see, approve, terminate, or audit another Tenant's support lease.
• Application Administrator can approve or terminate its own support request.
• Approval changes the originally requested expiration or permission scope.
• Lease activation creates a Person, Person–Tenant Membership, Tenant Actor, Collaborator, or Role Grant.
• Tenant A lease authorizes Tenant B.
• Active lease is not visibly attributable by Lease ID.
• Authorized support action is not auditable against the Lease ID.
• Denied support request is not auditable against the Lease ID.
• Tenant Administrator receives general application Audit Log access.
• Global Audit Log Viewer cannot filter by Support Lease ID.
• Termination does not remove authorization.
• Termination deletes or rewrites history.
• Lapsed PENDING request remains approvable.
• Lapsed PENDING request permanently blocks a later request.
• Any manual lease remains unintentionally effective at the end of the suite.

If all three identities already exist and can sign in with the credentials in this document, do not run a fixture script merely because this suite exists.

If one of the deterministic local identities is missing or unusable, use the accompanying:

prepare-bite30i3-manual-fixtures.py

from the ERS repository root.

The helper:

• reuses [email protected]'s existing GLOBAL APPLICATION_ADMIN Actor when valid;
• refuses to rebind/elevate an unrelated existing login;
• invokes the repository's own backend/cmd/provision-e2e-admin;
• creates/reconciles the deterministic Tenant Administrator fixtures;
• does not create a Tenant Support Access Lease.

The support leases must be created, approved, used, expired, and terminated through the UI in this suite.

Exactly one DevTools request is required: Test 10, to generate a denied expenses.read support attempt because the UI correctly hides Expenses without that permission.

No SQL is required for normal execution of this manual promotion suite.

If UI evidence is inconsistent, stop the suite and treat the discrepancy as a defect rather than using SQL to override the UI acceptance result.