Keep one Add field control in the request-form editor (PMS-750) #500

Merged

longjacksonle merged 1 commit from fix/PMS-750-single-add-field-control into main

2026-08-09 19:47:13 +02:00

longjacksonle commented

2026-08-09 19:45:27 +02:00

Owner

This is a defect in my PMS-747 fix (#498), not in the original design. The header control sits inside the only region the modal scrolls (the modal pins its header and footer), and each field card is roughly 250px tall, so from the third field on the control was off-screen and adding a fourth meant scrolling back up past everything just typed. #498 added a second copy under the list and left the first in place. That fixed reachability and created this.

The fix

One control, immediately after the last field row.

It is the keeper on its own merits, not merely as the survivor of the pair. The list is what is being extended, the end of the list is where the new row appears, and it is where the operator's eye and cursor already are. Scrolling to the bottom of the field list is the same motion as finishing the field list, so the control is adjacent to the work at every length, which is the property #498 was reaching for and got the awkward way.

Full width now, because the "Conditional rules" heading sits directly below it and, with the header copy gone, a small centred button between two sections could be read as belonging to either. The Fields heading loses its header row along with its button, since a flex container with one child and justify-between was left doing nothing.

Conditional rules keeps its header control

Deliberate asymmetry, called out so it does not read as a miss. A form always has at least one field (the server refuses a definition without one, so the editor opens with a row), so a control after the last row always has something to sit under. Rules are usually zero and the section renders "No conditional rules." in their place, so an append control there would sit under a sentence saying there is nothing to append to. The rules list is also short by nature, so its header control is never far from the work the way the fields one was. If that list ever grows the same way, it should get the same treatment.

Testing

cargo fmt --all --check, cargo clippy --all-targets -- -D warnings, both guard scripts, cargo test --lib (274 passing, unchanged: this is markup, and no test asserted the button count).

Needs eyeballing on staging, like the rest of this series: the browser-driven e2e specs are still quarantined, so nothing automated can see that there is now one button rather than two.

PMS-750. The request-form editor showed two identical "Add field" buttons, one in the Fields section header and one under the last row. On a new form, which opens with exactly one empty field, both were on screen at once with a single field card between them. This is a defect in my PMS-747 fix (#498), not in the original design. The header control sits inside the only region the modal scrolls (the modal pins its header and footer), and each field card is roughly 250px tall, so from the third field on the control was off-screen and adding a fourth meant scrolling back up past everything just typed. #498 added a second copy under the list and left the first in place. That fixed reachability and created this. ## The fix One control, immediately after the last field row. It is the keeper on its own merits, not merely as the survivor of the pair. The list is what is being extended, the end of the list is where the new row appears, and it is where the operator's eye and cursor already are. Scrolling to the bottom of the field list is the same motion as finishing the field list, so the control is adjacent to the work at every length, which is the property #498 was reaching for and got the awkward way. Full width now, because the "Conditional rules" heading sits directly below it and, with the header copy gone, a small centred button between two sections could be read as belonging to either. The Fields heading loses its header row along with its button, since a flex container with one child and `justify-between` was left doing nothing. ## Conditional rules keeps its header control Deliberate asymmetry, called out so it does not read as a miss. A form always has at least one field (the server refuses a definition without one, so the editor opens with a row), so a control after the last row always has something to sit under. Rules are usually zero and the section renders "No conditional rules." in their place, so an append control there would sit under a sentence saying there is nothing to append to. The rules list is also short by nature, so its header control is never far from the work the way the fields one was. If that list ever grows the same way, it should get the same treatment. ## Testing `cargo fmt --all --check`, `cargo clippy --all-targets -- -D warnings`, both guard scripts, `cargo test --lib` (274 passing, unchanged: this is markup, and no test asserted the button count). Needs eyeballing on staging, like the rest of this series: the browser-driven e2e specs are still quarantined, so nothing automated can see that there is now one button rather than two.

longjacksonle added 1 commit

2026-08-09 19:45:27 +02:00

fix(forms): keep one Add field control, under the last field

Check / fmt + clippy + tests (pull_request) Successful in 1m42s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

da0f963d22

PMS-750. The editor showed two identical "Add field" buttons: one in the Fields section header, one under the last row. On a new form, which opens with exactly one empty field, both were on screen at once with a single field card between them, so the editor was asking the operator to choose between the same thing twice.

That is a defect in the PMS-747 fix rather than in the original design. The header control sits inside the only region the modal scrolls, so from the third field on it was off-screen and adding a fourth meant scrolling back up past everything just typed. PMS-747 added a second copy under the list and left the first in place.

The one under the list is the keeper, and not merely as the survivor of the pair: the end of the list is where the new row appears and where the cursor already is after filling in the last one. Scrolling to the bottom of the field list is the same motion as finishing it, so the control is adjacent to the work at every length, which is the property PMS-747 was reaching for.

Full width now, because the Conditional rules heading sits directly below it and a small centred button between two sections could be read as belonging to either.

Conditional rules keeps its header control on purpose. A form always has at least one field, so a control after the last row always has something to sit under; rules are usually zero and the section renders "No conditional rules." in their place, so an append control there would sit under a sentence saying there is nothing to append to.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E48b8YHWYwmaKjFBy5esXp

longjacksonle scheduled this pull request to auto merge when all checks succeed

2026-08-09 19:45:54 +02:00