PUT /assigned-site can disable any employee's login, and is guarded by a read claim #1720

Raised in review of #1717, which makes UpdateAssignedSite write EformUser.IsActive — the platform's login kill-switch — when a worker is resigned. The write is correct; the endpoint it rides on is the problem, and it predates that PR.

TimePlanningSettingsController:

[HttpPut]
[Route("assigned-site")]
[Authorize(Policy = TimePlanningClaims.GetWorkingHours)]
public async Task<OperationResult> UpdateAssignedSite([FromBody] AssignedSite site)

Two problems, which only matter together:

1. GetWorkingHours is a read claim. The same policy guards the GET endpoints beside it. A write with offboarding consequences now sits behind "may view working hours".
2. No ownership scoping. site.SiteId comes straight from the request body and is looked up with no manager/tag check, so any site id is addressable.

So any account holding GetWorkingHours can PUT {"siteId": <any>, "resigned": true, ...} and disable that employee's login everywhere — the web back office and both flutter apps — since core refuses IsActive = false at every credential surface. There is no admin UI anywhere that shows or sets IsActive, so the only way back is another PUT with resigned: false.

Related sharp edge: the model binds from the body, so a payload that omits resigned deserializes to false. #1717 made the login write conditional on the resignation actually changing, which contains the blast radius — but the underlying clobber is still there for the settings row itself.

Options

• an admin-scoped claim for the resigned field specifically, rather than the whole endpoint (smallest change that matches what the permission means)
• scope the write to sites the caller manages, the way the rest of the plugin scopes by managing tags
• split resignation out of the settings endpoint entirely

Worth deciding before the feature reaches customers, not after.