>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615067. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !172 >>> <p>Price resolution walks the resource tariff and then the resource, taking the first value that is <em>set</em> (<code class="language-php">PaymentPolicyResolver::policyFor()</code>, via its <code class="language-php">overridden()</code> helper). So a resource tariff whose price is empty sells at the resource price instead, and which of the two applies depends on whether a field happens to have been filled in.</p> <p>That is a silent fallback. An operator who adds a tariff and does not price it gets the resource price, which on a resource that predates its tariffs is likely a leftover nobody meant to sell at. Nothing on screen says which of the two numbers is in force.</p> <h3>Proposal</h3> <p>Make <code class="language-php">price</code> required on <code class="language-php">yoyaku_resource_tariff</code>. Zero stays a valid value, so a free tariff becomes an explicit <code class="language-php">0.00</code> rather than an empty field that quietly inherits. A free booking is gated through checkout either way, so being explicit costs nothing and reads better.</p> <p><strong>The resolver needs no change.</strong> <code class="language-php">overridden()</code> only falls through when a value is empty, so guaranteeing the tariff carries one stops the fallthrough by itself. No new branch and no precedence rule to write.</p> <h3>What stays as it is</h3> <ul> <li><strong>The resource price, narrowed.</strong> It still prices a resource that sells no tariffs at all, which is the documented case where a slot sells against its own capacity and its bookings leave the tariff empty. Its description should say so, since that becomes its only job.</li> <li><strong>Collection and no-show settings keep inheriting.</strong> <code class="language-php">policyFor()</code> resolves <code class="language-php">collect_mode</code> and <code class="language-php">collect_value</code> as a pair and <code class="language-php">noshow_fee</code> separately, and its own docblock explains that this is what stops a tariff price dragging the collection mode along with it. The amount belongs to the thing being sold; the policy belongs to the resource. Only the amount becomes mandatory.</li> <li><strong>The slot tariff price stays optional.</strong> It is a departure from the tariff, not the price itself, and a per-session override is very often about the quota alone. Requiring a price there would mean retyping one on every session just to change an allocation.</li> </ul> <h3>Migration</h3> <p>No update hook: the project is pre-1.0 and reinstall-only. An existing site stamps each empty resource-tariff price with its resource's current price, once, so nothing changes what anything currently sells for.</p> <h3>Related</h3> <p>Requiring a price on twelve tariffs is only reasonable because <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3614386" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3614386</a></span> can stamp all twelve from a reusable set, so the two belong together even though either can land first.</p>