>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3608275. --> Reported by: [lisa.rae](https://www.drupal.org/user/1223730) Related to !1 >>> <h2>Summary</h2> <p> This adds a permission gate that was part of the module's original design<br> intent but was never implemented, and fixes a persistence mismatch between<br> the admin-facing settings form and the code paths that actually enforce<br> limits. Both issues were found while debugging the field widget's counter<br> not rendering in a downstream consumer module. </p> <h2>Problem 1: no permission gate on role eligibility</h2> <p> The module's intent from the start was that a role must hold a specific<br> permission before an administrator can configure a role-based limit for<br> it &mdash; a safeguard against accidentally capping a role (a built-in<br> role, or an unrelated custom role) with no deliberate opt-in. This gate<br> did not exist anywhere in the codebase: no<br> <code>role_aware_maxlength.permissions.yml</code>, and no check anywhere<br> in <code>RoleLimitResolver</code> or the settings form. </p> <h2>Problem 2: settings form persists to the wrong storage location</h2> <p> <code>hook_field_widget_third_party_settings_form()</code> builds the<br> admin UI for configuring limits, embedded in the field widget's own<br> settings on "Manage form display". Field UI's submit handling<br> always persists that form's values to the <strong>widget's</strong><br> third-party settings &mdash; this is a structural property of how Field<br> UI processes entity form display saves, not something a hook<br> implementation can redirect. </p> <p> However, both the field widget's own rendering<br> (<code>RoleAwareMaxlengthWidget::formElement()</code>) and the server-side<br> constraint (<code>RoleAwareMaxlengthConstraintValidator</code>) read<br> limits from the <strong>field definition's</strong> third-party settings<br> instead &mdash; deliberately, so that enforcement works regardless of<br> which widget, form, or non-form code path (REST, migrations, a custom<br> compose UI) creates the content. The two halves of the module were<br> reading from two different, unsynchronized locations. An administrator<br> filling in the settings form would see their values saved, but neither<br> the counter nor server-side enforcement would ever reflect them. </p> <h2>Proposed resolution</h2> <h3>1. New permission: <code>role_aware_maxlength</code></h3> <p> Added <code>role_aware_maxlength.permissions.yml</code>. This is<br> deliberately not an "administer" permission &mdash; it grants no<br> access to configure anything. It marks a role as <em>eligible</em> to have<br> a limit applied to it at all. </p> <h3>2. <code>RoleEligibilityCheckerInterface</code> / <code>RoleEligibilityChecker</code></h3> <p> A small, single-method service (<code>isEligible(string $roleId): bool</code>)<br> backed by <code>user_role</code> entity storage, checking<br> <code>$role-&amp;gt;hasPermission('role_aware_maxlength')</code>. Extracted as<br> its own interface/service rather than folded directly into<br> <code>RoleLimitResolver</code>, for the reason below. </p> <h3>3. <code>RoleLimitResolver</code> updated, backward-compatibly</h3> <p> <code>RoleLimitResolver</code> was deliberately dependency-free &mdash;<br> its own docblock calls this out as a design property, and its full unit<br> test suite constructs it with zero arguments. Injecting<br> <code>EntityTypeManagerInterface</code> directly to check permissions<br> would have broken that and forced every existing test to start mocking<br> storage. </p> <p> Instead, the constructor now accepts an <em>optional</em>, nullable<br> <code>RoleEligibilityCheckerInterface</code>: </p> <pre><pre>public function __construct(<br>&nbsp; private readonly ?RoleEligibilityCheckerInterface $eligibilityChecker = NULL,<br>) {}</pre></pre><p> Inside <code>resolve()</code>, a role's configured limit is skipped if a<br> checker is present and reports the role ineligible: </p> <pre><pre>if ($this-&amp;gt;eligibilityChecker !== NULL &amp;amp;&amp;amp; !$this-&amp;gt;eligibilityChecker-&amp;gt;isEligible($roleId)) {<br>&nbsp; continue;<br>}</pre></pre><p> This check runs at <em>resolution time</em>, not just at config-save<br> time &mdash; so revoking the permission from a role immediately stops any<br> previously-configured limit for that role from being enforced. Stale<br> <code>role_limits</code> config left behind after a permission change<br> cannot silently reactivate. All 9 pre-existing unit tests are unaffected;<br> 3 new tests cover the gating behaviour specifically. </p> <h3>4. Settings form filtered to eligible roles</h3> <p> <code>hook_field_widget_third_party_settings_form()</code> now only<br> offers role-limit fields for roles that currently hold the permission,<br> via the same <code>RoleEligibilityCheckerInterface</code> service. If no<br> role is currently eligible, the form shows a message linking to the<br> permissions page rather than an empty section. </p> <h3>5. <code>hook_entity_presave()</code> syncs widget-level settings to the field</h3> <p> Added a new hook, implemented for <code>EntityFormDisplayInterface</code><br> entities. On every entity form display save, for each component carrying<br> <code>role_aware_maxlength</code> third-party settings, the corresponding<br> <code>FieldConfig</code> is loaded and its own third-party settings are<br> updated (or unset, if the widget-level settings are now empty) to match. </p> <p> This keeps Field UI's native persistence target (widget-level, where<br> admins actually interact with the settings form) and the module's actual<br> enforcement mechanism (field-level) in sync, without requiring any<br> change to how site builders configure the module &mdash; still just the<br> "Manage form display" settings form, no custom code. </p> <h2>Files changed</h2> <ul> <li><code>role_aware_maxlength.permissions.yml</code> &mdash; new</li> <li><code>src/Service/RoleEligibilityCheckerInterface.php</code> &mdash; new</li> <li><code>src/Service/RoleEligibilityChecker.php</code> &mdash; new</li> <li><code>src/Service/RoleLimitResolver.php</code> &mdash; optional checker dependency, gating logic in <code>resolve()</code></li> <li><code>role_aware_maxlength.services.yml</code> &mdash; registers the checker service, wires it into the resolver</li> <li><code>role_aware_maxlength.module</code> &mdash; role list filtered to eligible roles in the settings form; new <code>hook_entity_presave()</code></li> <li><code>tests/src/Unit/RoleLimitResolverTest.php</code> &mdash; 3 new tests for the gating behaviour</li> </ul> <h2>Remaining risk / needs verification</h2> <p> <code>hook_entity_presave()</code> has no test coverage yet &mdash; there<br> is no kernel test exercising "save an entity form display, confirm<br> the field config picked up the settings." This is the most likely<br> place for a surprise. A kernel test covering this save-and-sync path<br> should land before this is considered fully verified. </p>