How Requests Are Processed

Endpoints, idempotency rules and the cron order of operations.

Modal endpoints

index.php?m=deleteAccount&a=modal serves the dialog states as AJAX {body} markup. Mutating actions — password, sendcode, verifycode, survey, offerclaim, request, extend, confirm, cancel, userperm — are POST + token-checked JSON, guarded by login, module-enabled and owner-or-flagged checks. Scheduling is idempotent: re-submits never duplicate rows.

Cron order (per due row)

1. Select rows with deletein <= today and empty status; skip review-held (isRunnable gate).
2. Finance guard: block mode skips + logs on unpaid balances; warn mode logs and proceeds; leftover credit is applied/forfeited per setting.
3. Run closeclient / deleteclient; on success write the complete audit entry (feeds the dashboard) and delete the request row so it can never re-execute. Failures keep the row for retry.
4. Prune the activity log per retention. Nothing fatal ever breaks the cron.

Email merge fields

Client notices support {$delete_days}; admin notices add client id/name/email/phone plus the admin link. The verification-code mail supports {$verification_code}. All five templates are seeded only when missing.