mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-10-02 23:45:08 -04:00
Isaac ConnorandClaude Opus 5
3d8fdf8677
Saving a deleted monitor undeleted it even though the undelete checkbox was never ticked. Two causes. The $types map, whose entries exist so that unticked checkboxes (which submit nothing) get forced to a default, listed Deleted => 0. But the Deleted checkbox is not a state toggle, it is an undelete action: it is only rendered for a deleted monitor and only ever submits 0. Forcing it to 0 when absent put Deleted => 0 into every $changes set. Remove it from $types so an absent Deleted simply is not a change. Second, the guard meant to catch the "new monitor reusing a deleted record's Id" case tested isset($_REQUEST['newMonitor[Deleted]']), a literal-bracket key that never exists, so $monitor->Deleted(false) ran on every save of a deleted record. Since save() writes every field, that persisted. Test empty(mid) instead, which is exactly the case the comment describes: mid is absent when adding a new monitor whose requested Id collides with a deleted row. Editing an existing monitor by mid now only undeletes via the checkbox, which arrives as newMonitor[Deleted]=0 and shows up in $changes on its own. Manual test on a deleted monitor: editing and saving with the checkbox unticked keeps Deleted set and persists the other edits; ticking the checkbox and saving clears Deleted as before. The restart block was already guarded by !$monitor->Deleted(), so no capture daemon is started for a monitor that stays deleted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NDhTBPj9xEaT52pRmAufaP