Commit Graph

2 Commits

Author SHA1 Message Date
0d8af7cdf0 Refuse a save that changes nothing instead of reporting success
update_position returned quietly when no field differed, and the interface
answered "Planstelle geändert." — a confirmation for something that had not
happened. It now raises, and the message says so.

This is reachable without the user doing anything wrong: the chief checkbox
is dropped on the way out when the unit already has a chief position, so a
save consisting only of that tick arrives as an empty change set. The reply
was a green toast and an unchanged list, which sends someone looking in the
wrong place.

It also separates the two explanations for "I saved and nothing happened",
which is why it went in now: an empty change set is refused in red, so a
green confirmation with a stale card can only mean the page did not reload.

Verified against the live database: an unchanged payload is refused, a
changed one goes through.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 14:57:31 +02:00
a87c688c0a Show positions that do not exist yet, and let them be corrected
Two gaps in the positions view, both reported from use.

A position dated into the future was invisible. loadOpenPositions required
valid_from <= today, so a position decided now and effective at the quarter
boundary appeared nowhere until the day it began. The database already held
one — 60000824 "Neue Position", effective 01.09. — created through the
application and shown on no screen since.

Future positions now have their own section rather than joining the vacancy
list. They are a different statement: "nobody is here" and "this does not
exist yet" should not be counted together, and a position starting 01.10.
read as a vacancy nobody was filling.

Positions could only be created and deleted. Fixing a typo in the job title
meant deleting and recreating — with a new position number, which appears in
job postings, budgets and audit entries, and whose trail then breaks.
update_position keeps the number and records old and new values per field,
using the audit detail added earlier today.

Three things it refuses, as guards rather than remarks:

  - Moving an occupied position to another unit. That is a transfer, with
    history and reporting line, and belongs to the person — otherwise
    someone changes department silently.
  - Ending an occupied position, which would leave an assignment without
    one.
  - A second chief position in a unit, or an end before the start.

Verified against the live database, all rolled back: each guard fires with
its own message, the permitted edits go through, the audit entry carries the
changed fields. Open positions stay at 9 and the future one now appears in
its own section.

ESLint caught me priming the dialog's fields from an effect. Replaced by a
key on the component, so React rebuilds it per position and the fields
initialise from props — which also removes the flash of the previous
position's values on second open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 12:26:12 +02:00