>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3624458. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !517 >>> <h3>Problem</h3> <p>A subprocess child takes its parent run's initiator, unconditionally. Nothing on the node configures it, and the engine has no way to be told otherwise: start() reads a NULL initiator as "the caller did not say" and then inherits, so "nobody" cannot be expressed at all.</p> <p>That matters because an initiator is not only attribution. InstanceReadAccessCheck short-circuits on it, before the read-access scope is consulted, so whoever a run is attributed to can read it. A workflow whose child does internal work - a staff-only review, a supplier negotiation, a fraud check - therefore hands that child's page to whoever filed the parent request, and an author has no way to stop it.</p> <p>The opposite case exists too: a child that genuinely belongs to whoever is acting, rather than to the person the parent belongs to.</p> <h3>Proposed resolution</h3> <p>A per-node setting on both subprocess nodes, the local one and the remote one, with three values and the current behaviour as the default:</p> <ul> <li><strong>Inherit from the parent run</strong> (default): what happens today.</li> <li><strong>The current user</strong>: whoever is acting in the request that advances the parent. Synchronous runs only, and only where a person is acting at all - a queued or cron advance, an API-driven one, and an anonymous link resume each have nobody, and the child then records nobody. Said on the option itself and in the description, because the same workflow would otherwise attribute differently depending on how it is executed.</li> <li><strong>Nobody</strong>: the child belongs to no one, whatever the parent says.</li> </ul> <p>The setting lives once, on the trait both nodes already share for their correlation and state variables, so neither node carries a copy. The values are an InitiatorSource enum, read the way VariableScope already is.</p> <p>The engine stops guessing. SubprocessTask is the only caller that passes a parent token, so the inheritance moves there, and start() records exactly the initiator it is handed. That is what lets "nobody" mean nobody, and it takes a hidden default out of the kernel.</p> <p>Over the wire a name is honoured or the start is refused. A caller without <code>attribute orchestra runs</code>, a login the receiving site has never heard of, and an account it has blocked each refuse the start with nothing created, and the step raises an incident on the parent. Recording nobody and answering with an id instead hands back a run that looks started and is unreadable by the one person it was started for, with nothing said: a caller that does not care whose the run is names nobody, so a caller that named somebody asked for something. The two refusals say different amounts on purpose - without the permission a caller learns nothing about the site's accounts, not even whether the one it named is there, while past it the refusal names the login back, which is what makes it fixable. The name is resolved only where a run is about to be made, so a retry an idempotency key answers is still answered with the run the first ask made.</p> <p>The current user means a person. Cron and the queue worker reach a step with nothing acting, an anonymous link with nobody named, and a step advanced over the API with a set of credentials, which is a machine: one set can serve several people, so recording it would say a machine asked for the work and would hand that account the child to read. Each of those starts the child belonging to nobody.</p> <h3>User interface changes</h3> <p>One new select on the subprocess and remote subprocess nodes, defaulting to the behaviour those nodes have now. Its description says that an initiator is read as ownership, so the choice decides who may read the child run.</p> <h3>API changes</h3> <p>ProcessControlInterface::start() no longer fills a NULL initiator from the parent; the caller decides. The only in-tree caller that passed a parent is the subprocess node, which is updated with it.</p> <p>OrchestraClientInterface::startProcess() refuses an initiator it cannot honour rather than recording nobody, so the HTTP start answers 422 where it used to answer 201 with a run attributed to no one.</p> <h3>Data model changes</h3> <p>None. The setting is node configuration, and a workflow that does not carry it reads as inherit.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)</p>