Log and surface cancelled access requests for gateway managers

[rustyjux]

User Story

As a gateway manager,
I want cancelled (self-denied) access requests to leave a clear activity trail and not appear as still-pending work,
so that I can understand what happened to a request without hunting for a consumer that no longer exists.

---

Background

When a consumer cancels (self-denies) a pending access request, the Portal hard-deletes the AccessRequest (and related consumer / service access) via deleteAccessRequest, but does not write a corresponding Activity event.

Manager reject already logs via StructuredActivityService.logRejectAccess. Consumer cancel skips that path.

Observed production / repro behaviour

• Gateway Activity still shows: received credentials … (access pending approval)
• Consumers page does not show the request (nothing to approve/deny)
• Searching by the consumer ID finds nothing
• In the keystone DB:
  • GatewayConsumer / ServiceAccess / AccessRequest for that consumer are gone
  • An orphan Activity row remains with refId / filterKey1 = accessRequest:N and filterKey2 = consumer:<id>

Confirmed for:

• Prod Forest Client case: consumer 74EF984C-6629CA40674, accessRequest:3477 (APS-4835 / related DATABC-6973)
• Self-deny repro: consumer 41ABC126-6AC8D000368, accessRequest:3480

This leaves gateway managers with a misleading “pending” signal and no audit of who cancelled or when.

Proposed work (1, 2, 3)

1. Log cancel — On consumer cancel, record Activity (e.g. cancelled access request) via StructuredActivityService, same shape as approve/reject (actor = requestor).
2. Prefer complete over hard-delete — Route cancel through a completed state (same or analogous to manager reject: isComplete + not approved, or an explicit cancelled-by-requestor state) instead of deleting AccessRequest / consumer, so lineage stays queryable and Activity/Consumers stay consistent.
3. Defensive Activity UX — On the Activity read path, detect stale “pending approval” events and present them so they do not look like open work (badge / demote / optional hide). This covers existing orphans and any future missed cancel logs.

Signals to define a stale “pending” Activity case (for #3)

Treat an Activity as stale / no-longer-pending when most or all of the following hold:

• action = received credentials
• context/note indicates access pending approval
• refId / filterKey1 = accessRequest:N and that AccessRequest does not exist
• and/or filterKey2 = consumer:<username> and that GatewayConsumer does not exist
• there is no later approve / reject / cancel Activity for the same accessRequest: or consumer: filter keys

Enrichment can happen in the Activity API/formatting layer and/or UI; intent is presentation only for #3 (not rewriting history).

---

Acceptance Criteria

• Functional format:

  • When a consumer cancels a pending access request, the system should record a cancel Activity (actor, application, consumer, product, environment) visible on the gateway Activity page.
  • When a consumer cancels a pending access request, the system should not leave the request looking “pending approval” with no corresponding Consumers entry (prefer completing/rejecting the request over hard-delete of lineage rows).
  • When Activity is shown for a gateway, stale “access pending approval” events matching the signals above should be visually distinguished (and optionally demoted/hidden from the default view) so managers do not treat them as open requests.
  • Manager reject behaviour and existing approve/reject Activity logging should remain unchanged.

• Other considerations:

  • Cancel Activity should use the same structured Activity pattern (filterKey1/filterKey2/context) as approve/reject for consistent filtering.
  • Existing orphan pending Activities (no backfill required) should still benefit from the defensive UX (Add missing compliance audit file #3).
  • Notify-on-cancel email for gateway managers is optional / follow-up, not required for this story.

---

Business Value (Optional)

Gateway managers currently receive email and see Activity for new requests, then lose the ability to act on or understand cancelled ones. Closing that gap reduces support load and restores trust in Gateway Activity as an audit trail.

---

Assumptions (Optional)

• “Cancel” means the developer/requestor deleting a pending request from the applications/access UI (deleteAccessRequest), not manager reject.
• Hard-delete of Kong consumer credentials on cancel may still be required for security; the ask is to preserve Portal lineage / Activity, not necessarily keep live gateway credentials.

---

Out of Scope (Optional)

• One-off DB backfill / synthetic cancel rows for historical orphans
• Restoring approve/deny actions on the Gateway Activity page (separate regression noted in APS-4835)
• Email notification to gateway managers on cancel (optional follow-up)

---

Constraints (Optional)

• Prefer extending existing StructuredActivityService and access-request workflow rather than a new activity subsystem.
• Read-path stale detection (Add missing compliance audit file #3) must remain cheap (lookup by accessRequest id / consumer username already present on Activity filter keys).