Notifications
A bell in the admin header holding a durable record of every notification BlackOps sends you, including the ones no device ever received.
BlackOps tells you things: someone read a post, someone joined your newsletter, a reply queue is ready, a billing event needs attention, an agent finished a job. Those used to arrive only as a web push, and a web push is easy to miss. Close the browser, be offline past the push's expiry, never grant permission, or never subscribe a device at all, and the notice was simply gone. Nothing anywhere recorded that it had ever been sent.
The bell fixes that by inverting which part is primary. The record is the notification. Push and email are delivery channels. Every sender writes the row first and then attempts delivery, so a push that fails or was never possible leaves a real, readable notification behind instead of nothing.
How it works
The bell sits in the admin header. When you have unread notifications it carries a badge with the count; the count is polled about once a minute, and the list itself is only fetched when you actually open the bell.
Opening it shows your 20 most recent notifications, newest first, with a relative timestamp and a dot on the ones you have not read. From there:
- Click a notification to mark it read and follow it to whatever it is about.
- Mark as read / unread on any single row, if you want to leave something flagged for later.
- Mark all read clears the badge in one action.
- Delete removes a row for good, and Clear read removes every notification you have already read. There is deliberately no "delete everything". Clearing unread notices you have not looked at yet is the one action you cannot undo and did not ask for.
The bell is scoped to you, not to a site. A notification is addressed to a person, so the feed spans everything you are responsible for: site notices and platform-level notices arrive in the same place.
What lands in the bell
Every notification BlackOps sends is recorded, including:
| Type | Sent when |
|---|---|
post_visit | Someone reads one of your posts |
newsletter_signup | A new subscriber joins |
reply_queue_ready | A reply queue has finished building |
daily_traffic_report | The daily traffic summary runs |
new_user_signup, new_site_created | Platform-level account activity |
subscription_started, subscription_canceled, payment_failed | Billing events |
daily_platform_summary | The daily platform digest |
admin_notice | An agent or routine calling send_admin_notification |
That last row is worth calling out. When an agent sends you a notice through send_admin_notification, the notification is recorded before the email is attempted. It appears in your bell whether or not the email lands, and a bounced send leaves a row marked undelivered rather than vanishing.
Delivery status
Each notification tracks its own outcome per channel, and the bell says so quietly on the row rather than pretending everything arrived. The states are:
sent. The channel delivered it. A push that fanned out to several devices also records how many were reached.skipped. The channel was never attempted. Most commonly there was no push subscription to send to, or the notification was email-only by design.failed. The channel tried and could not deliver: an expired push endpoint, a denied permission, a bounced email.pending. The attempt has not finished yet. Nothing is shown on the row while a channel is still pending.
When nothing was delivered anywhere, the row is labelled with the reason: Email failed to send, Not delivered to your devices, or No device to notify. A channel that actually succeeded always wins, so an email-only notice that was emailed successfully is never labelled as undelivered just because it skipped push.
Scope and privacy
- Notifications belong to a person. The feed is filtered by your own user id on the server, taken from your session and never from anything the browser sends. You cannot read, mark, or delete anyone else's notifications, and passing someone else's notification id simply matches nothing.
- Platform-scoped notices have no site. Selecting a site narrows the feed for display, but platform notices stay visible because they belong to you rather than to any one site.
- Nothing can forge a notification. Rows are written only by the server. There is no client-side insert path.
Things to know
- The badge polls roughly every minute, so a brand-new notification can take up to a minute to show up if the bell is already on screen.
- The bell is a feed, not an archive. Deleting is permanent. There is no trash to recover from.
- Visit notifications do not navigate anywhere when clicked. Following one would make you the next visitor and generate the next notification, so the loop is cut deliberately.
- The bell does not replace web push or email. It is the durable record underneath both, and enabling push still gets you the notification on your device in real time.