feat(notifications): click a notification to jump to its related page
CI/CD / CI · API (dotnet build + test) (push) Successful in 42s
CI/CD / CI · Admin API (dotnet build) (push) Successful in 28s
CI/CD / CI · Dashboard (tsc) (push) Successful in 1m9s
CI/CD / CI · Admin Web (tsc) (push) Successful in 37s
CI/CD / CI · Website (tsc) (push) Successful in 45s
CI/CD / CI · Koja (tsc) (push) Successful in 49s
CI/CD / Deploy · all services (push) Successful in 2m45s

Every notification surface now deep-links to where the staff member needs to act:
- bell dropdown: clicking an actionable notification navigates and closes the
  dropdown (platform broadcasts still expand inline to show their text)
- notifications page: rows navigate to the right page
- in-app toast: gains a "View" action button
- desktop/Windows popup: clicking it focuses the tab and navigates

Routing is now permission-aware via a single resolver (notification-routes.ts):
a new-order alert sends a kitchen user to /kds, a cashier to /pos, and a floor
user to /tables — never to a page their role can't open; a waiter call → /tables.
This also fixes the old bug where table_call_waiter (which carries a referenceId)
wrongly routed to /kds. Toast/desktop clicks navigate client-side through a small
event bridge mounted in the dashboard shell.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
soroush.asadi
2026-06-21 06:08:18 +03:30
parent 2cff5051ac
commit 3dfcb1585b
7 changed files with 121 additions and 5 deletions
+5
View File
@@ -4,12 +4,17 @@ import { ApiClientError } from "@/lib/api/client";
export type NotifyOptions = {
description?: string;
duration?: number;
/** Optional click-through button (e.g. "View" → navigate to the related page). */
action?: { label: string; onClick: () => void };
};
function baseOptions(opts?: NotifyOptions) {
return {
description: opts?.description,
duration: opts?.duration ?? 4000,
action: opts?.action
? { label: opts.action.label, onClick: opts.action.onClick }
: undefined,
};
}