Closes #20301: Add "Dismiss all" action to notifications dropdown

[pheus]

Fixes: #20301

Add a “Dismiss all” action to the bell dropdown that clears all unread notifications for the current user via a GET endpoint. The dropdown continues to show up to the most recent 10 unread items, and now includes a clear, i18n’d confirmation message that shows the total number of unread notifications affected.

Summary of changes

• New view: NotificationDismissAllView registered with @register_model_view(Notification, name='dismiss_all', path='dismiss-all', detail=False); deletes unread notifications for request.user.

  • HTMX requests: if invoked from the Notifications page, return an HX-Redirect to repaint the page; otherwise return the existing dropdown partial.
  • Non‑HTMX requests: redirect to the Notifications page.

• Dropdown partial context: Now passes only the top 10 unread notifications plus counts:
  notifications = request.user.notifications.unread()[:10],
  total_count = request.user.notifications.count(),
  unread_count = request.user.notifications.unread().count(). :contentReference[oaicite:1]{index=1}

• Template update (htmx/notifications.html):
  Adds a “Dismiss all” button in the dropdown header when there are unread items, with a pluralized confirmation that shows the total unread count (e.g., “Dismiss 37 unread notifications?”).

• HTMX utility helpers:
  Introduce htmx_current_url() and htmx_maybe_redirect_current_page() to detect the current page (via HX-Current-URL) and issue an HX-Redirect when appropriate. Both are now used by the single‑item dismiss view and the new dismiss-all view to avoid stale rows on the Notifications page. :contentReference[oaicite:3]{index=3}

Screenshots

Screenshots (notifications present)

Screenshots (no notifications)

---

Notes for reviewers

• The button label uses “Dismiss all” to align with the route name (dismiss-all).

[bctiemann]

@pheus This works well and after a lot of thought about whether "Clear" was the right terminology (as opposed to "Mark Read" or "Dismiss"), I think probably "Clear" is clear enough, though maybe "Dismiss" is a little more consistent. The issue I have is that our existing terminology isn't very consistent — we use "Delete Selected" for the bulk delete button, and "dismiss" for the URL path, and then we muddle things up with the "read" path for when you click on the notification to view the object it pertains to, which makes it no longer "new" (a dirty badge), but doesn't remove it from your list of notifications, but also doesn't have any differentiator between it and an "unread" notification (well, it's shown in a slightly dimmed gray). "Clear" is a new terminology that has no precedent, but then most other terminology we have is implicit at best. So I'm okay with "Clear" because it obviously does "the right thing" as far as what the user is most likely to want.

I did notice one funny corner case: if you are viewing the Notifications page and you use the "Clear All" button to dismiss all unread notifications, those notifications stay in the list (because the action was done through HTMX and does not repaint the page). Then if you click on the trash can icon for any of the now-deleted notifications, or use the "Delete Selected" button, you get a 404 error.

Could you please give that some thought and see if there's a simple way to avoid that behavior, maybe by forcing a refresh if you're viewing the Notifications page? Or maybe the right answer is it isn't worth trying to prevent that, depending on how much effort it involves.

Thanks!

[pheus]

Thanks for the thoughtful review!

Terminology
I’ll think this through, but your points have me leaning toward “Dismiss all” to match the existing dismiss-all route and view. “Clear all” came from the issue text, but I agree we shouldn’t introduce another term.

Corner case
I’ve seen the same behavior when using the ❌ in the dropdown while the notifications table is open. I’ll think it through and report back; if it turns out non‑trivial or brittle, I’m comfortable keeping the current behavior.

Thanks again!

[pheus]

Quick design question about the dropdown UX:

The bell dropdown shows up to 10 unread items, but the new “Dismiss all” currently clears all unread notifications for the user. To avoid surprises, what’s your preference?

• A. Keep “Dismiss all” but show the total unread count and a clear confirm (e.g., “Dismiss all 37 unread?”).
• B. Scope the action to only the visible 10.
• C. Offer both: “Dismiss shown (10)” and “Dismiss all (N)”.

Happy to implement whichever aligns best with NetBox’s UX. Thanks!

[jeremystretch]

I would prefer option A. Seems like the most common use case IMO.

[pheus]

Note: This is an unrelated fix. Http404 is used, but not imported.

[pheus]

During manual testing, I've noticed that the dropdown menu does not actually limit the notification.

[pheus]

Thanks again for the thoughtful review!

What I changed based on your feedback

• Terminology: Switched the UI copy to “Dismiss all” to align with the existing dismiss-all route and keep wording consistent.
• Scope clarity: The confirm now includes the unread count (e.g., “Dismiss all 37 unread notifications?”) so it’s clear the action may affect more than the 10 items shown in the dropdown.

Stale-list fix

• To address the Notifications page corner case, I added a small HTMX helper that returns HX-Redirect when the action originates from account:notifications. That fully repaints the page; elsewhere the dropdown still refreshes in place.

Optional UI tweak

• While testing, I tried an icon‑only version of the button to match the existing delete actions. Screenshots are below. If you prefer that look, I’m happy to update the PR.

Open to any tweaks on copy, placement, or behavior—thanks again for the thoughtful guidance!

Icon-Only Design: