The two personal Views that orchestra_inbox_views and orchestra_views ship, My tasks and My workflow instances, are documented as the Views counterparts of the inbox page and the themed requester page. Neither can stand in for the page it mirrors.
1. The act link misses every family that routes through a pending-action handler
TaskActLink::render() asks the task type plugin for a route:
if (!$plugin instanceof TaskActRouteInterface) { return ''; } ... '#url' => Url::fromRoute($plugin->actRoute(), ['orchestra_work_item' => $task->id()]),
But TaskActRouteInterface is not the seam a task type declares its act surface through, it is an implementation detail of InboxTaskHandler. The general seam is PendingActionHandlerInterface::actUrl(), which is what InboxController::inbox() uses. InteractionTask implements no TaskActRouteInterface and reaches its surface through InteractionTaskActionHandler::actUrl(), so the inbox page links it and the view renders an empty string for it. The same holds for any family shipping its own handler. The field also builds a bare route URL where the inbox wraps it in OrchestraReturn::embed(), so a task opened from a view does not come back to the list.
2. A row offers no actions
An inbox row carries Claim for an unassigned task, the act link, one one-click link per non-guarded outcome, Reassign, and Unclaim / Return to pool, plus the task state and who holds it. The task view carries the act link and nothing else, so even where that link works a pooled task cannot be claimed and an outcome cannot be signaled without opening the task.
The requester view has the same gap: the themed page offers the step waiting on the viewer as its call to action, and the view offers nothing. The service that resolves it, PendingActionsFinder, lives in orchestra_ui, which orchestra_views cannot depend on, so the shipped view cannot carry a field built on it.
3. The shipped rows have no layout
The task view uses an unformatted list of fields with inline labels and ships neither a row template nor CSS, so it renders as a flat run of label-value lines with no separation between rows. The requester view is a table, so it reads as a report of the themed page rather than a replacement for it. Both also show raw machine values where the pages show labels: the task state, the outcome a task was completed with, and an empty Reference where a run carries no correlation key.
Proposed resolution
- Extract the inbox link building into one
orchestra_inbox.task_actionsservice and build both surfaces from it. Add anOperationsfield offering that whole set, honoring the same guards. - Resolve both act links through the family handler, threading the listing on as the return target.
- Move
PendingActionsFinderto the base module, which is where its eight dependencies already live, and add an instanceAct linkfield so the requester view offers the same step the themed page offers, from the same finder. - Ship one shared card row (
orchestra-card-row.html.twig) that every personal list includes, on a card component promoted into the base module, so the lists are usable with no theme work and a theme can still override per view. - Add the missing labeled fields: the task state and the run reference (correlation key, else the run id), the outcome as its authored label, and who holds a task. Render the authored status as its tag and the engine state as the lifecycle marker, as the themed page does.
- Emit per-step CSS classes on every control offered for a step, so a design can give one step its own icon without replacing a template.
Two side effects worth naming. The status tag orchestra_views already renders carries classes whose stylesheet lived in orchestra_ui, a module it does not depend on, so that tag was unstyled unless the requester UI happened to be enabled; promoting the component fixes it. And the inbox badge used orchestra-status--{state}, which collides with the per-status-id hook class orchestra-status--{id} that StatusTermResolver adds to an authored status; the task state now uses orchestra-task-state--{state}.
None of the shipped view labels were present in the modules' .po files, so the lists were untranslated whatever the interface language; those are added too.
Issue fork orchestra-3613841
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #4
mably commentedMR up. 41 kernel classes across orchestra_inbox, orchestra_views, orchestra_ui and orchestra_interaction_operation pass locally, including a new test module whose task family ships a pending-action handler and declares no act route, which is the shape the old act link rendered nothing for.
The finder move changes a service id, so a consumer follow-up is filed as #3613843: Follow the Orchestra pending-actions finder move to the base module and postponed on this.
Comment #6
mably commented