The three entity types added in #3615101: Add allotments, named slices of a session's capacity that given tariffs draw from have no form widgets and no add action, so an operator cannot create an allotment at all.

Steps to reproduce

  1. Go to Booking, Allotments. There is no add action on the page.
  2. Go to the allotment add path directly. The form shows a Save button and no fields.
  3. Same on a production Allotments tab: the add form renders a Save button and nothing else, and saving stores a record naming no allotment.

Cause

yoyaku_ui is what makes the booking base fields form-displayable: BookingUiHooks::entityBaseFieldInfoAlter() calls setDisplayConfigurable() and setDisplayOptions() from a per-entity-type widget map. That map never got entries for yoyaku_allotment, yoyaku_resource_allotment or yoyaku_slot_allotment, so their default form display has no components and ContentEntityForm renders nothing but Save. yoyaku_ui.links.action.yml has the matching gap: no add action points at their collections.

Proposed resolution

  • Give the three types their widgets.
  • Present the allotment reference as a select rather than an autocomplete, for the reason the tariff class is a select: a tenant names a handful of allotments and they are its own vocabulary, so they are a list to pick from rather than a name to remember and type. This applies to the preset allocation form too, so the field looks the same wherever it is named.
  • Accept an ISO 8601 duration such as P1D in the release field, the way the settlement grace already does, rather than seconds alone. The column keeps holding seconds, so the availability query is unchanged.
  • Add the missing add actions. Preset allocations, preset tariffs and slot tariffs have the same missing action, so they are fixed in the same pass.

Also in scope

Everything an operator meets while setting an allotment up, fixed as one piece of work rather than split across tickets.

  • A pinned place is added one at a time on a pinning's Places tab: an allotment autocomplete, a place autocomplete and a weight. Naming a fifty-seat VIP block that way is fifty submits, and it asks the operator to know each place's label before typing it, which is exactly the knowledge the seat map exists to spare them. The hall already draws an interactive map (yoyaku_placement.venue_map), so the tab gets a map picker: choose the allotment once, click places to pin and unpin, save once. An already pinned place is drawn in its allotment's color. Click order seeds the weight, which is what truncation reads when a production pins fewer places than the plan names. The per-place form stays as the fallback the map writes through, and the picker is keyboard-operable and announces each selection.
  • The pinnings table calls its count "Places held", which is the label the allotment's own capacity field carries. One reads a count of named seats, the other a number an operator types. The column becomes "Named places".

Issue fork yoyaku-3615603

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: The allotment screens render an empty form and carry no add action, so an allotment cannot be created » Make the allotment screens usable: form fields, add actions, ISO 8601 release offsets, and pinning places from the venue map
Issue summary: View changes

  • mably committed a3791d75 on 1.x
    fix: #3615603 The allotment screens render an empty form and carry no...
mably’s picture

Status: Active » 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.