>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3603015. --> Reported by: [pfrenssen](https://www.drupal.org/user/382067) Related to !97 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Elements are exposed off the built form, and the shared element walker <code>WebformElements</code> drops any child whose <code>#access</code> is denied (see <code>WebformElements::isAccessAllowed()</code>). That is what keeps disabled composite sub-properties out of the schema, the behaviour discussed in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/graphql_webform/-/work_items/3571739" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/graphql_webform/-/work_items/3571739</a></span>.</p> <p>The <code>webform_address</code> element does not go through that walker. Its <code>items</code> field is resolved by a dedicated <code>WebformAddressCompositeItems</code> producer that iterates <code>#webform_composite_elements</code> and returns every entry that is simply <code>!empty()</code>, with no access check:</p> <pre><pre>foreach ($elementKeys as $key) {<br>&nbsp; if (!empty($element[$key])) {<br>&nbsp;&nbsp;&nbsp; $elements[] = $element[$key];<br>&nbsp; }<br>}</pre></pre><p>So a disabled address sub-property (for example a field configured with <code>#state_province__access: false</code>) still carries <code>#access =&amp;gt; FALSE</code> in the built composite and is returned through <code>items</code>, while the equivalent sub-property on a name, contact or custom composite is correctly omitted. The address element is the one composite that leaks disabled sub-properties.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Add a <code>webform_address</code> element to a webform and disable one of its sub-elements (e.g. set State/Province access off).</li> <li>Query the form and read the address element's <code>items</code>.</li> <li>The disabled sub-element is present in <code>items</code>, even though disabling the same sub-element on any other composite hides it.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Apply the same access filtering to the address composite that every other composite already gets. Either reuse the access check from <code>WebformElements</code> inside <code>WebformAddressCompositeItems</code>, or route the address element's children through the shared walker so there is a single place that decides element visibility.</p> <p>Extend the test webform's <code>webform_address</code> element with a disabled sub-element and assert it is absent from <code>items</code>, so the behaviour is pinned and matches the other composites.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Filter denied <code>#access</code> sub-elements in the address resolver (or delegate to the shared walker).</li> <li>Add a disabled sub-element to the address element in the test fixture.</li> <li>Add coverage asserting the disabled address sub-property is omitted from <code>items</code>.</li> <li>Run phpunit / phpcs / phpstan.</li> </ul> <h3 id="summary-api-changes">API changes</h3> <p>Disabled address sub-properties will no longer be returned by the address element's <code>items</code> field, bringing it in line with all other composites. This is a correctness fix to resolver behaviour, not a schema/SDL surface change, so it does not need a change record; the GraphQL types and fields are unchanged.</p> <h3 id="summary-release-notes">Release notes snippet</h3> <p>The address element now hides disabled sub-properties from its <code>items</code> field, matching the behaviour of all other composite elements.</p>