UC-BEH-FRONT-004 — Frontpagewijziging opslaan
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-FRONT-004 |
| Naam | Frontpagewijziging opslaan |
| Domein | Beheerder / Frontpagebeheer |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, autorisatiecomponent, database, historyservice |
| Rolcontext | Actieve beheerdercontext; overige combinatierollen geven geen extra beheerrechten binnen deze usecase |
| Betrokken schermen | Site Instellingen > Frontpagebeheer, contexttabs, contentblokeditor, previewblok, geschiedenisdeel |
| Gerelateerde usecases | UC-BEH-FRONT-003, UC-BEH-FRONT-005 |
| Primaire entiteiten | ContentBlocks, ContentBlockHistory, Users |
| Secundaire entiteiten / events | DomainType, ContextType, ContentBlockHistory, frontpage-readmodels |
| Gerelateerde popups | POP-BEH-GEN-SAVE-FAILED, POP-BEH-GEN-VALIDATION-FAILED, POP-BEH-GEN-UNSAVED-CHANGES |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
De beheerder slaat een frontpagewijziging op. Het systeem valideert context, blokkey en inhoud, schrijft de nieuwe waarden weg en registreert de wijziging historisch.
Frontpagebeheer beheert tekstuele inhoud binnen vooraf bepaalde frontpagecontexten. De beheerder kan inhoud per context bekijken, aanpassen en historie raadplegen, maar de structurele pagina-opbouw blijft codegedreven.
De usecase gebruikt als functionele basis: DomainType = FrontPage en ContextType = Public, NoRole, Admin, Teacher, Student of Guardian. Dit betekent dat de beheerinterface geen vrije technische constructies introduceert, maar alleen werkt binnen de bestaande sleutelsets, records en codevaste ankers.
De usecase is bedoeld als definitieve functionele beschrijving voor het verdere FO-, TO- en SRS-traject. Daarom wordt expliciet vastgelegd welke gegevens wel worden gelezen of gewijzigd, welke gegevens bewust niet worden gewijzigd en welke validaties altijd server-side moeten plaatsvinden.
Uitgangspunten
- De beheerdercontext is altijd server-side leidend.
- De beheerinterface maakt onderscheid tussen beheerbare inhoud en technische ankers.
- History is onderdeel van het functionele resultaat wanneer een beheerder een wijziging opslaat.
- Zoeken, filteren, contextselectie en detailopenen zijn read-only totdat expliciet wordt opgeslagen.
- Onbekende of gemanipuleerde identifiers worden veilig geblokkeerd.
- De gebruikersinterface toont geen technische stacktraces of interne databasefouten.
- Domeinoverschrijdende bijwerkingen zijn uitgesloten tenzij een usecase die expliciet benoemt.
- De uitwerking volgt de centrale popup-, DRY- en ontwerpbronafspraken.
3. Scope
Deze usecase beschrijft:
- De beheerder slaat een frontpagewijziging op. Het systeem valideert context, blokkey en inhoud, schrijft de nieuwe waarden weg en registreert de wijziging historisch.
- Server-side controleren dat de gebruiker beheerder is.
- Werken binnen de afbakening van Beheerder / Frontpagebeheer.
- Gebruik van DomainType = FrontPage en ContextType = Public, NoRole, Admin, Teacher, Student of Guardian.
- Scheiding tussen beheerbare velden en codegedreven of read-only velden.
- Veilige fout-, lege-staat- en blokkadeafhandeling.
- Historyregistratie bij iedere opgeslagen contentwijziging.
- Readmodelverversing na succesvolle opslag of validatieafwijzing.
- Voorkomen dat deze beheeractie onbedoeld andere domeinen wijzigt.
Deze usecase beschrijft niet:
- Vrij bouwen van frontpages als pagebuilder.
- Wijzigen van de vaste volgorde, layout of renderlogica van frontpageblokken.
- Beheren van systeemnotificaties of featuretoggles.
- Aanpassen van docent-, leerling- of ouder-/voogdgegevens.
- Wijzigen van de runtime-prioriteitsregels voor gecombineerde rolfrontpages.
- Wijzigen van accounts, rollen of sessies buiten de autorisatiecontrole.
- Maken of wijzigen van oefenruns, resultaten, relaties, meldingen of privéberichten.
- Aanpassen van onderliggende code, migraties of seeddefinities 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 bezit een actieve beheerderrol. |
| PRE-003 | De beheerder opent de relevante route via Site Instellingen of een onderliggende beheerpagina. |
| PRE-004 | De relevante records of contexten voor Beheerder / Frontpagebeheer zijn aanwezig of kunnen als veilige lege staat worden getoond. |
| PRE-005 | De server-side autorisatiecomponent is beschikbaar. |
| PRE-006 | De database en historytabellen zijn beschikbaar voor read-only of muterende acties. |
| PRE-007 | De frontend gebruikt de actuele serverrespons en niet alleen eerder opgeslagen clientstate. |
| PRE-008 | Eventuele feature- of routebeschikbaarheid is door de applicatieconfiguratie toegestaan. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | De usecase "Frontpagewijziging opslaan" is uitgevoerd binnen de beheerdercontext. |
| POST-002 | De beheerder ziet een actuele, veilige weergave of een duidelijke blokkade. |
| POST-003 | Read-only acties hebben geen domeinmutatie uitgevoerd. |
| POST-004 | Muterende acties hebben uitsluitend toegestane velden gewijzigd. |
| POST-005 | Wanneer een wijziging is opgeslagen, is history of auditinformatie vastgelegd. |
| POST-006 | Wanneer validatie faalt, zijn geen gedeeltelijke wijzigingen opgeslagen. |
| POST-007 | Technische sleutels en codegedreven velden zijn ongewijzigd gebleven. |
| POST-008 | Andere domeinen zoals accounts, meldingen, relaties en oefenruns zijn niet gewijzigd. |
6. Trigger
De usecase start wanneer de beheerder de actie Frontpagewijziging opslaan uitvoert binnen het beheeronderdeel Beheerder / Frontpagebeheer.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Contentblokeditor | Kiest Opslaan voor een gewijzigd frontpagecontentblok. | Frontend verzamelt BlockKey, ContextType, recordversie en gewijzigde beheerbare velden. | Commandpayload. |
| 2 | Frontend | Validatielaag | Voert basiscontrole uit. | Onvolledige invoer kan direct worden gemarkeerd. | Clientcontrole is ondersteunend. |
| 3 | Backend | Autorisatiecomponent | Controleert actieve beheerdercontext. | Zonder beheerderrol stopt de verwerking. | Server-side verplicht. |
| 4 | Backend | Contentblokservice | Laadt bestaande recordversie. | Het systeem controleert of het blok nog bestaat en binnen DomainType = FrontPage valt. | Concurrency. |
| 5 | Backend | Validatieservice | Controleert context, BlockKey, veldrechten, lengte en veilige inhoud. | Ongeldige waarden worden als veldspecifieke terugkoppeling geretourneerd. | Domeinvalidatie. |
| 6 | Backend | Validatieservice | Controleert dat uitsluitend beheerbare tekstvelden zijn gewijzigd. | Read-only payloadvelden worden geweigerd. | Technische ankers blijven ongewijzigd. |
| 7 | Backend | Domeinservice | Past de wijziging toe wanneer alle controles slagen. | Alleen toegestane contentvelden, UpdatedAtUtc en UpdatedByUserId worden bijgewerkt. | ContentBlocks. |
| 8 | Backend | Historyservice | Registreert wijzigingsmoment en veldverschillen. | Wijzigingshistorie toont actor, UTC-tijdstip, veld, oude waarde en nieuwe waarde. | ContentBlockHistory. |
| 9 | Backend | Frontend | Levert opgeslagen record en bevestiging. | Frontend toont actuele opgeslagen waarden. | Geen popuptekst dupliceren. |
| 10 | Frontend | Beheerpagina | Ververs overzicht of detail. | De nieuwe waarde is direct zichtbaar in de beheercontext. | Readmodelverversing. |
| 11 | Runtime | Frontpagecontent | Gebruikt gewijzigde content volgens normale cache- en herlaadgrenzen. | De structurele route, layout en blokvolgorde blijven ongewijzigd. | Geen route- of layoutmutatie. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 3 | De gebruiker heeft geen actieve beheerderrol. | Backend blokkeert de actie en toont geen beheerdata. | Inline toegang geweigerd of veilige redirect. | Geen. |
| ALT-002 | 4 | Het contentblok bestaat niet of hoort niet bij DomainType = FrontPage. | Opslaan wordt geweigerd. | Inline niet-beschikbaarmelding. | Geen. |
| ALT-003 | 4 | De recordversie is intussen gewijzigd. | Opslaan wordt geweigerd; beheerder moet actuele waarden opnieuw laden. | Inline conflictmelding. | Geen. |
| ALT-004 | 5 | ContextType of BlockKey is onbekend. | Backend weigert de payload. | Inline validatie. | Geen. |
| ALT-005 | 5 | Een beheerbaar tekstveld overschrijdt lengte- of veiligheidsgrenzen. | Opslaan wordt geweigerd en het veld krijgt terugkoppeling. | Inline validatie. | Geen. |
| ALT-006 | 6 | Een read-only veld is gewijzigd in de payload. | Backend weigert de opslag. | Inline foutmelding. | Geen. |
| ALT-007 | 7 | Er is geen daadwerkelijke wijziging. | Het systeem slaat niets op en toont de actuele toestand. | Inline melding. | Geen. |
| ALT-008 | 8 | Historyregistratie faalt. | De volledige opslagtransactie wordt teruggedraaid. | Veilige foutmelding. | Geen blijvende mutatie. |
| ALT-009 | 7 | De databaseactie faalt technisch. | De wijziging wordt niet gedeeltelijk opgeslagen. | Veilige foutmelding. | Geen of rollback. |
| ALT-010 | 11 | Cache- of readmodelverversing faalt na succesvolle opslag. | De opgeslagen brondata blijft leidend; de UI moet opnieuw laden. | Veilige melding. | Contentwijziging en history blijven consistent. |
9. Business rules
| ID | Regel |
|---|---|
| BR-UC-BEH-FRONT-004-001 | Frontpagebeheer beheert alleen inhoud binnen vooraf codevast bekende bloklocaties. |
| BR-UC-BEH-FRONT-004-002 | De frontpage-layout, blokvolgorde en structurele aanwezigheid van blokken blijven codegedreven. |
| BR-UC-BEH-FRONT-004-003 | Gecombineerde rolfrontpages worden runtime samengesteld uit basiscontexten en krijgen geen zelfstandig persistent frontpageontwerp. |
| BR-UC-BEH-FRONT-004-004 | Alle wijzigingen in beheerbare contentvelden worden veldniveau of changesetniveau historisch vastgelegd. |
| BR-UC-BEH-FRONT-004-005 | Contentwijzigingen mogen geen autorisaties, navigatierechten of zichtbare gegevenssets wijzigen. |
| BR-UC-BEH-FRONT-004-006 | De beheerder mag alleen contexten beheren waarvoor de applicatie een bekende frontpagecontext ondersteunt. |
| BR-UC-BEH-FRONT-004-007 | Opslaan is alleen toegestaan wanneer minstens één beheerbaar veld daadwerkelijk gewijzigd is. |
| BR-UC-BEH-FRONT-004-008 | Eén opslaanactie registreert een samenhangend historymoment met veldniveauverschillen waar het datamodel dat ondersteunt. |
| BR-UC-BEH-FRONT-004-009 | De backend voert alle validaties opnieuw uit, ook wanneer de frontend al voorvalidatie heeft gedaan. |
10. Datavalidatie
| Veld / object | Validatie |
|---|---|
| Beheerdercontext | De gebruiker moet server-side een actieve beheerderrol hebben. |
| Recordtoegang | Het record, blok of template moet binnen het gevraagde subdomein bestaan. |
| Read-only velden | Technische sleutels, actie-identifiers en codegedreven velden mogen niet via de GUI worden gewijzigd. |
| Concurrency | Opslaan moet de actuele recordversie controleren zodat overschrijven van nieuwere wijzigingen wordt voorkomen. |
| DomainType | Moet FrontPage zijn voor frontpagebeheer. |
| ContextType | Moet een bekende frontpagecontext zijn: Public, NoRole, Admin, Teacher, Student of Guardian. |
| BlockKey | Moet verwijzen naar een bestaande codevaste bloklocatie. |
| Titel en tekstvelden | Mogen niet als vrije layoutcomponent worden geïnterpreteerd en moeten veilig worden opgeslagen en gerenderd. |
| Geschiedenis | Moet oude en nieuwe waarde, veldnaam, actor en tijdstip kunnen tonen. |
| Gecombineerde context | Mag niet als zelfstandig persistent ontwerp worden opgeslagen. |
| Auditactor | UpdatedByUserId of ChangedByUserId moet naar de uitvoerende beheerder of systeemactor verwijzen. |
| Tijdstip | Wijzigingsmomenten worden in UTC vastgelegd. |
| Rendering | Beheerbare tekst moet veilig worden opgeslagen en gerenderd zonder actieve inhoud. |
| Lege waarden | Verplichte zichtbare velden mogen niet leeg worden opgeslagen wanneer de runtime ze nodig heeft. |
11. Datamutaties en events
| Stap | Type | Entiteit / event | Mutatie |
|---|---|---|---|
| Opslaan | Update | ContentBlocks | Beheerbare titel-, tekst- of knoptekstvelden worden bijgewerkt binnen DomainType FrontPage en de gekozen ContextType. |
| Opslaan | Insert | ContentBlockHistory | Wijziging wordt vastgelegd met actor, tijdstip, veld en oude/nieuwe waarde. |
Transactionele uitgangspunten
- Een muterende beheeractie wordt atomair verwerkt.
- Historyregistratie is onderdeel van dezelfde functionele verwerking wanneer audit verplicht is.
- Bij validatiefouten wordt niets gedeeltelijk opgeslagen.
- Bij technische fouten wordt een veilige foutmelding getoond zonder interne details.
- Readmodelverversing na opslaan is afgeleid en vormt geen extra bronrecord.
12. Geen datamutaties
| Entiteit | Reden |
|---|---|
| Users, Roles en UserRoles | Worden alleen gebruikt voor autorisatiecontrole; rollen of accounts worden niet gewijzigd. |
| Runtime gebruikersdata | Deze beheerusecase wijzigt geen leerling-, docent- of ouder-/voogddata. |
| Tickets en meldingen | Meldingenbeheer blijft in het generieke meldingendomein. |
| ExerciseRuns en resultaten | Oefenruns, geschiedenis en resultaten worden niet aangepast. |
| Relaties en uitnodigingen | Relatiebeheer wordt niet vanuit deze beheerpagina uitgevoerd. |
| Frontpage layoutdefinities in code | Blokvolgorde, structuur en renderlogica worden niet via data gewijzigd. |
| Gecombineerde frontpageontwerpen | Er wordt geen persistent ontwerp per rolcombinatie aangemaakt. |
13. State diagram
Niet van toepassing. Deze usecase wijzigt geen zelfstandig statusobject. De relevante toestanden zijn scherm-, editor- of readmodeltoestanden en worden in de decision flow en het data lifecycle diagram beschreven.
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 |
|---|---|---|
| Niet van toepassing | Geen bevestigings- of invoerpopup in de normale processtroom. | Inline meldingen, lege staten of veilige redirects volstaan. |
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Doeldocument | Afleiding |
|---|---|
| Functioneel Ontwerp | Beschrijft welke beheeractie de beheerder kan uitvoeren, welke schermonderdelen zichtbaar zijn en welke grenzen gelden tussen beheerbare inhoud en codegedreven structuur. |
| Technisch Ontwerp | Technisch Ontwerp: domeinmodel en admin-eigenaarschap, databaseontwerp en frontendcompositie beschrijven de technische uitwerking. Beschrijf server-side autorisatie, readmodelopbouw, transacties, historyregistratie en het gebruik van ContentBlocks, ContentBlockHistory, Users. |
| Software Requirements Specificatie | Beschrijft requirements voor toegangscontrole, validaties, foutafhandeling, immutable history en afbakening van beheerbare velden. |
| Database-informatie | Beschrijft of velden, constraints, historytabellen en sleutelsets voor ContentBlocks, ContentBlockHistory volledig aansluiten op deze usecase. |
| Ontwerpbronnen en registers | Beschrijven autorisatiematrix, business rules, command-register, event-register en eventuele popupmatrix bij. |
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-FRONT-004-001 | SRS-ADM-002 SRS-ADM-001 SRS-CNT-001 AC-ADM-002 AC-ADM-001 AC-CNT-001 | De actie uitsluitend toestaan aan gebruikers met een actieve beheerderrol |
REQ-UC-BEH-FRONT-004-002 | SRS-AUTH-001 SRS-AUTH-002 SRS-ADM-002 SRS-ADM-001 SRS-CNT-001 AC-AUTH-001 AC-AUTH-002 AC-ADM-002 AC-ADM-001 AC-CNT-001 | Alle beheerautorisatie server-side controleren en mag niet vertrouwen op clientstate of routeparameters |
REQ-UC-BEH-FRONT-004-003 | SRS-AUTH-004 SRS-ACC-003 SRS-ACC-005 SRS-ADM-001 SRS-CNT-001 SRS-NFR-SEC-001 AC-AUTH-004 AC-ACC-003 AC-ACC-005 AC-ADM-001 AC-CNT-001 AC-NFR-SEC-001 | Onbekende, ontbrekende of niet-toegankelijke records veilig afhandelen zonder technische details te tonen |
REQ-UC-BEH-FRONT-004-004 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Read-only technische sleutels en codegedreven velden beschermen tegen wijziging via de GUI |
REQ-UC-BEH-FRONT-004-005 | SRS-RDM-001 SRS-ADM-001 SRS-CNT-001 AC-RDM-001 AC-ADM-001 AC-CNT-001 | Zoek-, filter- en selecteeracties behandelen als read-only acties zonder domeinmutatie |
REQ-UC-BEH-FRONT-004-006 | SRS-AUTH-001 SRS-ADM-001 SRS-CNT-001 AC-AUTH-001 AC-ADM-001 AC-CNT-001 | Wijzigingen pas opslaan nadat server-side validatie geslaagd is |
REQ-UC-BEH-FRONT-004-007 | SRS-ADM-001 SRS-CNT-001 SRS-NFR-AUD-001 AC-ADM-001 AC-CNT-001 AC-NFR-AUD-001 | Relevante wijzigingen auditbaar vastleggen met actor, UTC-tijdstip en oude en nieuwe waarde waar van toepassing |
REQ-UC-BEH-FRONT-004-008 | SRS-ADM-001 SRS-CNT-001 SRS-NFR-AUD-001 AC-ADM-001 AC-CNT-001 AC-NFR-AUD-001 | Historyrecords als immutable behandelen en niet via de beheerinterface wijzigbaar maken |
REQ-UC-BEH-FRONT-004-009 | SRS-ADM-001 SRS-CNT-001 SRS-NFR-SEC-001 AC-ADM-001 AC-CNT-001 AC-NFR-SEC-001 | Beheerbare tekst veilig opslaan en renderen zonder actieve of onveilige inhoud |
REQ-UC-BEH-FRONT-004-010 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Lege staten en blokkades gebruikersgericht en zonder technische details weergeven |
REQ-UC-BEH-FRONT-004-011 | SRS-ADM-002 SRS-ADM-001 SRS-CNT-001 AC-ADM-002 AC-ADM-001 AC-CNT-001 | Frontpagecontent per basiscontext beheren en geen persistent ontwerp per rolcombinatie aanmaken |
REQ-UC-BEH-FRONT-004-012 | SRS-AUTH-003 SRS-LRN-009 SRS-TCH-001 SRS-GUA-001 SRS-ADM-002 SRS-ADM-001 AC-AUTH-003 AC-LRN-009 AC-TCH-001 AC-GUA-001 AC-ADM-002 AC-ADM-001 | Gecombineerde rolfrontpages runtime samenstellen volgens de prioriteit Beheerder, Docent, Ouder/voogd |
REQ-UC-BEH-FRONT-004-013 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Frontpageblokstructuur, volgorde en layout codegedreven houden |
REQ-UC-BEH-FRONT-004-014 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | De usecase "Frontpagewijziging opslaan" uitvoeren volgens de afbakening van het subdomein Beheerder / Frontpagebeheer |