Requester-facing read-only detail view for a process instance

The "My requests" page (orchestra_ui, issues #3611212, #3611235, #3611246) lists a requester own instances as cards, but offers no way to open one. A read-only view-detail affordance was intentionally left out of the initial version (see the note in MyRequestsController) because a per-request detail is source-specific.

Problem

The person who started a run wants to open a single request and see it in requester-appropriate terms: where it stands and what they submitted. The admin trace (tokens, nodes, incidents) is not requester-appropriate, so this needs its own read-only surface.

Why this is not trivial

"The request detail" depends on what seeded the instance. A webform submission is naturally shown as a read-only submission review; a booking is shown as booking details. So there is no single generic detail page: it needs either a pluggable per-source renderer, or delegation to the source entity own canonical view.

Approaches

• Delegate: link each card to the source entity own read-only view (for example the webform submission page), gated by initiator access. Minimal, but couples the page to each source.
• Pluggable detail renderer: a tagged-service seam mirroring the status-provider seam, where each source module contributes how to render its instance detail. Cleanest and most consistent with the module design.
• Generic milestone timeline: a source-agnostic page showing the authored statuses as a timeline plus the current step, with no source data. Ships generically and extends the Status feature directly.

Suggested direction: the generic timeline as the first deliverable, with the pluggable renderer added as the extension point for source data.

Source identification

To dispatch to a source renderer, an instance must record what seeded it. The correlation key is not enough on its own: it is an optional, non-unique business key meant for external event correlation (a payment return, an inbound message), so it may be empty and need not map to a loadable entity.

Proposed: capture an explicit source binding at start, as a source provider id plus a source reference, and add a tagged SourceProvider service seam (keyed by that provider id, mirroring the instance-status provider) that can load, access-check and render or link the source for a given reference. A source module (webform, a booking module) registers its provider. The correlation key may serve as an opportunistic reference where a provider already sets it to the source id, but the binding should not depend on it.

Decisions and scope

• Access: initiator-only, reusing the existing "view own process instances" permission; the route would carry the instance (for example /orchestra/my-requests/{orchestra_instance}) with an access check that the current user is the initiator.
• A status history is a prerequisite for a timeline: today the collector resolves only the current node status, not past ones. A timeline implies either recording status transitions (audit-style) or deriving them from the token history combined with each node status config. This should be scoped before building the timeline.
• Source-data rendering: define the SourceProvider seam (or the delegation target) and its access rules.

Related

The deferred "modify by link" card action is a separate follow-up (it needs the interaction to store a uid identifying the intended user, since a bearer link cannot prove the viewer is the intended actor). It should not be conflated with this read-only detail view.