Taking an area is one operation with two surfaces. On the plan a booker clicks its outline; on the booking page there was nothing to click, so the same choice has to be offered as a control beside the price. Letting the engine choose is the absence of that choice, which the control spells Auto.

The page groups its offers into tariff class panels, and the choice belongs to neither the panel nor the card. It belongs to the place grades an offer covers: the areas worth listing are the ones holding available places of those grades, and one choice per grade set keeps a party together. One control per card would let the full price go to one area and the youth price to another, splitting the party across the house.

Proposed resolution

  • A request may name an area, and the engine seats its units inside it. A $wanted entry, and a request handed to RequestBooker::holdMany(), carries area as a section and an optional subsection. It confines the engine whatever the area's mode, so it is useful for a placed area as much as a pooled one.
  • One area control per group of offers covering the same grades: Auto, then the areas of those grades with places left, in house order. The tariff class panels are untouched; the controls sit in a group of their own above the offers.
  • Both surfaces that offer the choice derive their answer from one data layer, so neither can offer an area the other does not, nor disagree about what is left in one.
  • Carry the choice in the selection payload as an areas map beside the tariffs, leaving the target token as it is, and pass it on as the request's area.
  • Refresh the option list with the rest of the offer state, so an area that fills up stops being offered.
  • An area that fills up between the page being drawn and the hold refuses and names itself. Nothing is seated elsewhere, and no choice falls back to Auto silently.
  • Whether a booker is offered the choice at all, and at which grain, is one field rule on the resource: never, sections, subsections, or both. So a resource, its type, the tenant or the site may each answer it, and a hall divided into forty rows does not open by offering a booker forty of them.

Remaining tasks

Done: docs and the French translation in the same commit, and tests covering a grade group whose area choice is honored, one whose area filled up, Auto, each grain, and the read count.

API changes

The selection payload gains an areas map. The request seam gains the optional area described above, which #3616297: Offer an area whose places the house gives out also needs and which belongs to whichever of the two ships first.

AI-Generated: Yes (Claude Code was used to help draft this issue summary, write the code and run the tests.)

Issue fork yoyaku-3616323

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

mably created an issue. See original summary.

mably’s picture

Title: Let a booker choose an area on the slot page, not only on the plan » Offer the part of the house on the booking page, not only on the plan
Issue summary: View changes
mably’s picture

Status: Active » Needs review

  • mably committed 8cc5c4e0 on 1.x
    feat: #3616323 Offer the part of the house on the booking page, not only...
mably’s picture

Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.