Nick SzaunigandClaude Opus 5
b0e05daa42
Four fields were still frozen because changing them would have bypassed the record that makes the change traceable, and a user's login data could not be corrected at all. Locking a field is the wrong trade: a wrong value stays in the system forever. The fix is to let the edit write the same history entry the dedicated endpoint writes. - A colony's apiary is editable through PATCH and writes the same ColonyApiaryHistory entry POST /colonies/:id/move writes, so the location history never skips a stand the colony was recorded on. - A honey batch's storage container is editable through PATCH and writes the same HoneyBatchRelocation entry POST /honey-batches/:id/relocate writes. - A stock item's quantity is editable and books the difference as an ADJUSTMENT movement, so the stored level stays the sum of its movements. - A role's key is editable (system roles were already rejected outright by RolesService.update, which keeps the seed's ADMIN lookup intact). - A user's e-mail - the login identity - is editable. A typo there previously locked the account out for good. - New POST /users/:id/reset-password lets an administrator set someone else's password: there is no self-service reset flow, so a forgotten password was the one thing no edit could repair. It revokes every refresh token and clears the permission cache exactly as a self-service change does, refuses to act on your own account (that goes through /profile/password, which proves ownership by asking for the current one), and never writes the password to the log. Frontend: - Users had no edit UI at all, although PATCH /users/:id existed. New EditUserDialog covers name, e-mail, role and an optional new password. - Colony, honey batch and stock item forms gained the newly editable fields, each with a note saying the correction is recorded as a move, a relocation or a stock adjustment. - The role dialog gained the key field. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>