>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615592. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !191 >>> <p>Places held by name are templated: a pinning is defined once per venue and pointed at from a session, from <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3615568" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3615568</a></span>. The numbers are not. <code>yoyaku_resource_allotment</code> gives reuse across the sessions of one production, and that is where it stops, so a season running eight productions declares "Schools 20, Guests 10" eight times by hand.</p> <p>The tariff preset does not close this. A preset cell already carries <code>allotment</code>, from <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3615101" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3615101</a></span>, so applying one points the school tariff at the schools. It never says how many places the schools get.</p> <h3>The preset is the right home</h3> <p>Not a second preset entity. Who draws on an allotment and how much it holds are configured together and go stale together, and an operator applying "the season's standard setup" to a new production means both. <code>TariffPresetApplier</code> also already has the machinery: <code>plan()</code> walks what would happen so the confirmation and the apply cannot disagree, and <code>apply()</code> is opt-in per cell with an explicit overwrite list, reporting created, updated, left and refused. Allocations want exactly that.</p> <h3>What a cell would carry</h3> <p>The allotment, the number of places, and the release offset. The offset travels and an absolute deadline does not, which is the same reason the resource record holds <code>release_before</code> while the session record holds <code>release_at</code>: a season says "release two days before" once, and a date belongs to one evening.</p> <p>Applying stamps <code>yoyaku_resource_allotment</code> rows on the production. A session's departure from its production stays a manual exception, as it is for <code>quota</code>, so nothing here writes <code>yoyaku_slot_allotment</code>.</p> <h3>Re-stamping</h3> <p>Applying twice should update <code>capacity</code> and <code>release_before</code> on a record that already exists, the way <code>copyValues()</code> re-stamps price, quota and allotment onto an existing tariff. Re-applying a preset must not leave last season's number in place.</p> <h3>Open</h3> <p>Whether an allocation cell should be refusable the way a graded tariff cell is refused when it names another hall's grades. Probably not: an allotment is tenant-level, so every preset can name every allotment, which is why the tariff <code>allotment</code> field needed no <code>TariffApplicabilityInterface</code> implementation either.</p> <p>Whether the preset should be able to say "this production holds nothing for the schools", which needs a zero rather than an absent cell, since absent means the preset is silent and zero means the schools get nothing.</p>