# Editable General Rules — September 7, 2026

The three request-processing sections now have Edit forms. Settings belong to
the selected company and brand; saving creates a new revision with actor and
timestamp. Earlier revisions remain in the database. No delete/update revision
endpoint is provided.

## Enable

1. Select `solidmarkmaster_db` in phpMyAdmin and run
   `backend/migrations/2026_09_07_leave_general_settings.sql` in full.
2. Deploy the backend, including the shared mutation and authorization changes,
   and the rebuilt frontend together.
3. Open Leave Configuration → General Rules. An account needs `leave_type`
   access to read and `can_edit` to save, plus access to the selected brand.
4. Review each form before saving. No setting is activated by the migration;
   before the first save the page displays the existing behavior.

## Supported settings

- Duration: current two-decimal amounts, whole-day or half-day increments;
  maximum days per request, with zero meaning no extra cap. Existing positive
  duration, date-range, policy, and entitlement validation still applies.
- Restrictions: 0–365 calendar days advance notice, and allow/disallow
  backdating. Dates use Asia/Manila. When backdating is enabled, historical
  entries are exempt from advance notice. These rules apply to administrators
  as well as employees.
- Approval: permit/block creation of already-approved leave; permit/block
  self-approval by comparing the authenticated username to employee ID;
  permit/block cancelling, rejecting, archiving, or moving approved leave back
  to pending. Blocking direct approval requires a pending request first. All
  existing action permissions and finalized-payroll protections remain active.

Duration and submission restrictions apply to new requests, changes to type,
dates or duration, and reopening inactive requests. Unchanged pending requests
can still be approved under their original submission conditions. Approval and
cancellation controls apply to subsequent actions immediately. Cancelling a
pending request remains possible; repeated archive remains idempotent.

Settings saves lock the brand and require the revision read by the form. A
stale editor must reload. Leave writes acquire the same brand lock after the
employee lock and validate before any request or balance mutation. SQL remains
the sole writer of usage deductions/reversals. Existing balances and deferred
reconciliation flags are not rewritten or cleared.

## Not enabled

Working-day/holiday/hourly calculation, required-document workflows,
configurable negative balances, multi-stage approvals, employee cancellation
requests, and notification settings need separate implementation. Forms state
these limits explicitly. No legal entitlement defaults are introduced.

## Verification

`backend/tests/leave/settings.php` runs the existing integrity, policy, ledger,
and allocation suite, then tests settings persistence, stale revisions, scope,
duration/notice boundaries, historical requests, approval/cancellation rules,
real mutation rollback, ledger preservation, and migration reruns.

Seven `guard_case.php` scenarios check reading/editing, denied employee access,
foreign brands, missing permissions, and an attempted status-field permission
bypass. Tests use only the disposable database on port 33316. No live database
changes or live leave submissions were made. Browser validation was unavailable.