>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618835. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !300 >>> <h3>Problem/Motivation</h3> <p>A duplication audit over the whole project compared 2,527 non-test method bodies in <code>src</code> and the submodules, hashing each one normalized and again with variables, strings and numbers blinded. It found 53 groups of byte-identical bodies and 84 groups sharing a shape. Excluding framework boilerplate, where <code>create()</code> factories and list builder headers share a shape but no content, and excluding bodies under six significant lines, 10 identical and 23 same-shape groups remain. Those reduce to five concepts that are genuinely written more than once. Each is a rule a later fix would have to find twice.</p> <p><strong>A managers form that copies its own base.</strong> <code>ScopeManagersFormBase</code> exists precisely to carry the grant table, the add field group, the validation and the removal, and it abstracts four hooks: <code>target()</code>, <code>grantMatch()</code>, <code>createDefaults()</code> and <code>emptyMessage()</code>. <code>TenantManagersForm</code> and <code>TypeManagersForm</code> use it and are 100 lines each. <code>ResourceManagersForm</code> extends <code>FormBase</code> instead and reimplements the lot at 269 lines: <code>removeSubmit()</code> is byte-identical to the base, and <code>buildForm()</code>, <code>submitForm()</code>, <code>addValidate()</code> and <code>addSubmit()</code> mirror it with no difference that the four hooks do not already express. Only two things actually differ between them, and both are wording: the copy names the resource in its duplicate-grant error and in the user field's description, where the base is generic. Everything else is the same query and the same form built twice, so a correction to either side reaches only that side.</p> <p><strong>Two signed tokens with one implementation between them.</strong> <code>CancelToken::open()</code> in yoyaku_order and <code>TicketDownloadToken::open()</code> in yoyaku_ticket are byte-identical over 14 lines: the same three-part split, the same expiry comparison, the same <code>hash_equals()</code> check, with the signing halves matching too. A correction to the token format or the expiry handling has to be made in two modules that do not reference each other.</p> <p><strong>Two domains forms with no shared base.</strong> <code>TenantDomainsForm</code> (205 lines) and <code>BookingChannelDomainsForm</code> (231 lines) have byte-identical <code>submittedDomainIds()</code> and <code>domains()</code>, and their <code>getFormId()</code>, <code>title()</code>, <code>buildForm()</code>, <code>validateForm()</code> and <code>submitForm()</code> differ only in the entity they hang off.</p> <p><strong>Seven storage schema classes that add their table keys the same way.</strong> Each one takes core's schema, finds the entity's own table in it, and adds what that type needs, and each writes those three steps out again. <code>BookingStorageSchema</code> and <code>BookingTransactionStorageSchema</code> have byte-identical <code>getEntitySchema()</code> bodies and already document an <code>indexes()</code> hook meant for exactly this; four more add a single unique key rather than indexes, and the slot's adds one to its data table. Only the keys, and which table they belong on, actually differ.</p> <p><strong>Row accessors written once per entity type.</strong> <code>label()</code> is byte-identical across the three allotment row entities. <code>getWeight()</code> is hand-written as the same content-entity read in 11 classes, which is the module's widest single repetition, <code>getAllotmentId()</code> in 8 and <code>getResourceId()</code> in 5, each time as the same read of the same field name.</p> <h3>Proposed resolution</h3> <p>Give each of the five one owner. Make <code>ResourceManagersForm</code> extend <code>ScopeManagersFormBase</code> and supply the four hooks, with two further hooks on the base so each scope keeps its own wording. Move the signed token into one class the two submodules share, keeping each module's own key and lifetime. Give the two domains forms a common base holding the form's shape and the storage, and leave validation in each of them, because which pairings are contradictory is a rule about the thing being bound. Add a trait so all seven schema classes state only their indexes, their unique keys, and which of the entity's tables those belong on. Add traits for the weight, allotment and resource accessors, and let the three allotment rows share their <code>label()</code>.</p> <h3>Remaining tasks</h3> <p>The engine-side findings from the same audit are a separate issue, because they are about <code>BookingManager</code> reusing readers it already injects rather than about copied classes.</p> <h3>User interface changes</h3> <p>None intended. The strings the copies carried are kept, so the resource managers form keeps its own empty-table text and field descriptions through the base hooks rather than losing them.</p> <h3>API changes</h3> <p>None. Nothing listed here is public API: the touched methods are protected or private, and the interfaces the accessors satisfy do not move.</p> <h3>Data model changes</h3> <p>None. The storage schema change moves where the keys are declared, not the keys themselves, so the tables are unchanged.</p> <p>AI-Generated: Yes (Claude Code was used to run the duplication audit behind this issue, to help draft this summary, and to write the code and tests on the merge request. The linters and the named test classes were run before it was pushed; a maintainer reviews it before it merges.)</p>