Add a Reopen button for expired requests

[barborico]

Summary

Adds a "Reopen Request" button to the view for expired access, role, and group requests. It opens the normal create dialog prefilled from the lapsed request.

Urgency: LOW - 2 weeks?
Expected review effort: MEDIUM

Stacked on #597 — please review that one first; this branch targets brynna/request_expiration.

Motivation

#597 makes role and group requests expire, which means more requests will lapse without anyone having said no. Today a user whose request expired has no path back other than rebuilding it by hand from the read view: retyping the group, the duration, and the justification. This makes the common case one click.

Reopen is deliberately an ergonomic shortcut for "create a fresh one", not a new operation. It adds no endpoint; it drives the existing create endpoints, so tag constraints and conditional-access hooks re-run exactly as they would on a hand-built request.

Description & Screenshots of Changes

Recognising an expired request. Expiration is not modelled as its own status or column, so isExpiredRequest (src/helpers.tsx) infers it from status === 'REJECTED' + a null resolver + an exact match on the sweep's reason string. A null resolver alone is not enough: user deletion, group deletion, group unmanaging, and a conditional-access plugin denial all close requests with no resolver, and a policy denial in particular must never get a one-click reopen. The check goes through resolver, not resolver_user_id, because GroupRequestDetail exposes only the former — keying off the id would silently never match on group requests.

The reason string is duplicated across the language boundary and pinned by tests/test_expired_reason_constant.py, which reads src/helpers.tsx and asserts the backend constant appears in it.

Duration prefill is an extraction, not new logic. Recovering the duration a request originally asked for already existed, duplicated, in requests/Read.tsx and role_requests/Read.tsx. It moved to reconstructRequestedUntil in src/helpers.tsx and both call sites now use it, so this leaves one copy where there were two. The option-label map is a parameter rather than an assumption, because the access and role views source it differently (accessConfig.ACCESS_TIME_LABELS vs a hardcoded map) — unifying those is out of scope.

Requests store an absolute request_ending_at, so a request that expired because its window lapsed has a stored date in the past. Diffing against created_at recovers the duration: an exact match round-trips to that option, anything else is re-offered as a custom date based from today, and a tag time limit that has since tightened clamps the result.

The button lives inside CreateRequest. It is rendered via a new reopen prop (mirroring the existing renew prop) rather than as a separate button in the read view, so it sits inside CreateRequest's own null-return guards. A hand-rolled button plus controlled open/setOpen would gate the button and the dialog on different conditions and produce a dead button — visible, clicked, opening nothing — for a requester who has since become an owner of the group.

Visibility mirrors who may create the same request:

Type	Who sees reopen	Why
Access request	the original requester only	an access request targets its own requester, so nobody else can recreate that request
Role request	current owners of the role	a role request must be submitted by a role owner, so any of them can
Group request	any authenticated viewer	anyone may request a group

Group requests carry the most prefill (type, app, name, description, ownership duration, reason, tags, plugin config) and need two client-side resolutions the API returns bare — app id → AppDetail, tag ids → TagDetail[]. Both reuse locals the read view already computes; no new fetches. Plugin config is dropped when the app's lifecycle plugin changed since the request was written, since the stored config is keyed by the plugin id configured then; the rest of the prefill still applies.

Screenshot — reopening an expired individual access request:

Screenshot — reopening an expired app-group request. Note the name field holds the un-prefixed suffix (Reporting) beside the static App-Zztestapp-, matching how the create form works:

Validation of Changes

• make test green: ruff, ty, 879 backend pytest, 57 frontend vitest. npm run tsc clean.
• Unit tests on the pure helpers, which is where the decision logic lives: isExpiredRequest (the true case, a human rejection with both a populated and an empty reason, each of the four other null-resolver closure reasons, pending/approved, and missing fields); reconstructRequestedUntil (indefinite, exact-option round-trip, the 100-second rounding, the custom re-base, both clamp paths, and the no-clamp default); prefillablePluginData (matching plugin, switched plugin, no plugin, no app, and that it narrows to only the matching plugin's entry).
• The cross-language pin was tamper-checked: rewording the frontend constant makes it fail, and it passes again on revert.
• Browser-verified against a locally seeded database (make run-backend + make run-frontend, six seeded requests):
  • Button appears on the expired access, role, and group requests; absent on a control access request rejected by a person with reason "Not this quarter." — which is the discrimination the reason-string match buys.
  • Access request: group App-Access-Default, until reconstructed to 7776000 / "90 Days" from the original 90-day ask, reason verbatim, Member toggle set (Owner false).
  • Role request: role Role-Zz-Reopen-Demo, target group, "90 Days", reason verbatim, Member toggle. Dialog opened, so no dead button.
  • app_group: name field holds Reporting with App-Zztestapp- rendered as static text beside it — not App-Zztestapp-Reporting. This is the case only a browser catches; the pre-fix bug produced a valid name, so no test, type check, or lint would flag it. Type correctly seeded to app_group so the app selector rendered at all, app Zztestapp selected, tag chip Zz-Quarterly-Renewal resolved from its stored id, ownership "90 Days", reason verbatim.
  • role_group: Role-Zz-Analytics → name Zz-Analytics.
  • okta_group: Zzwidgets left intact — no over-stripping of a name that has no prefix.
  • No console warnings, including no MUI Autocomplete "none of the options match". All /api/ calls 200.
  • A request whose original duration was a custom date (47 days, not one of the preset options): the "Custom End Date" field renders and is pre-filled with today + 47 days. This case was broken until review caught it — the earlier pass only exercised the exact-option ("90 Days") path, which is the path that worked.
• No page render tests: this repo has essentially no such infrastructure (two files use React Testing Library) and .claude/access-dev-testing.md says coverage is concentrated on pure helpers and form logic. That is why the browser checklist above matters rather than being belt-and-braces.
• No migration, no Pydantic schema change, no generated-client edit, no new endpoint.

Guidance for Reviewers

Go file-by-file rather than commit-by-commit — the last commit is a fix pass that touches several of the earlier files, so the commits do not cleanly reflect final state.

Three callouts:

1. The inferred-expiry approach (isExpiredRequest). It matches a display string, which is a bit janky. The argument for it: reopen only opens a prefilled form, and submitting re-runs constraints and conditional-access hooks, so a wrongly-shown button self-corrects rather than granting anything. If we would rather pay for robustness, I think the right shape is added nuance in the status enum, but that's a heftier change.
2. Why the button is a reopen prop on CreateRequest rather than a button in the read view. This is load-bearing against the dead-button case described above; a future "simplification" that pulls it back out would reintroduce it.
3. reconstructRequestedUntil's optional timeLimit. The two pre-existing read-view call sites deliberately pass none, because they apply their own clamp separately when building the approve form's defaultValues. The three reopen call sites do pass it. Passing it at the wrong site silently changes what the approve form defaults to; both the helper and each call site carry a comment saying so.

🤖 Generated with Claude Code

[matthew-bass]

this seems nice / harmless to add, though how often do people go and immediately re-file requests in access for things that get rejected?