>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3626903. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !398 >>> <h3>Problem/Motivation</h3> <p>Found by the release audit of 1.x at a81dd9eb. #3626745 and #3626764 made a slot that has bookings and a resource that has slots impossible to delete, as a tenant with records already was. The records around them are still deleted without a question, and each leaves somebody's data pointing at nothing. Every case below was reproduced in a kernel test.</p> <ul> <li><strong>A confirmed booking can be deleted outright.</strong> The bookings list's bulk delete removes it (delete access is granted to <code>administer yoyaku</code> whatever the booking's state, and to a resource manager for the resources they manage). Its order then reads <em>empty</em> although it was paid, and the slot shows the place free again. There is no cancellation, no refund and no word to the booker: the harm #3626745 removed from the slot delete, through the booking's own door. An order is already protected (it can be deleted only once archived or canceled, admins included); the booking is not.</li> <li><strong>A resource tariff that bookings use can be deleted.</strong> The bookings keep a tariff reference to nothing, so their price and label are gone, its slot tariffs stay behind orphaned, and the slot's availability loses the tariff and its quota.</li> <li><strong>A resource type that resources use can be deleted.</strong> Each resource keeps naming the type, and what it takes from the type changes silently: its effective rules (<code>FieldRuleResolver</code>) and the workflow profile it runs (type, then tenant, then site).</li> <li><strong>A tariff class that tariffs name can be deleted.</strong></li> <li><strong>A deleted tariff preset leaves its tariffs and allotments behind</strong>, naming a preset that no longer exists.</li> </ul> <h3>Steps to reproduce</h3> <ol> <li>Hold and confirm a booking. On <em>Administration &rsaquo; Booking &rsaquo; Bookings</em>, tick it and delete it.</li> <li>The booking is gone, its order reads <em>empty</em>, and the slot shows the place free.</li> <li>Likewise delete a resource tariff that a booking uses, a resource type a resource uses, or a tariff class a tariff names: each goes, and what named it stays.</li> </ol> <h3>Proposed resolution</h3> <ul> <li>A booking in a state that still counts (held, confirmed, completed, no-show) cannot be deleted by anyone, admins included, as an order that is not archived or canceled cannot: it is canceled first. In access, like the order's rule, because the order purge deletes the bookings of an archived or draft order from code.</li> <li>A resource tariff, a resource type and a tariff class are refused while other records still name them, in their own <code>preDelete()</code> so every way of deleting them is held to it, and their delete forms say what is left instead of offering a delete that is refused. One count serves every guard: what still names a record, found through the entity reference fields that target its type, as <code>TenantRecords</code> finds what belongs to a tenant.</li> <li>What only describes the record goes with it: a resource tariff's slot tariffs, a preset's tariffs and allotments.</li> </ul> <h3>Remaining tasks</h3> <p>Review the <a href="https://git.drupalcode.org/project/yoyaku/-/merge_requests/398">merge request</a>.</p> <h3>User interface changes</h3> <p>A booking that still counts can no longer be deleted; the bulk delete skips it and says so. The delete forms of a resource tariff, a resource type and a tariff class still in use say what is left, and offer no delete button.</p> <h3>API changes</h3> <p>Deleting a resource tariff, a resource type or a tariff class that other records still name throws. Deleting a tariff preset deletes its tariffs and allotments.</p> <p>AI-Generated: Yes (Claude Code was used to run this audit and draft this issue. I reviewed it before posting.)</p>