>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614926. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !166 >>> <h3>Problem/Motivation</h3> <p>Everything a resource offers, it offers everywhere. A site that runs a mini-site for a special event, on its own domain, cannot say that a tariff or a resource belongs to that mini-site and must not appear on the main site, and there is no way to offer a rate on one front without offering it on all of them.</p> <p>The axis wanted here is the booking channel: the front a booking is made through. A mini-site on its own domain is one, a partner integration through <code>yoyaku_api</code> is another, and a box office would be a third. Yoyaku has no box office today, the only operator booking entry being the test form at <code>modules/yoyaku_ui/src/Form/PlaceBookingForm.php</code>, so nothing here models one. The point is that it can become a channel later without the seam changing.</p> <h3>Proposed resolution</h3> <p>A booking channel is a config entity, <code>yoyaku_booking_channel</code>, scoped to exactly one tenant. Mini-sites are per tenant, so unlike a resource type a channel is never shared across tenants.</p> <p>Which channel is being served is answered by a priority ordered chain of services tagged <code>yoyaku.booking_channel_resolver</code>, the first non-empty answer winning, shaped like the tenant chain in <code>src/TenantContext.php</code>. It answers a channel or nothing, and nothing is the honest answer for the main site, for an administrative page, and for drush and cron. There is deliberately no default channel, unlike the tenant with its <code>default</code>: an entity naming no channel is on offer everywhere, including there, so a site running no mini-site never meets the feature at all. A site that later wants a main-site-only tariff creates a channel for the main site and binds its domain to it, which is also how a box office would join.</p> <p><code>yoyaku_domain</code> gains the binding the mini-sites need: a booking channel names the domains it is served on, as a third-party setting edited on a Domains tab, the same shape as the tenant binding already there. A domain no channel claims defers, because Domain falls back to the default domain record for any hostname it cannot match, so an unmatched host would otherwise resolve whichever channel names that record. The form refuses a domain whose tenant binding names another tenant, so the two answers cannot disagree.</p> <p>Restriction is one shared field, stamped on <code>yoyaku_resource</code> and on <code>yoyaku_tariff</code> the way the tenant field is stamped today: naming no channel means on offer everywhere, naming one or more means on offer only there. A slot inherits from its resource, and the tier can gain the field later without anything moving.</p> <p>The filter is one service applied at the read seams, rather than rewritten at each of them: <code>BookingManager::tariffsByResource()</code>, which feeds the availability map and therefore the booking form, the calendar, the venue map and the API in one move, then the listing entry points in <code>yoyaku_calendar</code>, <code>yoyaku_node</code> and <code>yoyaku_placement</code>. Views builds its own query, so <code>yoyaku_views</code> gets a filter plugin of its own. Engine reads pass <code>accessCheck(FALSE)</code> throughout, so none of this can ride on a query access tag.</p> <p>Hiding is not enforcing, so <code>RequestBooker</code>, the one booking path, refuses a line naming a resource or a tariff the channel does not offer.</p> <p>The channel is recorded on the transaction when it is opened, and read from there afterwards. The ambient request only seeds it: a basket outlives the request, a booker can arrive on the mini-site and come back on the main site, and mail and the back office render in a different context entirely. The field ships nullable now, so the day a box office exists its bookings are already told apart in reporting.</p> <p>Offers become channel dependent, so a cache context ships with this.</p> <p>One thing deliberately not done: the booking channel does not belong in <code>YoyakuAccessControlHandler</code>. The tenant is a hard boundary there for everybody, administrators included. A channel restricts what is on offer, and putting it in the access handler would blind the back office to the mini-site's own resources.</p> <h3>Remaining tasks</h3> <ul> <li>Kernel coverage for the resolution chain, for the domain binding and for the restriction, plus functional coverage of the admin screens.</li> <li>A documentation page, and the module maps that list what each submodule does.</li> <li>French translations in the same commit.</li> <li>The admin screens accessible from the first commit.</li> </ul> <h3>User interface changes</h3> <p>A Booking channels collection under the booking administration, a Domains tab per channel when <code>yoyaku_domain</code> is installed, and a Booking channels element on the resource form and on the tariff form.</p> <h3>API changes</h3> <p>New: the <code>yoyaku.booking_channel_resolver</code> service tag, and the service answering the channel being served.</p> <h3>Data model changes</h3> <p>A new <code>yoyaku_booking_channel</code> config entity, a booking channels base field on <code>yoyaku_resource</code> and on <code>yoyaku_tariff</code>, and a booking channel base field on the transaction. Pre 1.0, so no update hook: reinstall is the upgrade path.</p>