>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3592048. --> Reported by: [mxr576](https://www.drupal.org/user/315522) Related to !19 !14 >>> <h2>Problem Statement</h2> <p>Currently, the management of <code>llms_txt_section</code> entities is tied strictly to the global <code>administer llms.txt configuration</code> permission. This forces an all-or-nothing access model where a user must have full administrative access to the global configuration in order to perform basic CRUDL (Create, Read, Update, Delete, List) operations on individual sections. This lack of granularity prevents administrators from delegating section management to content editors or other roles without inadvertently granting them access to the global configuration settings that stored in configuration and changing them leads to configuration overrides.</p> <h2>Solution</h2> <p>Introduce a new, dedicated permission <code>administer llms.txt sections</code> that allows authorized users to perform CRUDL operations on <code>llms_txt_section</code> entities. The existing <code>administer llms.txt configuration</code> permission will continue to provide access, effectively creating an "OR" access condition (either global configuration permission OR specific section management permission). This enables site builders to grant section management capabilities to specific roles while keeping the global configuration locked down.</p> <h2>User Stories</h2> <ol> <li>As a site administrator, I want to create a new role for content editors, so that they can manage LLMS.txt sections without having full administrative access to the global configuration.</li> <li>As a content editor with the <code>administer llms.txt sections</code> permission, I want to create new <code>llms_txt_section</code> entities, so that I can add new content to the LLMS.txt file.</li> <li>As a content editor, I want to update existing <code>llms_txt_section</code> entities, so that I can keep the AI-readable content up to date.</li> <li>As a content editor, I want to delete outdated <code>llms_txt_section</code> entities, so that I can maintain the cleanliness of the LLMS.txt content.</li> <li>As a content editor, I want to view a list of all existing <code>llms_txt_section</code> entities, so that I can see the structure of the LLMS.txt content.</li> <li>As a site administrator, I want to retain the ability to manage both the global <code>llms.txt</code> configuration and all individual sections with my existing permission, so that my workflow remains uninterrupted.</li> <li>As a security-conscious administrator, I want to restrict access to the <code>/admin/content/llms-txt</code> configuration form to only those with the <code>administer llms.txt configuration</code> permission, so that sensitive global settings remain protected.</li> </ol> <h2>Implementation Decisions</h2> <ul> <li><strong>Permission Definition</strong>: A new permission <code>administer llms.txt sections</code> will be added to the module's permission definitions.</li> <li><strong>Entity Access Control Handler Modification</strong>: The <code>LlmsTxtSectionAccessHandler</code> will be updated to override <code>checkAccess()</code> and <code>checkCreateAccess()</code>.</li> <li><strong>Access Logic</strong>: The access handler will implement a combined check that returns <code>AccessResult::allowed()</code> if the user has either <code>administer llms.txt configuration</code> OR <code>administer llms.txt sections</code>.</li> <li><strong>Entity Annotation Integrity</strong>: The <code>admin_permission</code> attribute in the <code>LlmsTxtSection</code> entity annotation will remain set to <code>administer llms.txt configuration</code>. This ensures the existing route system, which relies on this annotation to define access requirements, correctly invokes the <code>LlmsTxtSectionAccessHandler</code> for all section-related routes.</li> <li><strong>Independence of Global Config</strong>: The <code>llms_txt.llms_txt_config</code> route will remain associated with the <code>administer llms.txt configuration</code> permission, ensuring that the new <code>administer llms.txt sections</code> permission does not grant unauthorized access to global configuration settings.</li> </ul> <h2>Testing Decisions</h2> <ul> <li><strong>Test Focus</strong>: Tests will focus on verifying external access behavior rather than internal implementation details. We will validate that users with only the new permission can perform CRUDL actions on sections but are denied access to the global configuration route.</li> <li><strong>Tested Modules</strong>: <ul> <li><code>LlmsTxtSectionAccessHandler</code>: This is the primary module for modification and requires thorough testing to ensure the "OR" permission logic works correctly across all CRUDL operations.</li> </ul> </li> <li><strong>Prior Art</strong>: The module's existing test suite (using PHPUnit) will serve as the reference for test structure, specifically looking for existing kernel tests that simulate user sessions with different permissions to verify entity access.</li> </ul> <h2>Out of Scope</h2> <ul> <li>Changes to the <code>/llms.txt</code> public-facing output (this remains unchanged).</li> <li>Changes to the <code>LlmsTxtConfigForm</code> or its associated route.</li> <li>Implementation of field-level access control within sections.</li> </ul> <h2>Further Notes</h2> <ul> <li>By leveraging the existing <code>AdminHtmlRouteProvider</code> behavior and simply extending the access handler, we minimize the surface area of changes, reducing the risk of introducing regressions in routing or entity management.</li> </ul>