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_actions service and build both surfaces from it. Add an Operations field 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 PendingActionsFinder to the base module, which is where its eight dependencies already live, and add an instance Act link field 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

Command icon 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

mably created an issue. See original summary.

mably’s picture

Issue summary: View changes
mably’s picture

Status: Active » Needs review

MR 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.

  • mably committed e2d5237d on 1.x
    fix: #3613841 Make the personal task and request views usable in place...
mably’s picture

Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.