>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3626929. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !400 >>> <h3>Problem/Motivation</h3> <p>A site with several tenants gets the tenant boundary backwards on both sides.</p> <ul> <li><strong>Lists show every tenant's records.</strong> On tenant A's domain, the slot overview, the resource list and every other access-checked list return tenant B's rows too, for administrators and everyone else: nothing adds the current tenant to a list query. Opening one of those rows is then refused, so an operator sees records they cannot open.</li> <li><strong>An administrator is refused another tenant's records.</strong> #3625422 made <code>YoyakuAccessControlHandler</code> refuse <code>administer yoyaku</code> any record outside the current tenant, and <code>OrderAccessControlHandler</code> limits deleting an order to the current tenant, administrators included. But <code>administer yoyaku</code> is the root of the booking engine, a <code>restrict access</code> permission for trusted people, and should reach everything whatever the tenant. The per-record check also had to be repeated by every handler replacing the engine's, and <code>yoyaku_manager</code>'s did not (#3626905, closed in favour of this issue).</li> </ul> <h3>Steps to reproduce</h3> <ol> <li>Create two tenants and a slot in each. As an administrator, open the slot overview on the first tenant's domain: both slots are listed.</li> <li>Open the second tenant's slot from that list: access is denied.</li> </ol> <h3>Proposed resolution</h3> <ul> <li>Every list of a tenant-bearing entity type (a type carrying the <code>yoyaku_tenant</code> entity key) shows only the current tenant's records, plus the ones shared by every tenant where the type allows that, for everyone, administrators included. A list is a View of such a type, or an access-checked entity query its code tags as one: the collections, the overviews, the resources a filter offers. A record's own children follow the record (a resource's tabs, a slot's bookings), and code counting or checking rows reads them all: narrowing every access-checked query would hand it part of them. A single-tenant site is unchanged, since every row carries its one tenant.</li> <li><code>administer yoyaku</code> reaches every record of every tenant: the per-record tenant check comes off the engine's access handler and the order's delete rule. What an order or a booking may become stays as it is (an order is deleted only once archived or canceled, and a booking that still counts is not deleted).</li> <li>A tenant-bound administrator is a later, separate permission (<em>administer tenant</em>): the same rights, within one tenant. Until it exists, <code>administer yoyaku</code> is given to people trusted with every tenant.</li> </ul> <h3>Remaining tasks</h3> <p>Review the <a href="https://git.drupalcode.org/project/yoyaku/-/merge_requests/400">merge request</a>.</p> <h3>User interface changes</h3> <p>Lists show only the current tenant's records. An administrator can open and change any tenant's record.</p> <h3>API changes</h3> <p><code>YoyakuAccessControlHandler</code> no longer refuses an administrator another tenant's record. Views of tenant-bearing entity types, and entity queries tagged <code>TenantListHooks::LIST_TAG</code>, are filtered by the current tenant.</p> <h3>Release notes</h3> <p><code>administer yoyaku</code> is site-wide: give it only to people trusted with every tenant.</p> <p>AI-Generated: Yes (Claude Code was used to draft this issue. I reviewed it before posting.)</p>