Problem
Five collection screens list weighted records in the order an operator chose without offering that choice: allotments, tariff classes, tariff presets, tenants and booking channels. A weight is a form element and a collection screen is a list builder, so the only place the number could be typed was the record's own form, one record at a time. Reordering a season's tariff classes meant opening each one, working out which number to type, and typing it.
A booking channel had the same weight and a second fault on top of it: it was offered ALPHABETICALLY everywhere it is chosen, so the order on its own list and the order in every picker disagreed. #3618261: The admin screens of a translatable record lost their form, their tabs and their order gave every weighted type its order in reference widgets but excluded config entity types, on the grounds that ConfigEntityBase::sort() is weight and then label already. That is only true where something calls it, and a selection handler does not.
Proposed resolution
Make the five draggable. Core already solves this for a config entity with DraggableListBuilder, and the mechanics live in DraggableListBuilderTrait, which is not config-specific: the two config lists use core's class directly, and the three content lists use a small base saying which FIELD holds the weight, since these types carry a weight field rather than declaring a weight entity key. As on the engine's other order screens, the weights are renumbered from zero on save, so the next record added lands after the last one instead of inside an arrangement somebody chose.
The weighted-options pass reads the weight off a config entity too now. It also no longer assumes an option key is numeric, which is what had kept the channels exactly where they were even once the type was recognised.
Remaining tasks
None.
User interface changes
The Allotments, Tariff classes, Tariff presets, Tenants and Booking channels screens are ordered by dragging a row, with a Save order button. The tenant list no longer prints a weight number, because the handle replaces it. Booking channels are offered in the order they were weighted wherever they are chosen.
Existing weights are renumbered to close their gaps the first time an order is saved. The order itself does not change.
API changes
A base list builder for a draggable list of weighted content entities. Nothing existing changes.
Data model changes
None.
AI-Generated: Yes (the code, its tests and this summary were written by Claude Opus, reviewed and verified by the maintainer against a running site)
Issue fork yoyaku-3618282
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
Comment #3
mably commentedComment #5
mably commented