UC-BEH-POP-006 — Custom-popup beperking toepassen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-POP-006 |
| Naam | Custom-popup beperking toepassen |
| Domein | Beheerder / Popupbeheer |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, autorisatiecomponent, database |
| Rolcontext | Actieve beheerdercontext; combinatierollen geven geen extra rechten binnen popupbeheer |
| Betrokken schermen | Site Instellingen > Popups beheren |
| Gerelateerde usecases | UC-BEH-POP-002, UC-BEH-POP-003, UC-BEH-POP-004 |
| Primaire entiteiten | PopupDetails |
| Secundaire entiteiten / events | PopupType, PopupVariant, PopupInputType, ButtonTheme, Users, popup-register, popup-themes |
| Gerelateerde popups | POP-BEH-GEN-VALIDATION-FAILED |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Het systeem past de functionele beperking toe dat afwijkende popup-layouts, meerdere inputvelden en custom rendering uitsluitend via bestaande Variant = Custom-records met een codegedreven renderer worden ondersteund. De beheerder kan deze technische keuze niet via de GUI wijzigen.
Popupbeheer is geen vrije popupbuilder. Het beheer werkt binnen bestaande popuprecords en respecteert de scheiding tussen beheerbare inhoud en codegedreven structuur. Popupteksten, knopteksten, acties, inputvelden en themekeuzes worden niet in usecases gedupliceerd.
3. Scope
Deze usecase beschrijft:
- Herkennen of een popuprecord een Custom-popup is.
- Tonen van
CustomRendererKeyals read-only technische referentie. - Blokkeren dat normale dynamische popups via beheer een afwijkende layout of meerdere invoervelden krijgen.
- Beperken van beheerbare velden bij Custom-popups tot de velden die expliciet veilig beheerbaar zijn.
- Voeden van server-side validatie bij opslaan via
UC-BEH-POP-004.
Deze usecase beschrijft niet:
- Nieuwe popuprecords aanmaken via de GUI.
- Popuprecords verwijderen of deactiveren via de GUI.
PopupKey,Variant,ThemeKey, knopacties ofCustomRendererKeywijzigen.- Popup-themes beheren.
- Runtime bepalen wanneer popups in gebruikersflows verschijnen.
- Popupteksten of knopteksten buiten het popupregister dupliceren.
- Onderliggende code, migraties of seeddefinities wijzigen via de beheerinterface.
4. Pre-condities
| ID | Voorwaarde |
|---|---|
| PRE-001 | De gebruiker is ingelogd en heeft een actief intern OefenHub-account. |
| PRE-002 | De gebruiker heeft server-side een actieve beheerderrol. |
| PRE-003 | De route of actie ligt binnen Site Instellingen > Popups beheren. |
| PRE-004 | De frontend gebruikt actuele serverrespons en vertrouwt niet op oude clientstate. |
| PRE-005 | Popupregister en popup-themes zijn als bronafspraak beschikbaar voor interpretatie van popuprecords. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | De beheerinterface maakt duidelijk of een popup een normale dynamische popup of bestaande Custom-popup is. |
| POST-002 | Custom-renderer en afwijkende layout blijven codegedreven en read-only. |
| POST-003 | Niet-custom popups kunnen niet via beheer tot custom-layout worden gemaakt. |
| POST-004 | Deze controle voert zelf geen databasewijziging uit. |
6. Trigger
De controle wordt toegepast wanneer een beheerder een popupdetail opent, popupvelden wijzigt of een popupwijziging opslaat.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Backend | Popupservice | Leest Variant en rendererinformatie van het bestaande popuprecord. | Systeem bepaalt normale of Custom-beperking. | PopupDetails. |
| 2 | Backend | Veldmetadataservice | Bepaalt welke velden beheerbaar zijn. | CustomRendererKey en layout blijven read-only. | Popupregister en code. |
| 3 | Frontend | Popupdetail | Toont beperking aan beheerder. | Beheerder ziet welke velden wel en niet beheerbaar zijn. | Geen mutatie. |
| 4 | Frontend | Editor | Voorkomt wijziging van variant, renderer of layout. | Alleen toegestane tekstvelden kunnen worden aangepast. | UC-BEH-POP-003. |
| 5 | Backend | Validatieservice | Controleert bij opslaan opnieuw of customregels niet worden overschreden. | Ongeldige payload wordt geweigerd. | UC-BEH-POP-004. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 1 | Record bestaat niet. | Controle stopt met veilige niet-beschikbaarafhandeling. | Inline melding. | Geen. |
| ALT-002 | 2 | CustomRendererKey ontbreekt bij een Custom-popup. | Detail blijft veilig raadpleegbaar; renderer wordt niet via beheer hersteld. | Inline technische beperking. | Geen. |
| ALT-003 | 4 | Beheerder probeert variant of renderer te wijzigen. | UI blokkeert wijziging; backend weigert payload bij opslag. | Inline validatie of POP-BEH-GEN-VALIDATION-FAILED. | Geen binnen deze usecase. |
| ALT-004 | 5 | Niet-custom popup probeert meerdere inputvelden te krijgen. | Opslag wordt geblokkeerd via UC-BEH-POP-004. | POP-BEH-GEN-VALIDATION-FAILED of inline fout. | Geen. |
9. Business rules
| ID | Regel |
|---|---|
| BR-UC-BEH-POP-006-001 | Custom-popups zijn bestaande codegedreven uitzonderingen, geen GUI-configuratievorm. |
| BR-UC-BEH-POP-006-002 | CustomRendererKey is read-only en kan niet via beheer worden gewijzigd. |
| BR-UC-BEH-POP-006-003 | Een normale dynamische popup mag niet via beheer meerdere inputvelden of afwijkende layout krijgen. |
| BR-UC-BEH-POP-006-004 | Variantwijziging is geen beheeractie en vereist code en migratie. |
| BR-UC-BEH-POP-006-005 | Custom-popups kunnen alleen beheerbare tekstvelden tonen wanneer de bestaande definitie dit veilig ondersteunt. |
10. Datavalidatie
| Veld / object | Validatie |
|---|---|
| Beheerdercontext | Server-side actieve beheerderrol verplicht. |
| Popuprecord | Het record moet bestaan en als bestaand popuprecord bekend zijn. |
| PopupKey | Moet bestaan en blijft read-only. |
| Variant | Moet een bekende PopupVariant zijn en blijft read-only. |
| ThemeKey | Blijft read-only en moet verwijzen naar een bestaande themedefinitie. |
| Knopacties | ActionCallMethod en technische actie-identifiers zijn read-only. |
| CustomRendererKey | Alleen relevant bij Custom-popups en blijft read-only. |
| Titel | Maximaal 50 tekens wanneer beheerbaar. |
| Tekst | Maximaal 1000 tekens wanneer beheerbaar. |
| Knoptekst | Maximaal 20 tekens per zichtbare knop wanneer beheerbaar. |
| Inputlabel | Alleen beheerbaar wanneer de bestaande variant een inputveld ondersteunt. |
| Rendering | Beheerbare tekst mag geen actieve of onveilige inhoud veroorzaken. |
| Tijdstip | Wijzigingsmomenten worden in UTC vastgelegd. |
11. Datamutaties en events
| Stap | Type | Entiteit / event | Mutatie |
|---|---|---|---|
| Alle stappen | Database | Niet van toepassing | Custom-beperking toepassen is controle- en validatiegedrag zonder eigen databasewijziging. |
12. Geen datamutaties
| Entiteit | Reden |
|---|---|
| PopupDetails | Deze usecase leest variant- en rendererinformatie maar wijzigt die niet. |
| CustomRendererKey | Blijft codegedreven en read-only. |
| PopupKey, Variant, ThemeKey en ActionCallMethod | Blijven technische ankers buiten GUI-mutatie. |
| PopupDetailsHistory | Alleen succesvolle opslag via UC-BEH-POP-004 registreert history. |
| Popupregister en popup-themes | Bronafspraken worden niet door de beheercontrole gewijzigd. |
13. State diagram
Deze usecase heeft geen persistent state diagram. De custombeperking is validatie- en veldmetadatagedrag en geen statusmodel.
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
Usecases verwijzen alleen naar PopupKey. Popupteksten, knopteksten, acties, inputvelden en themakeuzes worden centraal beheerd in het popupregister en de popup-themes.
| PopupKey | Moment | Doel |
|---|---|---|
| POP-BEH-GEN-VALIDATION-FAILED | Wanneer een payload de custombeperking of variantgrens overschrijdt. | Aangeven dat de wijziging niet binnen popupbeheer is toegestaan. |
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Doeldocument | Afleiding |
|---|---|
| Functioneel Ontwerp | Beschrijft welke popupvelden beheerbaar zijn, welke velden read-only blijven en hoe de beheerder bestaande popuprecords raadpleegt of wijzigt. |
| Technisch Ontwerp | Technisch Ontwerp: domeinmodel en admin-eigenaarschap, databaseontwerp en frontendcompositie beschrijven de technische uitwerking. Beschrijf server-side autorisatie, readmodelopbouw en geen command- of eventregisteruitbreiding voor read-only raadpleegacties, inclusief bescherming van technische sleutels en codegedreven velden. |
| Software Requirements Specificatie | Beschrijft requirements voor toegangscontrole, validatiegrenzen, veilige foutafhandeling, immutable history en de scheiding tussen beheerbare tekst en technische popupdefinities. |
| Database-informatie | Controleer aansluiting van PopupDetails, PopupDetailsHistory en PopupDetailsHistoryItems, inclusief veldlengtes, concurrency en auditvelden. |
| Ontwerpbronnen en registers | Houd popupregister, popup-themes, autorisatiematrix, usecase-popup-matrix en usecase-requirement-matrix consistent met deze usecase. |
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 |
|---|---|---|
REQ-UC-BEH-POP-006-001 | SRS-ADM-002 SRS-ADM-001 AC-ADM-002 AC-ADM-001 | De actie uitsluitend toestaan aan gebruikers met een actieve beheerderrol |
REQ-UC-BEH-POP-006-002 | SRS-AUTH-001 SRS-AUTH-002 SRS-ADM-002 SRS-ADM-001 AC-AUTH-001 AC-AUTH-002 AC-ADM-002 AC-ADM-001 | Alle beheerautorisatie server-side controleren en mag niet vertrouwen op clientstate of routeparameters |
REQ-UC-BEH-POP-006-003 | SRS-AUTH-004 SRS-ACC-003 SRS-ACC-005 SRS-ADM-001 SRS-POP-001 SRS-NFR-SEC-001 AC-AUTH-004 AC-ACC-003 AC-ACC-005 AC-ADM-001 AC-POP-001 AC-NFR-SEC-001 | Onbekende, ontbrekende of niet-toegankelijke popuprecords veilig afhandelen zonder technische details te tonen |
REQ-UC-BEH-POP-006-004 | SRS-ADM-001 SRS-POP-001 AC-ADM-001 AC-POP-001 | PopupKey, Variant, ThemeKey, knopacties en CustomRendererKey read-only houden in de beheerinterface |
REQ-UC-BEH-POP-006-005 | SRS-ADM-001 SRS-POP-001 AC-ADM-001 AC-POP-001 | Popupteksten, knopteksten, inputlabels en themekeuzes niet dupliceren buiten het centrale popupregister en popup-themes |
REQ-UC-BEH-POP-006-006 | SRS-ADM-002 SRS-ADM-001 SRS-POP-001 SRS-NFR-AUD-001 AC-ADM-002 AC-ADM-001 AC-POP-001 AC-NFR-AUD-001 | Deze raadpleeg- of controleflow uitvoeren zonder PopupDetails of historyrecords te wijzigen |
REQ-UC-BEH-POP-006-007 | SRS-RDM-001 SRS-ADM-001 AC-RDM-001 AC-ADM-001 | Zoek-, filter-, selectie- en detailacties behandelen als read-only readmodelgedrag |
REQ-UC-BEH-POP-006-009 | SRS-ADM-001 SRS-POP-001 AC-ADM-001 AC-POP-001 | Custom-popups behandelen als bestaande codegedreven uitzonderingen met read-only CustomRendererKey |
REQ-UC-BEH-POP-006-010 | SRS-ADM-001 SRS-POP-001 AC-ADM-001 AC-POP-001 | Voorkomen dat een normale dynamische popup via beheer een afwijkende layout of meerdere invoervelden krijgt |
REQ-UC-BEH-POP-006-011 | SRS-ADM-001 SRS-POP-001 AC-ADM-001 AC-POP-001 | De usecase Custom-popup beperking toepassen uitvoeren binnen de afbakening van Beheerder / Popupbeheer |