>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3620609. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !426 >>> <h3>Problem</h3> <p>A family of cross-module defects: schema types living in a module that no longer owns the plugin they type, shipped configuration gated on another module's permission, a controller redirecting to routes it has no claim on, and shipped workflows that declare no dependency on the modules providing their node types.</p> <p>7 findings: 5 high, 2 med.</p> <h3>High severity</h3> <h4>Every shipped workflow config omits the module dependency for the plugins its nodes use</h4> <p><strong>Where:</strong> <code>modules/orchestra_examples/config/install/orchestra.orchestra_workflow.example_eca_sync.yml:3-6</code> and <code>:18-24</code>, the same shape in all eleven shipped example workflows. Root cause: <code>src/Entity/Workflow.php:304-325</code>.</p> <p>A workflow node's <code>type</code>, its assignment plugins, its join and split plugins, its timer actions and its flow-condition plugins are all plugin ids owned by other modules, and neither the shipped YAML nor <code>calculateDependencies()</code> records a module dependency for any of them. Searching the whole repository for a module dependency being added returns <strong>zero hits</strong>, and there is no uninstall validator anywhere in the tree. Contrast the sibling files in the very same directory, which get this right: the shipped ECA model declares its module dependencies because it uses an orchestra_eca action. So orchestra_inbox can be uninstalled with no warning while workflows still use its node types, and the branch dead-letters on a plugin-not-found at the next advance.</p> <h4>Three schema types are stranded in a module that no longer owns them, under a fully validatable entity</h4> <p><strong>Where:</strong> <code>modules/orchestra_inbox/config/schema/orchestra_inbox.schema.yml:1-40</code></p> <p><code>Reassign</code> and <code>Unclaim</code> now live in <strong>core</strong> (<code>src/Plugin/TimeoutAction/Reassign.php</code>, <code>Unclaim.php</code>; there is no <code>modules/orchestra_inbox/src/Plugin/TimeoutAction/</code> directory at all), and <code>outcome_labels</code> is read by orchestra, orchestra_interaction and orchestra_ui, never by orchestra_inbox. All three schema types still live in orchestra_inbox, and the file's comments still assert the premise twice: "The reassign timeout action ships in this module, so its settings schema lives here too (not in orchestra core)" and "The unclaim timeout action ships in this module". The workflow config entity is declared fully validatable (<code>config/schema/orchestra.schema.yml:148</code>), so a key with no schema type is a validation failure rather than a silent pass. A schema-ownership pass over every plugin family and every node-setting key reports exactly these three and nothing else in the tree.</p> <h4>The two timeout actions are usable without orchestra_inbox, and their own docblocks say so</h4> <p><strong>Where:</strong> <code>src/Plugin/TimeoutAction/Reassign.php</code>, <code>src/Plugin/TimeoutAction/Unclaim.php</code>, <code>modules/orchestra_inbox/config/schema/orchestra_inbox.schema.yml:12-38</code></p> <p>Both plugins depend only on <code>orchestra.work_item_manager</code>, a <strong>core</strong> service, and orchestra_inbox is not a dependency of orchestra or of orchestra_ui. So both actions are offered and usable on a site without orchestra_inbox, and the config they write has no schema: a node's timeout settings are typed by the action id, which resolves to nothing. The two plugin docblocks make the opposite promise explicitly, "depends only on the core TimeoutAction plugin type, with no cross-submodule dependency".</p> <h4>A money operation redirects to a route that does not exist, and to one only an undeclared dependency provides</h4> <p><strong>Where:</strong> <code>modules/orchestra_payment/src/Controller/PaymentOperationsController.php:94-99</code></p> <p>Two defects in five lines, on the operator action that marks an in-flight payment paid or failed (route <code>orchestra_payment.token_payment_outcome</code>, <code>administer orchestra</code> plus CSRF). First, <code>entity.orchestra_instance.collection</code> <strong>does not exist anywhere in the codebase</strong>: <code>ProcessInstance</code>'s entity attribute declares no links and no route provider, no routing file declares that name, and this line is its only mention in the entire tree. The docblock above it promises "or the instances list", a list that was never built. Second, <code>entity.orchestra_instance.canonical</code> is declared by orchestra_ui (<code>modules/orchestra_ui/orchestra_ui.routing.yml:82</code>), and orchestra_payment depends on orchestra, orchestra_interaction and kessai only. Both resolve through <code>Url::fromRoute()</code>, which throws for an unknown route: on a site without orchestra_ui the money operation succeeds and then 500s on the redirect, so it looks to the operator as though it failed. The test that covers this controller passes only because its module list includes orchestra_ui, which the code under test does not declare.</p> <h4>The shipped requester view is gated on a permission no module this view depends on declares</h4> <p><strong>Where:</strong> <code>modules/orchestra_views/config/optional/views.view.my_workflow_instances.yml:3-7</code> and <code>:240-243</code></p> <p><code>view own orchestra instances</code> is declared <strong>only</strong> in <code>modules/orchestra_ui/orchestra_ui.permissions.yml:1</code>. <code>orchestra_views.info.yml</code> does not depend on orchestra_ui, deliberately, and core's permission access plugin has no dependency calculation, so Drupal never notices. The optional config therefore installs on an orchestra_ui-less site with an access plugin naming a permission that does not exist, which closes the requester dashboard to everyone but user 1 and cannot even be granted, since the role form only offers permissions a module defines. Shipped config cannot guard at runtime the way code can, which is what separates this from the deliberate, guarded optional integrations elsewhere in the module.</p> <h3>The rest</h3> <p>One line each: what it is, and where. The failing scenario and the fix for each are carried by its own commit.</p> <ul> <li><em>med</em> Without modeler_api the menu section lands in the <em>tools</em> menu, so the overview page it exists to feed renders empty. <code>modules/orchestra_views/orchestra_views.links.menu.yml:12-19</code> with <code>modules/orchestra_views/orchestra_views.routing.yml:1-14</code></li> <li><em>med</em> <code>views.filter.orchestra_workflow</code> has no config schema, so its multi-value setting validates as a plain string. <code>modules/orchestra_views/config/schema/orchestra_views.views.schema.yml</code> (absent entry), against <code>modules/orchestra_views/src/Hook/OrchestraViewsHooks.php:82</code></li> </ul> <h3>Remaining tasks</h3> <ul> <li>Move the three stranded schema types into core's schema and delete the two false ownership comments.</li> <li>Make shipped workflows and <code>calculateDependencies()</code> record the module dependencies their plugin ids imply, and add an uninstall validator.</li> <li>Resolve the payment controller's redirect targets through the route provider, and delete the reference to the non-existent collection route.</li> <li>Add or correct a test for every behaviour change, and make sure no test's module list hides a missing dependency.</li> <li>Run every linter and the affected test classes before pushing.</li> </ul> <p>This issue summary was drafted with the assistance of an AI agent (Claude). The analysis and the wording were reviewed by me before posting, and accountability for the content is mine.</p>