feat(notifications): wire the top-bar bell to the in-app inbox #97
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/mapps-132-notification-bell"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
MAPPS-132: the top-bar notifications bell did not work. It was a disabled stub (
disabled=true, "Notifications coming soon" tooltip) with a hard-coded always-on red dot. The frontend docs recorded the server endpoint as501, so the bell was left decorative.That note was stale. The server
notificationsmodule is implemented and mounted inmokosh-server(src/api/router.rsmergesnotifications_routes), servingGET /api/v1/notifications(the in-app inbox,channel_type='in_app', newest-first, paginated) andPOST /api/v1/notifications/{id}/read. So the feature is a pure frontend wiring job, no server change needed.Change
NotificationBellcomponent in the TopBar (src/components/layout.rs): fetches the inbox viause_resource, subscribed to the active-tenant generation so it refetches on org switch, and degrades to an empty inbox on fetch error (no error surfaced in the chrome).read_atis null) instead of being hard-coded on.src/hooks/fetch.rs: addedpost_authed_no_content/post_no_content_with_auth. The mark-read endpoint returns an empty200, which the JSON-parsingpost_authedcannot decode; these status-only POST helpers mirrordelete_with_auth.client-server-integration.mdrow 17,codebase-state.mditem 24). The/settings/notificationspreferences page remains a separate stub and is unchanged.Verification
mokosh-server: route mounted inapi/router.rs;list_inbox/mark_readhandlers inmodules/notifications/{routes,service}.rs; response is{ data: [...], meta: {...} }withNotificationInboxItemResponseitems (id, subject, body, read_at, created_at), matching the client DTO.pages/dashboard.rs):use_resource+active_tenant_generation()+read_unchecked().clone().unwrap_or_default(), and the{ data }paginated envelope decode.Manual test checklist (post-merge, real env)
#MAPPS-132
The notifications bell was a disabled stub (`disabled=true`, "coming soon" tooltip, a hard-coded always-on red dot) because the frontend docs recorded the server notifications endpoint as 501. That note was stale: the server `notifications` module is implemented and mounted, serving `GET /api/v1/notifications` (the in-app inbox, newest-first) and `POST /api/v1/notifications/{id}/read`. This wires the bell to it. `NotificationBell` (in the TopBar) fetches the inbox with `use_resource`, subscribed to the active-tenant generation so it refetches on org switch, and degrades to an empty inbox on fetch error. The red dot now reflects the real unread count (`read_at IS NULL`) instead of being hard-coded. Clicking the bell opens a dropdown panel listing items (subject, body, timestamp) with a "No notifications yet" empty state. Clicking an unread row POSTs the mark-read endpoint and refetches so the row and the dot update. `mark_read` returns an empty 200 body, which the JSON-parsing `post_authed` cannot decode, so `fetch.rs` gains `post_authed_no_content` / `post_no_content_with_auth` (status-only POST, mirroring `delete_with_auth`). The stale dev-docs rows (client-server-integration row 17, codebase-state item 24) are corrected to reflect that the inbox endpoints exist and the bell is wired. The `/settings/notifications` preferences page remains a separate stub and is unchanged. Note: no Rust toolchain is available in this environment, so this was not compiled locally; CI is expected to build it. #MAPPS-132 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>