Prevent deletion of the last admin account

[DogukanUrker]

Problem

The admin panel allows an admin to delete their own account via the user management interface. If the last admin account is deleted, the system becomes permanently locked out — there is no way to create new admin accounts without direct database/code access.

Requirements

1. In delete_user(), check if the user being deleted is an admin AND is the last admin account. If so, reject the deletion.
2. Prevent admins from deleting their own account via the admin panel.
3. Add appropriate error messages (using flash_message with the session language).
4. Add logging for blocked deletion attempts.
5. Add unit tests covering:
   • Last admin trying to delete themselves
   • Last admin trying to delete another admin
   • Second-to-last admin deleting another admin (should succeed)
   • Non-admin deleting an admin account (should succeed)

[DogukanUrker]

🤖 AI-generated implementation plan — local LLM (ornith-35b) via Hermes Agent.
Not human-reviewed. Do NOT merge or act on this without human approval.

Problem

The delete_user() function in app/utils/delete.py:64 has no guard against:

1. Deleting the last admin account (permanent lockout — no way to recover without DB/code access).
2. An admin deleting their own account from the admin panel (app/routes/admin_panel_users.py:29).

The change_user_role() function in app/utils/change_user_role.py:19-20 also allows an admin to demote themselves to user, which could produce the same lockout — but this is not in issue scope.

Current state in main

• app/utils/delete.py:64-98 — delete_user() queries the target user, then immediately deletes without checking role or admin count. It only checks perpetrator_role after the commit to decide redirect destination.
• app/routes/admin_panel_users.py:29 — unconditionally calls delete_user() with no pre-validation.
• app/routes/account_settings.py:19 — calls delete_user() for self-delete (not in scope).
• app/utils/route_guards.py — new file providing login_required and admin_required decorators; guards route access but does NOT enforce business logic like "don't delete last admin."
• app/utils/change_user_role.py:19-20 — allows an admin to toggle their own role to user, which could create a lockout if all other admins are gone.

Root cause

delete_user() performs the delete unconditionally. There is no query to count remaining admins before deletion, and no check for whether the target or the perpetrator holds the admin role.

Proposed fix

1. Add guard logic to delete_user() in app/utils/delete.py

Add two checks at the top of delete_user(), before the delete:

1. Self-deletion guard: If session["username"] matches the target username (case-insensitive), reject with a flash message and redirect back to /admin/users (if perpetrator is admin) or / (if not).
2. Last-admin guard: Query User.query.filter_by(role="admin").count(). If the count is 1 AND the target user's role is admin, reject with a flash message and redirect.

Return early (don't commit) on either rejection. Use flash_message() consistent with existing pattern (page="delete", message="last_admin" or similar, category="error", language=session["language"]).

2. Add translation keys for error messages

Add keys to app/translations/en.json (and any other language files that exist) for the new flash messages, e.g.:

• delete.last_admin — "Cannot delete the last admin account."
• delete.self_delete — "You cannot delete your own account from the admin panel."

3. Add logging

Add Log.warning() calls in delete_user() for both rejection paths (blocked self-delete, blocked last-admin deletion).

4. Note on change_user_role() (out of scope but flagged)

app/utils/change_user_role.py:19-20 allows an admin to demote themselves. If all other admins are deleted, the system locks out. Consider adding a similar "last admin" guard here in a follow-up.

Files to change

• app/utils/delete.py — add self-delete and last-admin guards with flash messages and logging
• app/translations/en.json — add new translation keys for error messages
• app/translations/*.json (all existing languages) — add corresponding keys (or skip non-English files and note as follow-up)
• tests/e2e/admin/test_admin.py — add E2E tests for the new guards

Test plan

Add the following E2E tests to tests/e2e/admin/test_admin.py (extend TestAdminUsers class):

1. test_admin_cannot_delete_last_admin_themselves — Create a single admin user (no other admins). Log in as admin. Attempt to delete self via POST to /admin/users. Assert user still exists and error flash message is shown.
2. test_admin_cannot_delete_last_admin_account — Create exactly one admin user (the target). Log in as admin (a different admin). Attempt to delete the target admin. Assert target still exists.
3. test_second_to_last_admin_can_delete_other_admin — Create two admin users. Log in as admin A. Delete admin B. Assert admin B is gone and admin A still exists.
4. test_non_admin_cannot_delete_admin_via_admin_panel — This is already handled by @admin_required on the route. Verify it still works. (No new test needed; existing test_admin_panel_redirects_non_admin covers this.)

Use existing helpers: create_test_user() with role="admin", _login(), get_user_by_username().

Risks & edge cases

• Race condition: Between the admin count query and the delete, another process could delete an admin. Mitigation: use a database transaction with a row-level lock or check again immediately before delete. For this app's SQLite/single-process model, the risk is negligible.
• account_settings.py self-delete: The user's own "delete my account" button should still work (it's a conscious action). Do NOT block self-delete from account_settings. Only block self-delete from the admin panel.
• Redirect after deletion: The existing delete_user() already handles redirect based on perpetrator_role. Keep this behavior intact for the success path.
• Flash message translation: If a non-English language file is missing the new keys, the flash will fall back to the key string. Add keys to all language files to avoid this.
• Admin count query: User.query.filter_by(role="admin").count() is correct but note that role is stored as a Text column. The comparison is case-sensitive — ensure all admin records use lowercase "admin" (they do, per app/database.py:44).

Out of scope

• change_user_role() last-admin guard (flagged as follow-up)
• Self-delete from account_settings.py (intentional user action)
• UI changes to the admin panel (e.g. disabling the delete button for self/last admin)
• Database migrations or schema changes
• Adding the guard to delete_user when called from account_settings.py (that's a deliberate user action)

[DogukanUrker]

Folding this into #259 — the last-admin guard is part of the unified delete_user() authorization refactor. Tracking there to avoid two conflicting PRs on the same function.