UC-BEH-FEAT-005 — Systeemnotificatie wijzigen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-FEAT-005 |
| Naam | Systeemnotificatie wijzigen |
| Domein | Beheerder / Features en systeemnotificaties |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, database, autorisatiecomponent, beheerlogcomponent |
| Rolcontext | Actieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker |
| Betrokken schermen | Site Instellingen > Features > tab Systeemnotificaties |
| Gerelateerde usecases | UC-BEH-FEAT-003, UC-BEH-FEAT-008, UC-GEN-NOT-001 |
| Primaire entiteiten | SiteNotifications, SiteNotificationHistory, Users |
| Secundaire entiteiten / events | SiteNotificationChanged |
| Gerelateerde popups | POP-BEH-NOT-EDIT-CONFIRM, POP-BEH-NOT-SAVED, POP-BEH-NOT-SAVE-FAILED |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft hoe een beheerder een bestaande systeemnotificatie wijzigt. Wijzigbare velden zijn de beheerbare inhouds- en planningsvelden: AudienceType, NotificationType, Title, BodyText, StartAtUtc, EndAtUtc en DisplayRule.
De mutatie blijft beperkt tot SiteNotifications en de bijbehorende notificatiehistorie. De gebruikersgerichte verwerking blijft bronhoudend in de generieke systeemnotificatie-usecases.
Alle datum- en statusafleidingen gebruiken UTC als technische bron en lokale tijd uitsluitend voor presentatie.
Uitgangspunten
- Systeemnotificaties zijn geen mailbox-systeemberichten.
- Systeemnotificaties zijn geen popupregister-popups.
- Er bestaat geen server-side per-gebruiker-seentabel.
- De beheerdercontext wordt bij iedere mutatie opnieuw server-side gecontroleerd.
3. Scope
Deze usecase beschrijft:
- Selecteren van één bestaande systeemnotificatie.
- Past beheerbare velden aan.
- Valideren van gesloten sleutelsets en datumregels.
- Vastleggen van notificatiehistorie.
- Verversen van het notificatieoverzicht.
- Wijzigen van inhoud, doelgroep, planning en displayregel.
Deze usecase beschrijft niet:
- Eindgebruikersweergave van de notificatie.
- Aanmaken van mailbox-systeemberichten.
- Aanmaken of wijzigen van popupdefinities.
- Vrij beheren van enumwaarden.
- Server-side gebruikersseenstatus opslaan.
3.1 Afbakening met aangrenzende usecases
| Onderdeel | Afbakening |
|---|---|
| UC-BEH-FEAT-003 | Levert het overzicht en de selectie van de notificatie. |
| UC-BEH-FEAT-008 | Beschrijft de displayregel en gevolgen voor browsermarkers. |
| UC-GEN-NOT-001 | Toont actieve notificaties aan gebruikers. |
4. Pre-condities
| ID | Voorwaarde |
|---|---|
| PRE-001 | De gebruiker is succesvol ingelogd in OefenHub. |
| PRE-002 | De backend heeft server-side vastgesteld dat de gebruiker een actieve beheerderrol heeft. |
| PRE-003 | De Site Instellingen-route is beschikbaar via de beheerdernavigatie. |
| PRE-004 | Clientstate, querystringwaarden of zichtbare UI-elementen bepalen niet zelfstandig de autorisatie. |
| PRE-005 | De systeemnotificatie bestaat. |
| PRE-006 | De beheerder heeft de notificatie geselecteerd vanuit een toegestane beheer-tab. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | De notificatie is bijgewerkt wanneer alle validaties slagen. |
| POST-002 | SiteNotificationHistory bevat de relevante wijziging. |
| POST-003 | Afgeleide status wordt opnieuw berekend in het overzicht. |
| POST-004 | Er is geen server-side seenstatus aangemaakt. |
| POST-005 | Er is geen mailboxbericht of popupdefinitie aangemaakt. |
6. Trigger
De usecase start wanneer de beheerder bij een geselecteerde systeemnotificatie kiest voor systeemnotificatie wijzigen.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Systeemnotificaties-tab | Selecteert een notificatie. | De frontend toont de beheerbare velden. | SiteNotifications. |
| 2 | Beheerder | Detailpaneel | Past beheerbare velden aan. | De frontend toont waar nodig een bevestigingspopup. | PopupKey. |
| 3 | Backend | Autorisatiecomponent | Controleert beheerdercontext opnieuw. | Mutatie wordt alleen bij actieve beheerder verwerkt. | Server-side autorisatie. |
| 4 | Backend | Validatie | Controleert status, sleutelsets, datums en veldlengtes. | Ongeldige invoer wordt geweigerd. | Centrale sleutelsets. |
| 5 | Backend | Database-transactie | Werkt gewijzigde velden van SiteNotifications bij. | De wijziging wordt atomair opgeslagen. | SiteNotifications. |
| 6 | Backend | Historie | Schrijft SiteNotificationHistory met oud en nieuw. | Wijziging is achteraf reconstrueerbaar. | Audit. |
| 7 | Frontend | Overzicht | Ververst de tab en statuslabels. | De beheerder ziet de actuele toestand. | Afgeleide status. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 1 | Notificatie bestaat niet meer. | De backend blokkeert de actie en ververst het overzicht. | Foutpopup. | Geen. |
| ALT-002 | 3 | Beheerdercontext is vervallen. | De backend weigert de mutatie. | Foutpopup. | Geen. |
| ALT-003 | 4 | Veldvalidatie faalt. | De wijziging wordt niet opgeslagen en de beheerder krijgt veldgerichte terugkoppeling. | Foutpopup. | Geen. |
| ALT-004 | 5 | Opslaan of history schrijven faalt. | De transactie wordt teruggedraaid. | Foutpopup. | Geen gedeeltelijke mutatie. |
| ALT-005 | 5 | DisplayRule wordt gewijzigd naar OncePerBrowser. | De nieuwe regel geldt vanaf de wijziging; bestaande browsermarkers voor dezelfde notificatie-id blijven bepalend. | Niet van toepassing. | SiteNotifications update. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Een wijziging aan een notificatie doorbreekt een bestaande OncePerBrowser-browsermarker niet automatisch. |
| BR-002 | Een notificatie blijft een eigen beheerdomein en veroorzaakt geen SystemMessage. |
| BR-003 | EndAtUtc null betekent geen geplande einddatum. |
| BR-004 | Afgeleide statussen worden niet als permanente statuskolom behandeld. |
| BR-005 | Oude en nieuwe veldwaarden worden auditbaar vastgelegd. |
| BR-006 | Wijziging van een OncePerBrowser-notificatie maakt oude browsermarkers niet ongeldig. |
| BR-007 | Bij belangrijke gewijzigde informatie moet beheer een nieuwe notificatie publiceren in plaats van te verwachten dat dezelfde notificatie opnieuw verschijnt. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | Title blijft maximaal 50 tekens. |
| VAL-002 | BodyText blijft maximaal 1000 tekens. |
| VAL-003 | AudienceType, NotificationType en DisplayRule blijven gesloten sleutelsets. |
| VAL-004 | EndAtUtc mag niet vóór StartAtUtc liggen. |
| VAL-005 | Datum/tijd wordt technisch in UTC opgeslagen. |
| VAL-006 | De geselecteerde notificatie moet bestaan en wijzigbaar zijn vanuit de betreffende tab. |
11. Datamutaties en events
| ID | Mutatie / event | Toelichting |
|---|---|---|
| MUT-001 | SiteNotifications update | Werkt gewijzigde velden van SiteNotifications bij. |
| MUT-002 | SiteNotificationHistory insert | Oude en nieuwe waarden plus actor en tijdstip worden vastgelegd. |
| MUT-003 | SiteNotificationChanged event | Interne gebeurtenis voor beheerhistorie en readmodelverversing. |
12. Geen datamutaties
| ID | Geen mutatie | Reden |
|---|---|---|
| NO-001 | SystemMessages | Geen mailbox-systeembericht. |
| NO-002 | PopupDetails | Geen popupdefinitie. |
| NO-003 | Gebruikersseenstatus | Geen server-side seenrecord. |
| NO-004 | Browsermarkers | Beheer wijzigt browsermarkers van gebruikers niet. |
| NO-005 | Andere notificaties | Andere records blijven ongewijzigd. |
13. State diagram
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
Deze usecase verwijst uitsluitend naar PopupKey. Popupteksten, knopteksten, inputlabels en themakeuzes blijven bronhoudend in het popupregister en popup-themes.
| PopupKey | Gebruik |
|---|---|
| POP-BEH-NOT-EDIT-CONFIRM | Zie popupregister voor tekst en knoppen. |
| POP-BEH-NOT-SAVED | Zie popupregister voor tekst en knoppen. |
| POP-BEH-NOT-SAVE-FAILED | Zie popupregister voor tekst en knoppen. |
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Document | Afleiding |
|---|---|
| Functioneel Ontwerp | Beschrijft beheeracties binnen Systeemnotificaties-tab. |
| Technisch Ontwerp | Technisch Ontwerp: communicatie en systeemnotificaties, readmodels en badges en frontendstate beschrijven de technische uitwerking. Vraagt transactionele update, UTC-datumverwerking en history. |
| Software Requirements Specification | Levert eisen voor validatie, audit en scheiding van notificatiedomeinen. |
19. SRS-trace
Deze usecase bevat geen normatieve requirementtekst. De centrale eis en acceptatiecriteria staan in de SRS; onderstaande tabel koppelt de usecase-afleiding alleen aan centrale SRS-*- en AC-*-items.
| Usecase-afleiding | Dekt | Usecasecontext |
|---|---|---|
UC-BEH-FEAT-005-REQ-001 | SRS-AUTH-001 SRS-ADM-001 SRS-POP-002 AC-AUTH-001 AC-ADM-001 AC-POP-002 | Bestaande systeemnotificaties kunnen wijzigen zolang de beheerder bevoegd is |
UC-BEH-FEAT-005-REQ-002 | SRS-ADM-001 SRS-POP-005 AC-ADM-001 AC-POP-005 | Duidelijk maken dat OncePerBrowser-markers niet automatisch worden doorbroken door wijzigingen |
UC-BEH-FEAT-005-REQ-003 | SRS-ADM-001 SRS-POP-002 SRS-NFR-AUD-001 AC-ADM-001 AC-POP-002 AC-NFR-AUD-001 | Wijzigingen aan systeemnotificaties auditbaar vastleggen |
UC-BEH-FEAT-005-REQ-004 | SRS-AUTH-001 SRS-ADM-001 AC-AUTH-001 AC-ADM-001 | Geen server-side seenstatus per gebruiker aanmaken |
UC-BEH-FEAT-005-REQ-005 | SRS-RDM-001 SRS-ADM-001 AC-RDM-001 AC-ADM-001 | Statuslabels na wijziging opnieuw afleiden uit StartAtUtc en EndAtUtc |