>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3616316. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !215 >>> <h3>Problem/Motivation</h3> <p>A venue that seats by place has a rule the engine cannot express: a booking must not leave a single place available on its own. Two shapes of the same thing: a place orphaned between two bookings, and a single place left at the end of a row. Neither is ever chosen by the next booker, so the row loses a place for the session, and a party arriving later finds the house fuller than the count says.</p> <p>Both shapes are one measurement, over the stretches of available places a booking leaves behind. A place alone between two bookings is a stretch of one bounded by bookings; a place alone at the end of a row is a stretch of one bounded by a booking and the end of the row. So this is one rule with a number, not two rules.</p> <h3>Proposed resolution</h3> <p>A configurable, attachable constraint policy, <code>orphaned_places</code>, hosted on a resource type, a resource, a tariff or one slot of a tariff. One setting: the fewest places that may be left available side by side (default 2, and at least 2, since 1 refuses nothing). Telling a place left alone between two bookings from one left alone at the end of a row would need the row's physical extent, which the places a strategy is handed do not carry, since a row map holds only what is still available. So both shapes are refused together, and a venue that wants to tolerate one of them is a follow-up.</p> <p>What it refuses, for a minimum of two: on each side of what the booking takes, the available places left must be none at all or at least two, never exactly one. Taking a place flush against a booking, against a closed area or against the end of a row is always accepted. A stretch of exactly three can only be entered from one of its ends. A pair cannot be broken by a booking of one, because that leaves one. A place that is already alone stays bookable, since taking it leaves nothing behind.</p> <p>Only what the booking creates is refused. The stretches are measured before and after, so a booker is never refused for a hole somebody else left, and attaching the rule to a house that already has orphaned places does not shut it down.</p> <p>Three parts, one reader:</p> <ul> <li>A reader in yoyaku_placement that, given the places of the touched rows and what a request takes, answers which stretches the request would leave shorter than the minimum. It reads the geometry through <code>PlaceGeometry</code>, so a place with no row and a place in a pooled area are exempt by construction. A place no booker may take, in a closed area or held by an allotment or a pinning, counts as a wall rather than as an available stretch. A rule can reach several slots, and a row is a different row on each of them, so the reader groups the lines by slot and measures each slot's rows on their own.</li> <li>The policy itself, asked at the hold checkpoint under the slot row lock, which is the only pass that is authoritative and the only one that catches a place named directly on a map, by an operator or through the API.</li> <li>The seating strategy, which has to weigh the same rule while it chooses. A strategy that proposes a placement the hold then refuses is a dead end with a message nobody can act on. Since a strategy reads nothing but its request, the resolved rule travels in <code>SeatingRequest</code> and its caller resolves it from the attachments; <code>propose()</code>, <code>giveUpFirst()</code> and <code>consolidate()</code> all read it.</li> </ul> <p>Two engine changes are needed. <code>ConstraintPolicyManager</code> drops the per-line values from a proposed line, so no policy can see which place a line names; those values have to reach the policy, the engine still not interpreting them, exactly as the booking constraint contract already states. Releases need no plumbing: the pass under the locks runs after the lines being given up are released, so what it reads already accounts for them. Second, a hold evaluates policies twice, once to fast-reject without contending for the slot row locks and once inside them, and a policy answering from committed state cannot be answered by the first: whatever it read there is read again under the lock. So a policy declares <code>readsCommittedState: TRUE</code> on its attribute and is asked once, inside the locks. It defaults to FALSE, so every existing policy keeps both passes.</p> <p>A policy says that it also constrains where a party may sit by implementing <code>PlaceSpacingInterface</code> and publishing its own number, and the provider asks whatever it finds rather than naming a plugin or reading another plugin's settings key. Measured with <code>Database::startLog()</code> on one placement in a six-place hall, caches warm: 22 queries with nothing attached, the same 22 on <code>1.x</code>, and 23 with the rule attached, the one extra being the availability read under the lock. <strong>That extra query is gone since <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3616341" title="Status: Closed (fixed)">#3616341: One hold asks the same slot-wide question once per line, so a party of twelve costs 102 queries</a></span></strong>, which shaped the locked read as the session's availability and primes the constraints before the group policies, so every constraint answers from one read: its <code>PlaceHoldCostTest::testTheOrphanRuleCostsNothingToEnforce</code> now measures 19 with the rule attached and 19 without. The figures above were true of <code>1.x</code> when they were taken.</p> <p>The word is freed for this. <code>orphaned</code> currently also describes a slot whose resource went inactive, in <code>SlotBookable</code>'s docblock and in one test's naming. That sense becomes <code>withdrawn</code> in the same change, so the word means one thing in the codebase. The unrelated <code>NoOrphanedTariffs</code> constraint and the incidental uses (a workflow instance, operational rows, a menu link, held lines) keep the ordinary sense of a child whose parent went away and are left alone.</p> <h3>Consequences</h3> <p>The rule makes some available places unbookable, which is the point of it: a row with four available and a party of three has no accepted answer, so the party is placed elsewhere. Counts and the Full mark are read from what is available and not from what this rule would accept, so they will differ. The strategy's <code>replace()</code> rung carries the weight, because a party arriving one unit at a time can reach a state where the row it sits in has no legal next place, and moving the party is the answer.</p> <p>A release is not refused: a booker may always hand a place back, even when what is handed back lands on its own. The reduction ordering prefers not to orphan a place, and <code>consolidate()</code> already closes a hole in the party itself.</p> <h3>Remaining tasks</h3> <ul> <li>The reader, with the before and after comparison.</li> <li>The policy plugin and its settings form.</li> <li>The rule inside the seating strategy's three questions.</li> <li>The per-line values on a proposed policy line.</li> <li>The slot sense of <code>orphaned</code> renamed to <code>withdrawn</code>, so the word means one thing.</li> <li>Kernel coverage: every refusal and every acceptance above, a pre-existing orphaned place not blamed, a pooled area exempt, a minimum of three, and the strategy never proposing what the policy refuses.</li> <li><code>docs/seating.md</code>, the policy documentation, and the French translation.</li> </ul> <h3>User interface changes</h3> <p>A new policy in the list a host offers, with its own settings form. The seat map is unchanged: whether a place would orphan another depends on the visitor's own basket, so it belongs in the per-visitor layer of the availability read and never in the cached document. A follow-up if it is wanted.</p> <h3>API changes</h3> <p>A proposed policy line gains its values. One new plugin, and one new value object on the seating request. Nothing released depends on either.</p> <h3>Data model changes</h3> <p>None. The policy attachments already have their store.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary. No code has been written yet.)</p>