>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3626846. --> Reported by: [jrockowitz](https://www.drupal.org/user/371407) >>> <p>AI-assisted by Codex</p> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Entity Usage Root 1.0.0-alpha1 provides the core relationship storage, rebuild, and reporting functionality. The remaining work is spread across test coverage, generated Views user experience, architectural cleanup, and beta readiness. A small roadmap is needed so those changes can be handled as focused child issues without expanding the base module unnecessarily.</p> <p>This plan also needs to decide whether generated Views support belongs in an optional submodule. The generator may be optional, but generated reports currently rely on runtime Views integration for some entity types. Therefore, disabling a Views integration module after generation should not be promised until that dependency is tested and resolved.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Use this issue as the parent plan for the 1.0.x release. Create focused child issues for the following workstreams.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h4>1. Alpha stabilization</h4> <ul> <li>Complete <a href="https://www.drupal.org/project/entity_usage_root/issues/3626516">#3626516</a> with end-to-end functional coverage and regression tests for the lifecycle bugs it exposed.</li> <li>Make the supported PHPUnit and code-review checks pass.</li> <li>Make generated field, table, View, route, and local-task identifiers length-safe and collision-resistant, including an update path for existing installations.</li> </ul> <h4>2. Batch update UX</h4> <ul> <li>Consider aligning the rebuild tab, page title, route, description, and action label with Entity Usage's <em>Batch Update</em> terminology where practical.</li> <li>Show Entity Usage configuration and data prerequisites before starting the batch operation.</li> </ul> <h4>3. Views integration and generated report UX</h4> <ul> <li>Evaluate an optional <code>entity_usage_root_views</code> submodule that owns generated Views, local tasks, report-link administration, and View-generation configuration.</li> <li>Separate generation-time responsibilities from runtime requirements such as <code>hook_views_data_alter()</code>.</li> <li>Document and test whether the optional module must remain enabled while generated reports are used, or whether a generate-then-disable workflow can be supported safely.</li> <li>Make View generation independently configurable and testable without adding a second replacement for the core Views UI.</li> <li>Consider renaming generated View and local-task titles to <em>@root entity label usage</em>, for example <em>Content usage</em> within the Media section.</li> <li>Use a matching path pattern such as <code>/admin/content/{leaf entity type}/{root entity type}-usage</code>, for example <code>/admin/content/media/node-usage</code>.</li> <li>Rename <em>Thumbnail</em> to <em>Media thumbnail</em> when the leaf entity is Media.</li> <li>Rename <em>Edit @entity</em> columns to <em>@entity operations</em>.</li> <li>Determine whether the standalone <code>/admin/content/entity-usage-root</code> overview is still needed. If it is removed, add configured report links and any explicit generate/update action to the settings or Views integration page, including reports for leaf entity types without collection pages.</li> <li>Add an interface for <code>EntityUsageRootViewBuilder</code> or its replacement service.</li> <li>Consider changing <code>EntityUsageRootViewBuilder</code> to <code>EntityUsageRootViewsBuilder</code> to avoid confusion with Drupal entity view builders.</li> </ul> <h4>4. Beta readiness and internal cleanup</h4> <ul> <li>Define and test report permissions and entity-access behavior.</li> <li>Cover direct, paragraph-mediated, Paragraph Library Item, multiple-root, revision, deletion, configuration-change, and large-rebuild scenarios.</li> <li>Split unrelated hook implementations into focused services, including cron processing and Views data alteration, so entity hook execution does not construct unrelated dependencies.</li> <li>Update documentation after the Views and batch-update decisions are complete.</li> </ul> <h4>Deferred until there is a demonstrated use case</h4> <ul> <li>A combined cross-entity usage report.</li> <li>Alternative table or entity storage.</li> <li>Additional styling or broad extension APIs without a concrete consumer.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>Generated report titles, paths, column labels, and batch-update terminology may change. The standalone report overview may move into the configuration or optional Views integration UI.</p> <h3 id="summary-api-changes">API changes</h3> <p>An interface will be added for the View-builder service. The service may be renamed to <code>EntityUsageRootViewsBuilder</code>. A Views submodule and focused hook services may be introduced after the architecture decision. Exact service names and compatibility requirements should be finalized in child issues.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>No relationship-storage redesign is planned. Length-safe identifiers may require an update path for existing base fields, tables, and generated View configuration.</p>