Give every bookable area its own outline, stored per part of a section and arranged in the venue layout

In a large hall the bookable unit is not the seat, it is the part of the house. A visitor chooses the Corbeille, or one half of the second balcony, and the engine seats them inside it: VenuePlacementProvider places every unit of a booking made by quantity through the resource's seating strategy, so the booker still receives a real ticket carrying a row and a place. "Pooled" describes how the area is counted, not what the booker gets, and this is how most large venues sell.

The defect

VenueMapBuilder built one pooled block per area, section plus subsection, and every one of those blocks took its clickable shape from the section: the block's element was the section's map_element. That field lived on the section and there was nothing per subsection, so two halves of one balcony offered separately produced two blocks pointing at the same outline, and a hall that offered half a balcony at a time had nothing a visitor could click. Nothing checked that the named id existed in the artwork either, so a section naming a shape the picture did not contain silently refused to be clickable, with no error anywhere.

What shipped

An area's outline is data, stored at the finest grain the hall is divided into: one outline per part of a section, where a part is a subsection and an undivided section is all of its first part. It is a multi-line field on the section, one outline per line, beside the names of those parts: line one describes part one. Not a record of its own, because every screen that draws an area has already loaded the section, so an outline costs no query at all.

Any area a configuration offers is drawn from the parts it covers, and that is one string rather than an algorithm: path data joins, so an area covering a whole divided section is its parts one after another, drawn as one shape with one control. The two halves of a balcony are two areas for the production that offers them apart and one area for the production that offers them together, with one geometry behind both. Geometry is a physical fact about the room and grouping is a commercial decision about a production, which is why no shape is ever stored on a configuration row: two configurations could then disagree about where a balcony is.

map_element is deleted, and the failure mode goes with it. A malformed outline is refused where it is written rather than ignored where it is read, and because nothing is looked up inside the artwork any more, a hall with no artwork at all can be booked by area.

How the shapes are authored

The venue layout of #3616062: Place a hall by arranging a generated layout in a vector editor, keep the result as its map background, and let the picker zoom out to all of it carries an Areas layer holding one shape per part of the hall, which an operator reshapes in a vector editor and the upload reads back. Each shape is seeded so nobody starts from a blank canvas: the outline the part already carries, else a hull around that part's own seats, else a box parked below the room for a part that holds no place at all, such as a standing floor. A part whose seats are all still parked gets no shape that trip, since a hull around the parked grid would come back as that part's outline once the seats had moved into the room.

Three things on the Layout tab follow from that. What to arrange chooses the places, the areas, or both: a placed hall is four hundred kilobytes of markers around a couple of dozen shapes, and shaping the areas over a finished room is thirty. Write each area name across its shape puts each part's name on it while you drag it, taken back out on the way in so it is never baked into the picture. And applying is now one answer per half, places and outlines separately, because an afternoon spent dragging seats is an afternoon in which a shape can be nudged unnoticed: the half you leave alone is left exactly as it was, and the report names every part the file would reshape whether or not you let it.

The name goes at the middle of the widest run of a shape's own inside. Neither the middle of the box around it nor the centroid of its area will do, and a hall is where both fail: a balcony subsection is a long diagonal strip, whose box has its middle out in the room, and a balcony is a curved band, whose centroid is in the hollow it curves around.

Also in it

The venue package carries the outlines, and the subsection names beside them, which had shipped without ever being exported; format version 4, and a version 3 package still imports. One fix found while reading the picker again: a full area announced itself aria-disabled and drew itself as refused, but still acted on a click or a key and leaned on the stepper clamping at its own top.

The bundled Auditorium de Bordeaux never carried a map_element, so no fixture needed migrating; only this module's own README showed one.

Deploying it to a site that already has areas

The new area_outlines base field has to be installed and map_element uninstalled, which is pre-1.0 so there is no update hook, and then one download and upload of the layout gives every area its shape. Done on the development site: twenty-seven parts across two halls, no place moved.

Left alone on purpose

Whether an area may ever mix granularities, a whole section together with half of another, is still unanswered; nothing here requires it. Offering several sections as one bookable block is still not a thing: a whole section is the union of its own parts, and a group of sections would need a key of its own.

AI-Generated: Yes (Claude Code wrote the code, the tests and the documentation on the merge request, ran them, deployed it to my development site and drafted this summary. I reviewed all of it, and several of its decisions are corrections I asked for.)