kovakmedya
2762aceb04
Modelled the real crown-and-bridge workflow (impression → accept →
framework try-in → bisque try-in → glaze/cila → delivery, with revisions
bouncing back at any try-in stage). Mapped every event in our system to
the appropriate side and tagged the ones a user actually needs to act on
versus normal progress traffic.
DB
- notifications.severity enum ('info' | 'warning', default 'info').
Existing rows default to info.
Helper
- createNotification gains an optional severity param; persists into
the new column.
Matrix changes (warnings vs infos)
Lab side:
- Düzeltme talebi (clinic → lab) WARNING
- İş iptal edildi (counterpart action) WARNING
Clinic side:
- Ödeme reddedildi (lab → clinic) WARNING
- Bağlantı reddedildi (counterpart → req) WARNING (newly fired —
rejectConnectionAction now sends a notification, previously silent)
Everything else (accept, hand-off, prova ready, prova approved,
delivery, payment submitted/approved, connection request/approved):
stays at info.
Behaviour additions in actions
- cancelJobAction now notifies the *other* party. Previously cancelled
jobs vanished from one side's inbox without warning. severity=warning.
- rejectConnectionAction notifies the requester (severity=warning) so
they know the connection didn't come through.
- requestRevisionAction tags its existing notification as warning.
- rejectPaymentAction tags its existing notification as warning.
UI
- Notifications list row: unread warning rows get an amber dot, an
amber-tinted background, and a 'Dikkat' destructive badge instead
of the regular 'Yeni' secondary one.
- Dashboard recent-notifications widget mirrors the same dot + bold
treatment so warnings stand out at a glance.
Net result: a user opening the bell sees normal traffic muted (still
listed for the 'herkes her şeyden haberdar' guarantee) and the things
that actually need them coloured amber and labeled Dikkat.