fix(ui): show toast notification when user deletion returns an error

[omorros]

🔗 Related Issue

Closes #3015

---

📝 Summary

When deleting a user returns a 4xx error (e.g. self-deletion, last
admin, or DB error), the error HTML was silently discarded by HTMX
because the global htmx:beforeSwap handler does not allow swaps
for user delete responses. The error was never shown to the admin.

This fix attaches hx-on::after-request to the delete button in
both the Jinja template (users_partial.html) and the
Python-generated card (admin.py). On any non-2xx response it
parses the error HTML, extracts the plain text, and calls the
already-existing showErrorMessage() function to display a toast.
No backend changes required.

---

🏷️ Type of Change

• Bug fix

---

🧪 Verification

Check	Command	Status
Lint suite	make lint	⏳
Unit tests	make test	⏳
Coverage ≥ 80%	make coverage	⏳

---

✅ Checklist

• Code formatted (make black isort pre-commit)
• Tests added/updated for changes
• Documentation updated (if applicable)
• No secrets or credentials committed

---

📓 Notes

Frontend-only fix. The admin_delete_user endpoint already returns
correct 400/403 responses with descriptive messages, this PR only
ensures those messages are surfaced to the user via the existing
toast system.

[marekdano]

Thanks for the PR @omorros 👍

What it does

Adds hx-on::after-request handlers to the delete user buttons so that when the DELETE /admin/users/{email} endpoint returns a non-2xx response (e.g., "Cannot delete your own account", "Cannot delete the last remaining
admin user"), the error message is extracted from the HTML response and displayed via showErrorMessage() toast.

Changes are in two places:

• admin.py:6357 — Python-generated user card (the users search/list view)
• users_partial.html:116 — Jinja template user card

Overall assessment: Looks good, minor suggestions

Positives:

• Correctly identifies the root cause — HTMX's beforeSwap handler was swallowing error responses
• Frontend-only fix is the right approach since the backend already returns proper error messages
• Uses the existing showErrorMessage() function rather than inventing a new pattern
• Both rendering paths (Python f-string and Jinja template) are covered

Two suggestions:

1. XSS concern with innerHTML — The handler does d.innerHTML=event.detail.xhr.responseText to parse the server response. While the server response is trusted HTML from our own backend, using innerHTML with response content is worth noting. The approach of creating a temp div to extract textContent is a common safe pattern for stripping HTML, so this is acceptable — but worth a comment.
2. Readability of inline handler — The hx-on::after-request value is dense, especially in the Python f-string version (line 6357) with escaped braces{{ and escaped quotes. Consider extracting this into a named JS function like handleDeleteError(event) in admin.js or admin.html to keep the templates clean and avoid duplication:

  function handleDeleteUserError(event) {
      if (!event.detail.successful) {
          var d = document.createElement('div');
          d.innerHTML = event.detail.xhr.responseText;
          showErrorMessage(d.textContent.trim() || 'Error deleting user');
      }
  }

Then both templates just use hx-on::after-request="handleDeleteUserError(event)".

[omorros]

Both suggestions addressed, thanks for the detailed review! @marekdano

1. Extracted the inline handler into window.handleDeleteUserError() in admin.js so both templates just use hx-on::after-request="handleDeleteUserError(event)".

2. Added a comment explaining the innerHTML + textContent pattern is intentional for safe HTML stripping.

[marekdano]

Thanks for the update!

LGTM 🚀

[crivetimihai]

Clean implementation. The `handleDeleteUserError` function correctly extracts the text content from the HTML error response and surfaces it via the existing toast system. Using `hx-on::after-request` on the delete button is the right HTMX pattern for this.

The SQL `text()` call reformatting is whitespace-only and consistent — no concerns there.

[crivetimihai]

Thanks @omorros — important UX fix. Surfacing error messages on delete failures instead of silently swallowing them is the right behavior. Clean implementation.

[crivetimihai]

Reopened as #3205. CI/CD will re-run on the new PR. You are still credited as the author.