Beheerderfunctionaliteit

12.1 Doel

Beheerderfunctionaliteit ondersteunt centraal beheer van OefenHub.

Het beheerderhoofdstuk beschrijft de functionele samenhang tussen:

• beheerdercontext;
• beheerder-frontpage;
• Site Instellingen-hub;
• accountbeheer;
• rollenbeheer;
• frontpagebeheer;
• contentbeheer, vaste pagina’s en footer;
• popupbeheer;
• systeemberichttemplates;
• featuretoggles;
• systeemnotificaties;
• technische systeeminstellingen;
• centrale categorieën;
• technische oefenmodules;
• docentondersteuning;
• meldingenbeheer;
• beheerlogging en audit.

Beheerders hebben brede beheerrechten, maar beheerderrechten zijn geen vrije bypass op eindgebruikersfunctionaliteit.

Ook voor beheerders geldt:

• de actieve beheercontext wordt server-side bepaald;
• zichtbare menu-items zijn geen autorisatiebewijs;
• iedere detail-, mutatie-, support- en exportactie controleert opnieuw de actuele rechten;
• beheeracties blijven functioneel begrensd tot het betreffende beheerdomein;
• mutaties worden auditbaar vastgelegd;
• privacygevoelige inhoud wordt alleen getoond wanneer dat binnen het beheerdoel noodzakelijk en toegestaan is.

12.2 Domeinafbakening

Beheerderfunctionaliteit is geen enkel groot scherm en geen onbeperkte technische console.

Het domein bestaat uit meerdere beheergebieden met elk een eigen brondata, validatie, lifecycle en history.

Beheergebied	Primair doel	Bronhoudende laag
Beheerdercontext	Vaststellen of de gebruiker beheerfuncties mag gebruiken.	Rollen, sessiecontext en server-side autorisatie.
Beheerder-frontpage	Oriëntatie en samenvatting van beheerstatus.	Afgeleide readmodels en contentblokken.
Site Instellingen-hub	Route-ingang naar onderliggende sitebeheerpagina’s.	Codegedreven tegelset en beheerderautorisatie.
Accountbeheer	Accounts, rollen, status, instellingen en lifecycle beheren.	Users, Roles, UserRoles, UserSettings en accountlogs.
Frontpagebeheer	Tekstuele frontpagecontent beheren.	ContentBlocks met DomainType = FrontPage.
Handige links & pagina’s	URL-records, footercontent en vaste publieke pagina’s beheren.	SiteLinks, footerrecords en ContentBlocks.
Popupbeheer	Bestaande popupinhoud corrigeren.	Popupregister en PopupDetails.
Systeemberichttemplates	Template-inhoud voor toekomstige systeemcommunicatie beheren.	SystemMessageTemplates.
Features	Expliciet togglebare functies sitebreed schakelen.	SiteFeatureToggles.
Systeemnotificaties	Doelgroepgerichte overlays plannen en beheren.	SiteNotifications.
Technische instellingen	Bestaande beheerbare configuratiesleutels wijzigen.	SystemSettings.
Categorieën beheren	Centrale categorie-identiteit, status en migratie beheren.	Centrale categorieën, migraties en categoriehistorie.
Modules beheren	Technische oefenmodulemetadata en migraties beheren.	ExerciseModules en modulehistorie.
Docentondersteuning	Eén docentcontext supportmatig inspecteren en corrigeren.	Docentstructuur, niveauautorisaties, collaborators en history.
Meldingenbeheer	Meldingen behandelen, oplossen, heropenen of doorzetten.	Ticketdomein.
Beheerlogging	Beheeracties raadplegen en reconstrueren.	Domeinspecifieke history en beheerlogreadmodels.

Een beheeractie in één gebied mag niet impliciet brondata in een ander gebied wijzigen, tenzij die samengestelde actie expliciet als flow is uitgewerkt.

Voorbeelden:

• accountbeheer kent geen oefeningen toe;
• categoriebeheer wijzigt geen concrete moduleconfiguratiepayloads;
• modulebeheer herschrijft geen historische runs;
• frontpagebeheer wijzigt geen tellerdefinities;
• popupbeheer bepaalt niet wanneer een popup in een flow verschijnt;
• systeemberichtenbeheer wijzigt geen reeds verzonden systeemberichten;
• docentondersteuning maakt geen nieuwe relatievorming buiten de vastgelegde supportflows om.

12.3 Bronpositie

Dit FO-hoofdstuk beschrijft de functionele samenhang en grenzen van beheerderfunctionaliteit.

Bronlaag	Betekenis
FO	Beschrijft beheerdercontext, grenzen, samenhang en hoofdregels.
Usecases	Beschrijven per beheergebied de concrete flows, validatie, bevestiging en mutaties.
Schermdocumentatie	Beschrijft de zichtbare schermen, tabs, velden, acties, lege toestanden en foutfeedback.
Database-informatie	Beschrijft brondata, historytabellen, readmodels, lifecycle en persistente grenzen.
Ontwerpbronnen	Beschrijven business rules, autorisatiematrix, statusmodellen, command- en eventregister.
Mockups	Ondersteunen visuele interpretatie, maar zijn geen bron voor definitieve datawaarden of autorisatie.

Het FO dupliceert niet de volledige schermspecificatie en niet alle usecase-stappen.

Het FO legt vooral vast:

• welk beheergebied bronhoudend is;
• welke acties functioneel wel of niet horen bij beheerderfunctionaliteit;
• welke autorisatie- en privacygrenzen gelden;
• welke mutaties auditbaar zijn;
• welke historische data niet herschreven mag worden;
• hoe beheerderfunctionaliteit zich verhoudt tot andere FO-hoofdstukken.

12.4 Beheerdercontext

Toegang tot beheerderfunctionaliteit wordt uitsluitend server-side bepaald vanuit een actieve beheerdersrol.

Clientstate, routeparameters, browsergeschiedenis, bookmarks, zichtbare menu-items of verborgen knoppen mogen geen beheercontext afdwingen.

Voor beheerdercontext gelden minimaal de volgende regels:

Onderwerp	Regel
Actieve beheerrol	Een actieve roltoekenning met beheerderrol is vereist.
Accountstatus	Het account moet actief en regulier toegankelijk zijn.
Niet-publieke rol	De beheerderrol is niet-publiek en mag niet via zelfregistratie ontstaan.
Server-side controle	Iedere beheerroute, detailweergave en mutatie controleert opnieuw server-side.
Routebeveiliging	Directe URL’s naar beheerpagina’s zijn gelijk beveiligd aan navigatie via het menu.
Contextwisseling	Combinatierollen veranderen de beheercontext niet in een vrij eindgebruikersrecht.
Zichtbare UI	Menu’s, tegels en knoppen zijn presentatie en geen autorisatiebewijs.
Foutafhandeling	Bij ontbrekende beheercontext wordt geen beheerdata, technische sleutel of stacktrace getoond.

Een gebruiker met beheerderrol kan ook docent of ouder/voogd zijn.

In dat geval blijven de contexten functioneel gescheiden:

• beheerdercontext is bedoeld voor beheer- en supporttaken;
• docentcontext is bedoeld voor eigen docentfunctionaliteit;
• ouder-/voogdcontext is bedoeld voor eigen gekoppelde kinderen;
• beheerdercontext verleent geen live-meekijkrecht als beheerder;
• beheerdercontext laat een beheerder niet namens een leerling oefenen.

12.5 Geen beheerder-bypass op eindgebruikersfunctionaliteit

Beheerderfunctionaliteit is breed, maar niet onbeperkt.

Een beheerder mag geen eindgebruikersflow uitvoeren alsof hij de eindgebruiker is, tenzij er een expliciete supportflow bestaat.

Eindgebruikersdomein	Beheerdergrens
Leerling oefenen	Beheerder start, hervat, beantwoordt of rondt geen leerlingrun namens een leerling af.
Live meekijken	Beheerder kan geen live-meekijksessie starten op actieve leerlingruns.
Ouder-/voogdinzage	Beheerder krijgt geen ouder-/voogdcontext zonder actieve ouder-/voogdrelatie; beheerinzage verloopt via support- of auditcontext.
Docentresultaten	Beheerder kan beheer- of supportinformatie raadplegen waar uitgewerkt, maar reguliere docentresultaatinzage blijft docentcontext.
Privéberichten	Beheerder krijgt geen vrije impersonatie of generieke doorstuurfunctie.
Relatiebeheer	Beheerdercorrrecties maken niet stilzwijgend nieuwe relaties buiten vastgelegde flows.
Oefeningconfiguratie	Centraal modulebeheer wijzigt geen concrete docentconfiguratie zonder expliciete migratie- of supportflow.
Profielbeheer	Beheerder wijzigt geen identity-providercredentials, wachtwoorden of externe sessies.

Beheerderondersteuning mag functioneel corrigeren waar dat is uitgewerkt, maar moet altijd auditbaar blijven.

12.6 Beheerdernavigatie

De beheerdernavigatie bevat minimaal:

• Site Instellingen;
• Content;
• Accounts beheren.

Het menu-item Site Instellingen groepeert configuratieve sitebeheerfuncties, zoals:

• Frontpage;
• Popups beheren;
• Systeemberichten;
• Handige links & pagina’s;
• Features;
• Technische instellingen;
• beheerlog waar dit als ingang is opgenomen.

Het menu-item Content groepeert inhouds- en supportgerichte beheerfuncties, zoals:

• Categorieën beheren;
• Modules beheren;
• Docent ondersteuning.

Het menu-item Accounts beheren opent accountbeheer.

Navigatiestructuur is presentatie.

De onderliggende beheerpagina blijft zelf verantwoordelijk voor:

• routeautorisatie;
• objectautorisatie;
• validatie;
• bevestiging;
• opslag;
• history;
• foutafhandeling.

12.7 Beheerder-frontpage

De beheerder-frontpage is een start- en oriëntatiepagina.

Zij bundelt beheersignalen en verwijst naar onderliggende beheergebieden, maar voert geen beheercommando’s rechtstreeks uit.

De beheerder-frontpage is read-only voor domeindata.

Blok	Betekenis
Introblok	Beheerdergerichte uitleg en oriëntatie.
Vandaag extra aandacht	Compacte signalen die beheer aandacht kunnen vragen.
Contentbeheer	Samenvatting van centrale content- en oefenstructuur.
Accounts & rollen	Samenvatting van actieve accounts, rollen en relevante status.
Recente beheerwijzigingen	Compacte read-only lijst van recente beheeracties.

De beheerder-frontpage mag tonen:

• aantal actieve modules;
• aantal modules in onderhoud;
• aantal actieve categorieën;
• aantal uit gefaseerde categorieën;
• aantal open of nieuwe meldingen;
• aantal actieve systeemnotificaties;
• aantal accounts per rol;
• recente beheerwijzigingen.

De frontpage mag niet:

• accounts wijzigen;
• rollen toekennen;
• modules migreren;
• categorieën migreren;
• meldingen oplossen;
• content opslaan;
• systeemnotificaties publiceren;
• beheerdercontext afdwingen vanuit clientstate.

Iedere klik naar een onderliggende beheerroute voert opnieuw server-side beheerdercontrole uit.

12.8 Tellers en samenvattingswaarden op de beheerder-frontpage

Tellers en samenvattingswaarden zijn afgeleide readmodelwaarden.

Per teller moet functioneel vastliggen:

Aspect	Vraag
Domeinobject	Welke objecten worden geteld?
Statusfilter	Welke statuswaarden tellen mee?
Activiteitsfilter	Tellen inactieve of soft-deleted records mee?
Tijdvenster	Geldt vandaag, recente periode of alle tijd?
Scope	Gaat het om centrale objecten, accounts of supportcontexten?
Distinct-logica	Wordt uniek geteld of tellen koppelingen mee?
Testdata	Tellen testmodules, TestDocentcontexten of testruns mee?
Autorisatie	Is de teller alleen opgebouwd uit beheerdata die de beheerder mag zien?

Tellers zijn geen workflowstatus en geen opslagbron.

Wanneer een teller niet veilig kan worden opgebouwd, toont het systeem een veilige fout- of niet-beschikbaarafhandeling zonder technische details.

12.9 Site Instellingen-hub

Site Instellingen is een hubpagina en geen totaalformulier.

De hub toont codegedreven tegels naar onderliggende beheergebieden.

Tegel	Doelgebied
Frontpage	Tekstuele frontpagecontent per basiscontext.
Popups beheren	Bestaande popuprecords en beheerbare popupvelden.
Systeemberichten	Bestaande systeemberichttemplates.
Handige links & pagina’s	URL-records, footercontent en vaste publieke pagina’s.
Features	Featuretoggles en systeemnotificaties.
Technische instellingen	Bestaande beheerbare systeeminstellingen.

De hub:

• toont alleen route-ingangen;
• voert geen beheercommand uit;
• bevat geen editorstate;
• slaat geen tegelvolgorde of persoonlijke beheerdervoorkeur op;
• maakt geen nieuwe beheerdomeinen aan;
• geeft geen mutatierecht door aan doelpagina’s.

Iedere doelpagina voert eigen autorisatie, validatie en history af.

12.10 Accountbeheer

Accountbeheer ondersteunt beheer van interne OefenHub-accounts.

Het blijft strikt gescheiden van de identity provider.

OefenHub-accountbeheer beheert:

• interne applicatieaccounts;
• profielgerelateerde accountstatus;
• roltoekenningen;
• publieke en niet-publieke rollen;
• ondersteunde gebruikersinstellingen;
• lifecycle-acties zoals tijdelijk uitschakelen, heractiveren en anonimiseren;
• accountgeschiedenis en lifecyclelog;
• informatieve online-/laatst-gezienstatus.

OefenHub-accountbeheer beheert niet:

• wachtwoorden;
• credentials;
• tokens;
• identity-provider-sessies;
• primaire e-mailverificatieflows;
• externe Keycloak- of identity-providerinterne statussen;
• eindgebruikersrelaties buiten de vastgelegde lifecycle-opruimregels;
• oefenresultaten als beheerbare inhoud.

12.11 Accountoverzicht

Het accountoverzicht is een server-side gefilterd beheerreadmodel.

Het overzicht ondersteunt minimaal:

• zoeken;
• filteren op rol;
• filteren op accountstatus;
• filteren op actief/inactief;
• tonen van displaynaam;
• tonen van e-mailadres waar toegestaan;
• tonen van rollen;
• tonen van laatst-gezieninformatie;
• openen van accountdetail.

Zoeken en filteren zijn read-only.

Een zoekresultaat is geen toestemming om het account te wijzigen.

Het openen van accountdetail voert opnieuw server-side autorisatie uit.

12.12 Accountdetail

De accountdetailweergave toont één account binnen beheercontext.

Minimaal zichtbaar zijn:

• basisaccountgegevens;
• actieve status;
• rollen;
• rolhistorie waar relevant;
• ondersteunde instellingen;
• accountafhankelijkheden;
• accountgeschiedenis;
• lifecycle-acties die op dat moment toegestaan zijn.

Accountdetail mag niet tonen:

• wachtwoorden;
• tokens;
• identity-provider secrets;
• ruwe authenticatiesessies;
• technische payloads die niet nodig zijn voor beheer;
• oefenantwoorden of resultaatinhoud zonder expliciet supportdoel.

12.13 Rollen beheren

Beheerders kunnen toegestane rollen beheren binnen de rolregels van OefenHub.

Roltype	Beheerregel
Publieke rollen	Kunnen waar toegestaan worden toegekend of ingetrokken via accountbeheer.
Niet-publieke rollen	Alleen via beheer, met server-side controle en auditbare reden.
Leerlingrol	Mag niet gecombineerd worden met Ouder/voogd, Docent, Beheerder of TestDocent.
Ouder/voogd, Docent, Beheerder	Mogen onderling gecombineerd worden volgens de contextregels.
TestDocent	Niet-publieke rol voor gecontroleerde testzichtbaarheid, geen normale leerlingrol.

Voor niet-publieke rollen geldt:

• zelfregistratie mag deze rollen nooit toekennen;
• profielwijziging mag deze rollen nooit activeren;
• toekenning vereist beheerderautorisatie;
• intrekking vereist beheerderautorisatie;
• waar vereist wordt een reden vastgelegd;
• laatste actieve beheerder mag niet per ongeluk worden buitengesloten.

12.14 Account tijdelijk uitschakelen en heractiveren

Tijdelijk uitschakelen maakt een account niet regulier bruikbaar binnen OefenHub.

Het wijzigt geen identity-providercredentials.

Bij uitschakelen gelden minimaal:

• Users.IsActive of de relevante interne accountstatus blokkeert reguliere toegang;
• actieve sessies worden functioneel niet langer vertrouwd;
• rollen en historie blijven bewaard;
• relatie- en resultaatgeschiedenis wordt niet verwijderd;
• de actie wordt auditbaar vastgelegd.

Heractiveren is alleen mogelijk wanneer het account niet geanonimiseerd of definitief verwijderd is volgens de accountlifecycle.

Bij heractiveren:

• wordt server-side opnieuw gecontroleerd of de actor bevoegd is;
• blijven historische rollen en relaties alleen actief wanneer de domeinregels dat toestaan;
• ontstaat geen nieuwe identity-providercredential;
• wordt de mutatie auditbaar vastgelegd.

12.15 Accountanonimisering door beheerder

Accountanonimisering is een definitieve interne OefenHub-lifecycleactie.

Het is niet hetzelfde als het verwijderen van het identity-provideraccount.

Bij anonimisering:

• wordt actuele reguliere toegang beëindigd;
• worden persoonsgegevens vervangen of gemaskeerd volgens de accountregels;
• rollen worden beëindigd of niet langer autoriserend gemaakt;
• actieve relaties worden administratief beëindigd;
• open uitnodigingen worden niet langer accepteerbaar;
• afhankelijke contexten worden volgens domeinregels opgeschoond;
• historische reconstructie blijft mogelijk zonder actuele persoonsgegevens te tonen.

Anonimisering mag niet:

• historische oefenruns hard verwijderen;
• historische audit onbruikbaar maken;
• berichten van andere deelnemers generiek verwijderen;
• tickets of meldinghistorie onreconstrueerbaar maken;
• identity-providercredentials rechtstreeks wijzigen.

Functionele gevolgen per domein:

Domein	Beheerregel bij anonimisering
Account	Actuele persoonsgegevens worden gemaskeerd of vervangen. Het account wordt niet opnieuw regulier activeerbaar.
Rollen	Actieve rollen worden beëindigd of niet langer autoriserend gemaakt. Niet-publieke rollen blijven historisch auditbaar.
Relaties	Actieve relaties en open uitnodigingen van of naar het account worden beëindigd of niet langer accepteerbaar.
Oefenruns	Historische runs blijven functioneel beschikbaar binnen toegestane geschiedenis-, resultaat- en auditcontexten, maar zonder actuele persoonsgegevens.
Gedeelde oefeningen	Shared records en ontvangersruns blijven historisch verklaarbaar. Delen wordt niet opnieuw mogelijk gemaakt door anonimisering.
Berichten	Andere deelnemers behouden hun eigen threadzichtbaarheid volgens berichtregels. De geanonimiseerde deelnemer krijgt geen mailboxtoegang.
Meldingen	Tickets en ticketgeschiedenis blijven beheerbaar voor bevoegde beheerders, met geanonimiseerde actorweergave waar nodig.
Audit	History- en beheerlogregels blijven reconstructief bruikbaar, maar tonen geen onnodige actuele persoonsgegevens.

Een beheerder mag retentie- of anonimiseringregels niet ad hoc per account aanpassen. Afwijkende bewaartermijnen, backupverwijdering, juridische grondslagen en technische cleanupmechanismen horen in beleid, TO of SRS, niet in een losse beheerhandeling.

12.16 Online-status bekijken

Online-status en laatst-gezieninformatie zijn informatief.

Zij zijn geen autorisatiebron.

Beheerders mogen online-/laatst-gezieninformatie raadplegen voor accountbeheer, maar krijgen hierdoor geen live-oefendata en geen live-meekijkrecht.

Gegeven	Regel
Laatst gezien	Afgeleide account- of sessie-informatie.
Online-indicatie	Readmodel of sessie-afgeleide waarde.
Autorisatie	Online-status verleent geen extra recht.
Live-oefening	Beheerder ziet hierdoor geen live vraag- of antwoorddata.
Mutatie	Raadplegen veroorzaakt geen account-, sessie- of rolmutatie.

12.17 Gebruikersinstellingen corrigeren

Een beheerder mag alleen expliciet ondersteunde gebruikersinstellingen corrigeren.

Voorbeelden kunnen zijn:

• presentatievoorkeuren;
• toegestane toegankelijkheidsinstellingen;
• verborgen waarschuwingvoorkeuren wanneer support dat vereist;
• andere in het instellingenmodel vrijgegeven velden.

Beheerdercorrecties aan instellingen mogen nooit:

• rollen wijzigen;
• relaties wijzigen;
• zichtbare gegevenssets verruimen;
• autorisaties wijzigen;
• credentials of wachtwoorden aanpassen;
• identity-providerdata aanpassen;
• oefenresultaten wijzigen.

Wijzigingen worden server-side gevalideerd op:

• bestaande instelling;
• toegestaan datatype;
• toegestane waarde;
• rolcontext waar relevant;
• auditvereisten;
• reden waar vereist.

12.18 Accountgeschiedenis en lifecyclelog

Accountgeschiedenis is een read-only auditweergave.

Zij kan onder meer tonen:

• accountaanmaak;
• roltoekenningen;
• rolintrekkingen;
• tijdelijke uitschakeling;
• heractivering;
• instellingcorrecties;
• anonimisering;
• relevante lifecycle-opruimacties.

Historyrecords worden niet aangepast of verwijderd via normale beheeracties.

De beheerder ziet compacte reconstructie-informatie, geen identity-providercredentials.

12.19 Frontpagebeheer

Frontpagebeheer beheert tekstuele frontpagecontent binnen vooraf bepaalde basiscontexten.

Ondersteunde basiscontexten zijn:

ContextType	Functionele context
Public	Niet-ingelogde publieke frontpage.
NoRole	Ingelogde gebruiker zonder actieve rolcontext.
Student	Leerlingfrontpage.
Guardian	Ouder-/voogdfrontpage.
Teacher	Docentfrontpage.
Admin	Beheerderfrontpage.

Beheerbare velden zijn tekstueel, zoals:

• titel;
• introductietekst;
• label;
• korte toelichting;
• knoptekst waar de bestaande codecontext dit ondersteunt.

Niet beheerbaar via frontpagebeheer zijn:

• layout;
• blokvolgorde;
• componenttype;
• tellerdefinities;
• autorisaties;
• rolcontexten;
• nieuwe technische blokkeys;
• persistente ontwerpen per rolcombinatie;
• systeemnotificaties;
• popups;
• footercontent.

Wijzigingen in frontpagebeheer volgen de generieke beheerhistorie. Minimaal moeten actor, tijdstip, gewijzigd veld en oude/nieuwe waarde herleidbaar zijn, voor zover het wijzigingstype deze waarden kent.

Gecombineerde frontpages worden runtime samengesteld uit basiscontexten.

Zij worden niet als aparte persistente frontpageconfiguraties beheerd.

12.20 Contentbeheer, handige links, vaste pagina’s en footer

De beheerpagina Handige links & pagina’s beheert tekstuele content en herbruikbare URL-records.

Binnen scope vallen:

• URL-records;
• URL-validatie;
• footerinhoud;
• footerlinktoewijzingen;
• vaste publieke pagina’s;
• wijzigingsgeschiedenis.

Vaste publieke pagina’s zijn minimaal:

• Over OefenHub;
• Privacybeleid;
• Contact.

Contentbeheer is geen pagebuilder.

Beheer mag niet:

• nieuwe pagina’s of routes via de GUI maken;
• layout of formulierlogica wijzigen;
• contactformulierverwerking aanpassen;
• navigatie-autorisaties wijzigen;
• systeemnotificaties nabootsen;
• popups of systeemberichten vervangen door contentblokken.

URL-records worden gevalideerd voordat opslag slaagt.

Verwijderen van een URL-record is alleen toegestaan wanneer het record niet actief gebruikt wordt in footerlinktoewijzingen en gebeurt logisch met behoud van historie.

12.21 Popupbeheer

Popupbeheer is bedoeld voor bestaande popupdefinities.

De beheerder kan alleen beheerbare velden aanpassen die door de bestaande popupdefinitie zijn vrijgegeven.

Beheerbaar zijn minimaal:

• titel;
• tekst;
• zichtbare knopteksten;
• inputlabel wanneer de variant dit ondersteunt;
• beheerbare toelichting wanneer functioneel ondersteund.

Read-only of codegedreven zijn minimaal:

• PopupKey;
• domeingebruik;
• variant;
• theme;
• knopacties;
• CustomRendererKey;
• technische routering;
• aantal invoervelden buiten de bestaande variant.

Popupbeheer mag niet:

• nieuwe popupdefinities aanmaken;
• popupdefinities verwijderen;
• popups willekeurig uitschakelen;
• popup-themes beheren;
• runtimebeslissingen over popupweergave wijzigen;
• popupteksten dupliceren in usecases.

Wijzigingen worden server-side gevalideerd en historisch vastgelegd.

12.22 Systeemberichttemplates

Systeemberichttemplates bepalen de inhoud van toekomstige systeemcommunicatie.

Zij zijn niet hetzelfde als concrete mailbox-systeemberichten.

Beheerbare velden zijn:

• domein waar ondersteund;
• type waar ondersteund;
• onderwerp;
• tekst;
• zichtbare knoptekst wanneer de achterliggende code een actieknop ondersteunt.

Read-only of codegedreven zijn:

• referentienaam;
• technische actiecode;
• entitytype-keuze;
• routering;
• placeholderdefinitie;
• verplichting dat een systeemflow communicatie aanmaakt;
• aangemaakte runtime-SystemMessages.

Templatewijzigingen gelden alleen voor toekomstige systeemcommunicatie.

Reeds aangemaakte systeemberichten worden niet met terugwerkende kracht aangepast.

12.23 Featuretoggles

Featuretoggles zijn sitebrede aan/uit-schakelaars voor functies die expliciet togglebaar zijn.

Minimaal functioneel relevante toggles zijn:

Feature	Functionele betekenis
Registratie toegestaan	Bepaalt of registratie beschikbaar is.
Inloggen toegestaan	Bepaalt of reguliere login beschikbaar is.
Vriendschappen toegestaan	Bepaalt of vriendschap en gerelateerde acties beschikbaar zijn.
Privéberichten toegestaan	Bepaalt of nieuwe privéberichten beschikbaar zijn.
Live meekijken toegestaan	Bepaalt of live meekijken gestart kan worden.
Oefeningen delen toegestaan	Bepaalt of delen van afgeronde oefeningen beschikbaar is.
Testoefeningen beschikbaar	Bepaalt of testfunctionaliteit voor bevoegde test-/docentcontexten beschikbaar is.
Meldingen beschikbaar	Bepaalt of nieuwe meldingen ingediend kunnen worden.
Toegankelijkheid beschikbaar	Bepaalt of toegankelijkheidsinstellingen functioneel toegepast en aangeboden worden.

Featuretoggles wijzigen beschikbaarheid van functies, maar herschrijven geen bestaande domeindata.

Voorbeelden:

• privéberichten uitzetten verwijdert geen bestaande threads;
• meldingen uitzetten verwijdert geen bestaande tickets;
• delen uitzetten verwijdert geen bestaande gedeelde oefeningen;
• live meekijken uitzetten verwijdert geen auditrecords;
• toegankelijkheid uitzetten verwijdert geen opgeslagen gebruikerswaarden.

12.24 Systeemnotificaties

Systeemnotificaties zijn beheerbare overlays die na frontpage- of contextload kunnen verschijnen.

Zij zijn geen:

• mailbox-systeemberichten;
• privéberichten;
• popupregister-popups;
• contentblokken;
• ticketdiscussieberichten;
• relatie-uitnodigingen.

Systeemnotificaties bevatten minimaal:

• doelgroep (AudienceType);
• notificatietype;
• titel;
• tekst;
• startmoment in UTC;
• optioneel eindmoment in UTC;
• displayregel;
• aanmaak- en wijzigingsinformatie.

Beheerderfunctionaliteit ondersteunt:

• overzicht van actieve en geplande notificaties;
• overzicht van recent verlopen notificaties;
• overzicht van alle verlopen notificaties;
• aanmaken;
• wijzigen;
• handmatig uitschakelen;
• history raadplegen.

Handmatig uitschakelen vult het eindmoment met het actuele UTC-moment.

Een notificatie met OncePerBrowser gebruikt browsergebaseerde onderdrukking en geen server-side seen-tabel.

Tijdens een actieve leerling-oefenrun worden systeemnotificatie-overlays niet boven de oefening getoond.

12.25 Technische systeeminstellingen

Technische systeeminstellingen zijn bestaande configuratiesleutels die expliciet beheerbaar zijn vrijgegeven.

Nieuwe systeeminstellingen ontstaan via code en migratie, niet via de GUI.

Een systeeminstelling heeft minimaal:

• sleutel;
• functionele groep;
• datatype;
• invoervorm;
• actuele waarde;
• validatieregels;
• wijzigingsmetadata.

Voor systeeminstellingen geldt:

Onderwerp	Regel
Bestaande sleutel	Alleen bestaande beheerbare sleutels kunnen worden gewijzigd.
Datatype	Het type bepaalt de toegestane invoer en validatie.
Invoervorm	De UI volgt de codegedreven invoervorm per sleutel.
Cache	Na wijziging wordt relevante configuratiecache ververst of ongeldig gemaakt.
Audit	Wijzigingen worden herleidbaar vastgelegd.
Geen vrije variabelen	De GUI is geen vrije key-value editor.

Booleaanse featurebeschikbaarheid hoort primair bij featuretoggles.

Systeeminstellingen zijn bedoeld voor waarden die niet simpelweg functie aan/uit betekenen.

12.26 Toegankelijkheidsfeature sitebreed

De toegankelijkheidsfeature heeft bijzondere impact omdat opgeslagen gebruikersinstellingen kunnen blijven bestaan terwijl toepassing sitebreed wordt uitgeschakeld.

Wanneer toegankelijkheid sitebreed wordt uitgeschakeld:

• opgeslagen gebruikerswaarden blijven bewaard;
• de functionaliteit wordt niet aangeboden of toegepast zolang de feature uit staat;
• browserwaarden blijven geen bron van waarheid;
• er worden geen persoonsgegevens in browserwaarden opgeslagen;
• herinschakelen kan bestaande gebruikerswaarden weer laten gelden volgens de profielregels.

Deze actie wijzigt geen individuele profielwaarden.

12.27 Categorieën beheren

Categoriebeheer richt zich op centrale categorie-identiteit.

Centrale categorieën bevatten gedeelde onderwijsidentiteit zoals:

• naam;
• icoon;
• kleur;
• status;
• aanmaak- en wijzigingsinformatie;
• history.

Categoriebeheer is geen docentniveau-editor.

De beheerder beheert:

• categorieoverzicht;
• categoriebeheer-detail;
• categoriegegevens;
• categoriestatus;
• migratie naar bestaande doelcategorie;
• categoriegeschiedenis.

De beheerder beheert hier niet:

• het aanmaken van oefeningen binnen een docentniveau;
• concrete oefeningconfiguraties;
• technische modules;
• leerlingtoegang tot niveaus;
• historische runresultaten;
• gedeelde-oefening-snapshots;
• resultaat-PDF’s.

12.28 Categoriestatus

Categoriestatus bepaalt of een centrale categorie regulier beschikbaar is voor nieuw gebruik.

Statuswijziging mag geen historische data onleesbaar maken.

Uitfaseren of verwijderen wordt geblokkeerd zolang de categorie actieve docentniveau- of oefenkoppelingen heeft wanneer de bronregels dat vereisen.

Een inactieve of uitgefaseerde categorie:

• blijft historisch herleidbaar;
• wordt niet regulier aangeboden voor nieuwe koppelingen;
• herschrijft geen bestaande afgeronde runs;
• mag geen leerlingtoegang blijven verruimen buiten actieve niveau-/oefencontext.

12.29 Categoriemigratie

Categoriemigratie is een expliciete beheeractie.

Zij migreert actieve koppelingen van een broncategorie naar een bestaande doelcategorie.

Voor categoriemigratie gelden minimaal:

Onderwerp	Regel
Broncategorie	De broncategorie wordt expliciet gekozen.
Doelcategorie	De doelcategorie bestaat al en is geschikt als doel.
Reden	Een reden is verplicht.
Impactanalyse	Conflicten en gebruiksimpact worden vóór uitvoering bepaald.
Duplicaatpreventie	Dubbele actieve niveaucategorie- of oefenkoppelingen mogen niet ontstaan.
Historische data	ExerciseRuns, gedeelde snapshots en resultaatcontexten worden niet herschreven.
Audit	Migratie legt bron, doel, actor, moment, reden en uitkomst vast.
Communicatie	Betrokken docenten kunnen via systeemcommunicatie geïnformeerd worden.

Categoriemigratie is geen hernoemactie en geen hard delete.

De broncategorie blijft historisch herleidbaar, maar wordt na succesvolle migratie niet regulier kiesbaar waar dat volgens de migratieregels geldt.

12.30 Modules beheren

Modulebeheer richt zich op technische oefenmodules uit ExerciseModules.

Een module is de administratieve koppeling naar technische oefenlogica.

Modulebeheer ondersteunt minimaal:

• moduleoverzicht;
• modulebeheer-detail;
• modulegegevens wijzigen;
• actiefstatus wijzigen;
• testzichtbaarheid wijzigen;
• moduleconnectiviteit testen;
• docentgerichte modulemigratie;
• globale modulemigratie;
• proefmigratie controleren;
• modulegeschiedenis bekijken.

Modulebeheer is geen editor voor concrete docent-oefeningconfiguraties.

Concrete oefeningen, oefeningnamen, iconen en modulespecifieke configuratiepayloads blijven bronhoudend in docentflows of docentondersteuning.

12.31 Modulegegevens en actiefstatus

Beheerbare modulemetadata kan onder meer bestaan uit:

• weergavenaam;
• beschrijving;
• beschikbaarheidsstatus;
• testzichtbaarheid;
• versie- of referentie-informatie waar beheerbaar;
• wijzigingsmetadata.

Read-only of codegedreven blijven:

• technische module-implementatie;
• modulecontract;
• modulecode;
• configuratie-DTO’s;
• antwoordcontrole;
• runtime-strategy;
• bestaande payloadinterpretatie.

Een module op inactief zetten wordt geblokkeerd wanneer actieve concrete oefeningen de module gebruiken, tenzij een expliciete migratie- of onderhoudsflow de impact afdekt.

12.32 Testzichtbaarheid

Testzichtbaarheid is bedoeld voor gecontroleerde toegang tot modules in testcontext.

Onderwerp	Regel
TestDocent	Niet-publieke rol die via beheer wordt toegekend.
Testzichtbaarheid	Module kan zichtbaar zijn voor testgebruik zonder reguliere beschikbaarheid te wijzigen.
Geen leerlingtoegang	Testzichtbaarheid maakt een module niet automatisch zichtbaar voor reguliere leerlingen.
Geen roltoekenning	Modulebeheer kent geen TestDocentrol toe; dat hoort bij accountbeheer.
Geen permanente leerlinggeschiedenis	Docenttestruns worden niet als reguliere leerlinggeschiedenis bewaard.

12.33 Moduleconnectiviteitstest

Een moduleconnectiviteitstest is een server-side healthcheck op de technische modulekoppeling.

De test:

• wijzigt geen modulemetadata;
• wijzigt geen concrete oefeningen;
• maakt geen leerlingrun aan;
• maakt geen docentresultaat aan;
• toont een beheerresultaat;
• kan technische fouten veilig loggen.

De uitkomst is support- en beheerinformatie, geen oefenresultaat.

12.34 Modulemigratie

Modulemigratie is een expliciete beheeractie.

Zij verplaatst toekomstig gebruik van actieve concrete oefeningen van een bronmodule naar een doelmodule binnen een bepaalde scope.

Ondersteunde scopes zijn:

Scope	Betekenis
Proefmigratie	Eén concrete oefening gecontroleerd testen.
Docentgericht	Actieve concrete oefeningen van één docentcontext migreren.
Globaal	Alle actieve concrete oefeningen die de bronmodule gebruiken migreren.

Voor modulemigratie gelden minimaal:

• bronmodule en doelmodule zijn expliciet;
• doelmodule is actief en geschikt;
• reden is verplicht;
• impact wordt vooraf bepaald;
• configuratiecompatibiliteit wordt server-side gevalideerd;
• migratie wordt transactioneel verwerkt;
• history wordt vastgelegd;
• betrokken docentcontexten blijven herleidbaar.

Modulemigratie herschrijft niet:

• historische runs;
• afgeronde resultaten;
• PDF-contexten;
• gedeelde-oefening-snapshots;
• bestaande ontvangersruns;
• oude payloads die historisch geïnterpreteerd moeten blijven.

12.35 Docentondersteuning

Docentondersteuning is supportgericht beheer rondom één geselecteerde docentcontext.

De beheerder gebruikt deze pagina om:

• docentstructuur te inspecteren;
• niveaus te bekijken;
• categoriegebruik binnen docentcontext te bekijken;
• concrete oefeningen te bekijken;
• configuratiepayloads voor supportanalyse te openen;
• leerlingtoegang supportmatig te corrigeren;
• collaborators te beheren;
• docent-docenttoegang in uitzonderingen te forceren;
• eigenaarschap over te dragen;
• docentcontextgeschiedenis te bekijken.

Docentondersteuning vervangt niet:

• reguliere docentflows;
• centraal categoriebeheer;
• centraal modulebeheer;
• accountbeheer;
• relatiebeheer;
• leerlingresultaatbeheer;
• live meekijken;
• oefeningen maken namens leerlingen.

12.36 Docentstructuur inspecteren

Docentstructuurinspectie toont de hiërarchie:

• docent;
• niveau;
• categorie;
• concrete oefening;
• modulekoppeling;
• relevante configuratie- of statusinformatie.

Deze inspectie is primair read-only.

Zij mag worden gebruikt voor supportanalyse, maar maakt geen vrije beheerstructuur waarbij de beheerder willekeurig alle domeinobjecten kan wijzigen.

12.37 Leerlingtoegang supportmatig corrigeren

Een beheerder kan binnen docentondersteuning leerlingtoegang tot een niveau supportmatig corrigeren wanneer de usecase dit toestaat.

Daarbij geldt:

• de docentcontext is expliciet geselecteerd;
• de leerling moet binnen geldige relatie- en toegangskaders vallen;
• de actie maakt geen nieuwe docent-leerlingrelatie aan;
• de actie kent geen ouder-/voogdrelatie toe;
• historische runs blijven bestaan;
• ingetrokken toegang verwijdert geen resultaten;
• mutatie wordt auditbaar vastgelegd.

12.38 Collaborators supportmatig beheren

Een beheerder kan collaborators op niveau-laag supportmatig beheren wanneer de flow dit toestaat.

Daarbij geldt:

• een collaborator is een docent met geldige docent-docentcontext of expliciet geforceerde supportcontext;
• collaboratorrechten gelden alleen binnen het betreffende niveau;
• collaboratorrechten geven geen leerling-, resultaat- of live-meekijktoegang;
• ontkoppelen van een collaborator is een soft-deactivatie;
• geschiedenis blijft herleidbaar;
• systeemberichten aan betrokken docenten kunnen ontstaan volgens communicatiebeleid.

12.39 Docent-docenttoegang forceren

Docent-docenttoegang forceren is een uitzonderlijke supportflow.

Deze flow mag alleen worden gebruikt wanneer supportmatig noodzakelijk en auditbaar verantwoord.

Zij:

• maakt of heractiveert een docent-docentcontext voor support;
• vereist beheerderautorisatie;
• vereist reden;
• creëert geen leerlingtoegang;
• creëert geen resultaatinzage;
• creëert geen live-meekijkrecht;
• wordt auditbaar vastgelegd.

12.40 Eigenaarschap overdragen als beheerder

Een beheerder kan niveau-eigenaarschap overdragen binnen de daarvoor uitgewerkte supportflow.

Voor overdracht gelden minimaal:

• het niveau heeft precies één actuele eigenaar;
• de nieuwe eigenaar is een geldige kandidaat;
• de kandidaat is actief en docent;
• waar vereist is de kandidaat actieve collaborator;
• reden is verplicht;
• overdracht wordt transactioneel verwerkt;
• history wordt vastgelegd;
• betrokkenen kunnen systeemcommunicatie ontvangen.

Eigendomsoverdracht wijzigt geen historische resultaten en maakt geen leerlingruns opnieuw aan.

12.41 Meldingenbeheer binnen beheerderfunctionaliteit

Meldingenbeheer is inhoudelijk uitgewerkt in het meldingenhoofdstuk.

Binnen beheerderfunctionaliteit geldt dat beheerders meldingen kunnen:

• zoeken en filteren;
• openen;
• lezen;
• aan zichzelf of andere beheerders koppelen;
• intern bespreken;
• extern reageren;
• oplossen;
• sluiten;
• heropenen;
• doorzetten naar docent;
• technische snapshot en geschiedenis raadplegen.

Meldingenbeheer blijft gescheiden van:

• privéberichtendomein;
• generieke mailbox;
• accountbeheer;
• docentondersteuning, behalve bij de expliciete doorzetflow naar docent;
• contentbeheer.

Een melding doorzetten naar docent kan een privébericht namens de melder aanmaken, maar dit blijft een expliciet ondersteunde ticketflow en geen algemene impersonatie- of doorstuurfunctie.

12.42 Beheerlogging

Alle betekenisvolle beheerhandelingen moeten auditbaar zijn.

Minimaal vast te leggen zijn:

• actor;
• rolcontext;
• tijdstip in UTC;
• domein;
• actie;
• objecttype;
• objectreferentie;
• oude waarde waar relevant;
• nieuwe waarde waar relevant;
• reden waar vereist;
• technische correlatie waar nuttig en veilig.

Beheerlogging is niet één vrije teksttabel die alle history vervangt.

Veel domeinen hebben eigen historytabellen of logs.

Het beheerlog-overzicht kan een read-only aggregatie zijn over meerdere bronnen.

12.43 Beheerlog-overzicht

Het beheerlog-overzicht toont compacte beheerhistorie.

Het ondersteunt minimaal:

• filteren op domein;
• filteren op actor;
• filteren op periode;
• filteren op actietype;
• detail openen;
• masking van gevoelige waarden;
• read-only raadpleging.

Het beheerlog-overzicht wijzigt geen historyrecords en geen beheerde objecten.

12.44 Beheerlog-detail

Een beheerlogdetail toont één beheeractie veilig en contextueel.

Het detail kan bevatten:

• datum/tijd;
• actor;
• domein;
• object;
• actie;
• oude waarde;
• nieuwe waarde;
• reden;
• bronverwijzing naar het onderliggende historyrecord waar toegestaan.

Gevoelige waarden worden gemaskeerd of niet getoond wanneer volledige inhoud niet nodig of niet toegestaan is.

12.45 Audit per beheergebied

Beheergebied	Auditregel
Accountbeheer	Rol-, status-, instelling- en lifecyclewijzigingen worden vastgelegd.
Frontpagebeheer	Veldwijzigingen aan contentblokken worden historisch vastgelegd.
Links en pagina’s	URL-, footer- en paginawijzigingen worden auditbaar vastgelegd.
Popupbeheer	Popupveldwijzigingen worden per veld herleidbaar gemaakt.
Systeemberichttemplates	Templatewijzigingen worden voor toekomstige communicatie vastgelegd.
Features	Togglewijzigingen worden met oude/nieuwe waarde vastgelegd.
Systeemnotificaties	Inhoud, doelgroep, planning en displayregelwijzigingen worden vastgelegd.
Systeeminstellingen	Instellingwijzigingen en cacheverwerking worden herleidbaar gemaakt.
Categorieën	Gegevens-, status- en migratieacties worden vastgelegd.
Modules	Metadata-, status-, testzichtbaarheid- en migratieacties worden vastgelegd.
Docentondersteuning	Supportcorrecties, collaboratoracties en eigendomsoverdracht worden vastgelegd.
Meldingenbeheer	Ticketassignments, discussie, sluitingen, heropeningen en doorzetten worden vastgelegd in ticketbronnen.

12.46 Systeemcommunicatie vanuit beheerderflows

Beheerderflows kunnen systeemcommunicatie veroorzaken.

Voorbeelden:

• roltoekenning of rolintrekking waar communicatie gewenst is;
• accountlifecycle waar gebruikers geïnformeerd moeten worden;
• categorie- of modulemigratie naar betrokken docenten;
• niveauautorisatiecorrecties;
• collaboratorwijzigingen;
• eigendomsoverdracht;
• ticketupdates;
• doorzetten naar docent.

Systeemcommunicatie blijft bronhoudend in het communicatie- en template-domein.

Beheerderflows maken geen vrije berichtteksten buiten de template- en domeinregels om, tenzij de onderliggende usecase vrije toelichting ondersteunt.

Het lezen van een systeembericht verwerkt de onderliggende beheeractie niet opnieuw.

12.47 Popupfeedback vanuit beheerderflows

Beheerderflows gebruiken popupfeedback voor bevestigingen, validatiefouten, blokkades en succesmeldingen waar dit is vastgelegd.

Usecases en FO dupliceren geen popupteksten.

Zij verwijzen naar popupkeys of beschrijven functionele feedback op hoofdlijnen.

Autorisatie- en validatiefouten mogen geen gevoelige gegevens lekken, zoals:

• tokens;
• stacktraces;
• technische payloads;
• interne identifiers zonder functionele noodzaak;
• persoonsgegevens buiten toegestane context;
• oefenantwoorden of resultaatinhoud buiten supportdoel.

12.48 Feature- en instellingseffecten op beheerderfunctionaliteit

Featuretoggles en systeeminstellingen kunnen bepalen of bepaalde beheeracties beschikbaar zijn.

Voorbeelden:

• Registratie toegestaan beïnvloedt gebruikersregistratie maar verwijdert geen accounts.
• Vriendschappen toegestaan beïnvloedt nieuwe vriendschapsacties maar verwijdert geen bestaande relaties.
• Oefeningen delen toegestaan beïnvloedt nieuwe deelacties maar verwijdert geen shared records.
• Live meekijken toegestaan beïnvloedt live-startacties maar verwijdert geen LiveViewAudit.
• Meldingen beschikbaar beïnvloedt nieuwe meldingindiening maar verwijdert geen bestaande tickets.
• Toegankelijkheid beschikbaar beïnvloedt toepassing van toegankelijkheidsinstellingen maar verwijdert geen opgeslagen waarden.

Beheer moet bij iedere toggle duidelijk maken welke bestaande data wel en niet geraakt wordt.

12.49 Privacygrenzen

Beheerderfunctionaliteit kan gevoelige gegevens raken.

Daarom gelden privacygrenzen per domein.

Gegevenssoort	Beheerregel
Accountgegevens	Alleen tonen wat nodig is voor accountbeheer.
Credentials	Niet tonen of wijzigen binnen OefenHub.
Oefenresultaten	Alleen tonen binnen expliciet uitgewerkte resultaat-, support- of auditcontext.
Live voortgang	Niet toegankelijk voor beheerder als live meekijken.
Privéberichten	Niet generiek leesbaar via beheer, tenzij specifieke ticket- of auditflow dit toestaat.
Tickets	Beheerders mogen tickets behandelen volgens meldingenregels.
Technische snapshots	Alleen zichtbaar voor beheerders binnen meldingen/supportcontext.
History	Compact tonen en maskeren waar nodig.

Beheerderfunctionaliteit mag geen onnodige persoonsgegevens tonen alleen omdat de gebruiker beheerder is.

Voor retentie en anonimisering geldt aanvullend dat beheerweergaven actuele persoonsgegevens niet uit historische records mogen reconstrueren wanneer het account functioneel geanonimiseerd is. Historische reconstructie is toegestaan binnen de beheercontext, maar gebeurt met geanonimiseerde actor- of gebruikerweergave waar persoonsgegevens niet langer nodig of toegestaan zijn.

12.50 Autorisatie- en veiligheidsregels

Voor beheerderfunctionaliteit gelden overkoepelend:

• iedere beheerroute controleert server-side de actieve beheerdercontext;
• iedere mutatie controleert object-, veld- en commandautorisatie;
• directe URL’s geven geen extra toegang;
• clientstate bepaalt nooit welk object gewijzigd wordt;
• formulierwaarden worden server-side gevalideerd;
• concurrency wordt behandeld waar records gelijktijdig kunnen wijzigen;
• mutaties zijn waar nodig transactioneel;
• fouten tonen geen technische details aan gewone gebruikers;
• auditregels worden niet afhankelijk gemaakt van clientdata;
• beheerderacties mogen historische reconstructie niet breken.

12.51 Concurrency en race conditions

Beheerderacties kunnen botsen met andere beheerderacties of runtimeflows.

Daarom gelden minimaal:

Situatie	Regel
Account tegelijk gewijzigd	Opslaan controleert actuele status en relevante versie/context.
Rol intussen ingetrokken	Mutatie wordt opnieuw geautoriseerd op het moment van opslaan.
Categorie intussen gemigreerd	Migratie of statuswijziging herberekent impact vóór uitvoering.
Module intussen inactief	Modulemigratie of configuratieactie valideert actuele moduletoestand.
Ticket intussen gesloten	Ticketbeheeractie controleert actuele ticketstatus.
Content intussen gewijzigd	Contentopslaan controleert actuele waarde of versie waar nodig.
Systeemnotificatie intussen verlopen	Wijziging controleert planning en actuele einddatum.
Beheerdercontext vervallen	Actie wordt geblokkeerd en niet gedeeltelijk opgeslagen.

Bij conflicten moet de gebruiker veilige feedback krijgen en mag geen gedeeltelijke mutatie achterblijven.

12.52 Geen hard deletes als standaard

Beheerderfunctionaliteit gebruikt soft delete, deactiveren of historisch behoud als standaard wanneer data functioneel relevant kan blijven.

Hard delete is geen normale beheeractie voor:

• accounts;
• rollen;
• relaties;
• oefenruns;
• gedeelde oefeningen;
• tickets;
• contenthistory;
• categoriehistory;
• modulehistory;
• beheerlogs.

Wanneer technische opschoning later nodig is, hoort die in een apart technisch of retentieontwerp.

12.53 Lege toestanden

Lege toestanden zijn normaal wanneer een beheerder toegang heeft tot een beheerpagina maar er geen relevante data is.

Voorbeelden:

• geen accounts binnen filter;
• geen zoekresultaten;
• geen beheerderslogregels binnen periode;
• geen actieve systeemnotificaties;
• geen geplande systeemnotificaties;
• geen verlopen notificaties;
• geen URL-records;
• geen footerlinks in een context;
• geen popuphistory;
• geen templatehistory;
• geen categorieën binnen filter;
• geen modules binnen filter;
• geen docenten binnen docentondersteuning;
• geen supportrelevante geschiedenis;
• geen meldingen binnen beheerfilter.

Een lege toestand mag uitleg geven en naar een veilige vervolgstap verwijzen.

Een lege toestand mag geen verborgen autorisatie- of foutdetails lekken.

12.54 Fouttoestanden

Fouttoestanden ontstaan wanneer beheerdata niet veilig kan worden geraadpleegd of gewijzigd.

Voorbeelden:

• beheerdercontext ontbreekt;
• account is niet toegankelijk;
• account is intussen geanonimiseerd;
• rolcombinatie is ongeldig;
• laatste beheerder zou worden buitengesloten;
• instellingstype klopt niet;
• contentblokkey is onbekend;
• popupkey bestaat niet;
• template bevat onbekende placeholders;
• URL is ongeldig of onveilig;
• URL-record wordt nog gebruikt;
• categorie kan niet worden uitgefaseerd;
• categoriemigratie heeft conflicten;
• module kan niet worden gedeactiveerd;
• modulemigratie is incompatibel;
• docentcontext bestaat niet meer;
• leerlingtoegang is intussen gewijzigd;
• ticketstatus is intussen gewijzigd;
• history kan niet worden vastgelegd;
• cacheverversing faalt;
• technische verwerking faalt.

Bij fouttoestanden geldt:

• geen gedeeltelijke mutatie zonder consistente rollback of herstelstatus;
• geen stacktrace aan eindgebruikers;
• geen tokens of secrets in fouttekst;
• geen gevoelige payload in gewone feedback;
• technische logging bevat voldoende correlatie voor beheeranalyse.

12.55 Relatie tot andere FO-hoofdstukken

Hoofdstuk	Relatie
Rollen, context en autorisatie	Bepaalt actieve beheerdercontext, niet-publieke rollen en server-side autorisatie.
Applicatieschil, header, footer en navigatie	Bepaalt beheerdernavigatie, profielmenu, badges en footer rondom beheerpagina’s.
Frontpages en overzichtsschermen	Beschrijft beheerder-frontpage als read-only oriëntatiescherm.
Account, profiel en voorkeuren	Beschrijft profiel- en accountgrenzen buiten beheerderaccountbeheer.
Relatiebeheer	Bronhoudend voor relaties; beheerdercorrecties blijven supportgericht.
Oefencatalogus, niveaus, categorieën en oefeningen	Beschrijft centrale categorieën, niveaus en oefeningen waarop beheerderflows aansluiten.
Leerling: oefenen, voortgang en resultaten	Beschrijft run-lifecycle die beheer niet namens leerlingen uitvoert.
Gedeelde oefeningen	Beschrijft shared records die beheerderacties niet stilzwijgend herschrijven.
Docentfunctionaliteit	Bronhoudend voor reguliere docentflows; docentondersteuning is supportgericht.
Ouder-/voogdfunctionaliteit	Beschrijft read-only oudercontext; beheerdercontext vervangt die niet.
Berichten, communicatie en notificaties	Beschrijft systeemberichten, privéberichten, badges en systeemnotificaties.
Meldingen en ticketafhandeling	Beschrijft ticketbeheerflows voor beheerders.
Live meekijken	Beschrijft dat beheerder geen live-meekijkviewer is.
Contentbeheer, vaste pagina’s en footer	Detailhoofdstuk voor content, URL-records, vaste pagina’s en footer.
Popups, templates, features en systeemnotificaties	Detailhoofdstuk voor popupbeheer, templates, features en notificaties.
PDF-export en resultaatpresentatie	Beschrijft historische resultaatpresentatie; beheer herschrijft exportcontext niet.
Oefenmodules en modulepayloads	Beschrijft modulecontract, payloads en modulemigratiegrenzen.
Functionele architectuurcontext	Plaatst beheerfuncties in bredere functionele architectuur zonder technische implementatiedetails te dupliceren.

12.56 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — rolflows	Rollenflows technisch
Technisch Ontwerp — domeinmodel	Domeinmodel en datamodel-overzicht
Technisch Ontwerp — databaseontwerp	Databaseontwerp, migraties, seeddata en constraints
Technisch Ontwerp — beheer en operatie	Beheerbeleid, monitoring, backup, restore en operatie
Usecases — beheerder	Beheerder
Usecases — beheerder frontpage en context	Beheerder — frontpage en context
UC-BEH-FP-001 — Beheerder-frontpage bekijken	Beheerder-frontpage bekijken
UC-BEH-FP-002 — Beheercontext bepalen	Beheercontext bepalen
UC-BEH-FP-003 — Beheersamenvattingen tonen	Beheersamenvattingen tonen
UC-BEH-FP-004 — Recente beheerwijzigingen tonen	Recente beheerwijzigingen tonen
UC-BEH-FP-005 — Gecombineerde beheerder-docent-ouder-frontpage tonen	Gecombineerde beheerder-docent-ouder-frontpage tonen
Usecases — Site Instellingen-hub	Site Instellingen-hub
UC-BEH-SITE-001 — Site Instellingen-hub openen	Site Instellingen-hub openen
UC-BEH-SITE-002 — Beheertegel kiezen	Beheertegel kiezen
UC-BEH-SITE-003 — Toegang tot Site Instellingen controleren	Toegang tot Site Instellingen controleren
Usecases — accountbeheer	Accountbeheer
UC-BEH-ACC-001 — Accountoverzicht bekijken	Accountoverzicht bekijken
UC-BEH-ACC-002 — Accountdetail openen	Accountdetail openen
UC-BEH-ACC-003 — Accountrollen beheren	Accountrollen beheren
UC-BEH-ACC-004 — Niet-publieke rol toekennen of intrekken	Niet-publieke rol toekennen of intrekken
UC-BEH-ACC-005 — Account tijdelijk uitschakelen	Account tijdelijk uitschakelen
UC-BEH-ACC-006 — Account heractiveren	Account heractiveren
UC-BEH-ACC-007 — Account anonimiseren als beheerder	Account anonimiseren als beheerder
UC-BEH-ACC-008 — Account online-status bekijken	Account online-status bekijken
UC-BEH-ACC-009 — Gebruikersinstelling als beheerder wijzigen	Gebruikersinstelling als beheerder wijzigen
UC-BEH-ACC-010 — Accountgeschiedenis en lifecyclelog bekijken	Accountgeschiedenis en lifecyclelog bekijken
Usecases — frontpagebeheer	Frontpagebeheer
UC-BEH-FRONT-001 — Frontpagebeheer openen	Frontpagebeheer openen
UC-BEH-FRONT-002 — Frontpagecontext selecteren	Frontpagecontext selecteren
UC-BEH-FRONT-003 — Frontpage-contentblok bewerken	Frontpage-contentblok bewerken
UC-BEH-FRONT-004 — Frontpagewijziging opslaan	Frontpagewijziging opslaan
UC-BEH-FRONT-005 — Frontpagegeschiedenis bekijken	Frontpagegeschiedenis bekijken
UC-BEH-FRONT-006 — Runtime-samenstelling van gecombineerde frontpage controleren	Runtime-samenstelling van gecombineerde frontpage controleren
Usecases — handige links en vaste pagina’s	Handige links en vaste pagina’s
UC-BEH-LINKS-001 — Handige links en pagina’s openen	Handige links en pagina’s openen
UC-BEH-LINKS-002 — URL-record aanmaken of wijzigen	URL-record aanmaken of wijzigen
UC-BEH-LINKS-003 — URL-validatie uitvoeren	URL-validatie uitvoeren
UC-BEH-LINKS-004 — URL-record verwijderen	URL-record verwijderen
UC-BEH-LINKS-005 — Footertekst bewerken	Footertekst bewerken
UC-BEH-LINKS-006 — Footerlink-toewijzingen beheren	Footerlink-toewijzingen beheren
UC-BEH-LINKS-007 — Vaste publieke pagina bewerken	Vaste publieke pagina bewerken
UC-BEH-LINKS-008 — Wijzigingsgeschiedenis raadplegen	Wijzigingsgeschiedenis raadplegen
Usecases — popupbeheer	Popupbeheer
UC-BEH-POP-001 — Popupoverzicht bekijken	Popupoverzicht bekijken
UC-BEH-POP-002 — Popupdetail openen	Popupdetail openen
UC-BEH-POP-003 — Popupvelden wijzigen	Popupvelden wijzigen
UC-BEH-POP-004 — Popupwijziging valideren en opslaan	Popupwijziging valideren en opslaan
UC-BEH-POP-005 — Popupgeschiedenis bekijken	Popupgeschiedenis bekijken
UC-BEH-POP-006 — Custom-popup beperking toepassen	Custom-popup beperking toepassen
Usecases — systeemberichtenbeheer	Systeemberichtenbeheer
UC-BEH-SYSMSG-001 — Systeemberichttemplates overzicht bekijken	Systeemberichttemplates overzicht bekijken
UC-BEH-SYSMSG-002 — Systeemberichttemplate openen	Systeemberichttemplate openen
UC-BEH-SYSMSG-003 — Systeemberichttemplate wijzigen	Systeemberichttemplate wijzigen
UC-BEH-SYSMSG-004 — Templatevalidatie en placeholders controleren	Templatevalidatie en placeholders controleren
UC-BEH-SYSMSG-005 — Templategeschiedenis bekijken	Templategeschiedenis bekijken
Usecases — features en systeemnotificaties	Features en systeemnotificaties
UC-BEH-FEAT-001 — Features-overzicht bekijken	Features-overzicht bekijken
UC-BEH-FEAT-002 — Featuretoggle wijzigen	Featuretoggle wijzigen
UC-BEH-FEAT-003 — Systeemnotificaties-overzicht bekijken	Systeemnotificaties-overzicht bekijken
UC-BEH-FEAT-004 — Systeemnotificatie aanmaken	Systeemnotificatie aanmaken
UC-BEH-FEAT-005 — Systeemnotificatie wijzigen	Systeemnotificatie wijzigen
UC-BEH-FEAT-006 — Systeemnotificatie uitschakelen	Systeemnotificatie uitschakelen
UC-BEH-FEAT-007 — Verlopen systeemnotificaties raadplegen	Verlopen systeemnotificaties raadplegen
UC-BEH-FEAT-008 — Systeemnotificatie-weergaveregel toepassen	Systeemnotificatie-weergaveregel toepassen
Usecases — systeeminstellingen en beheerlogging	Systeeminstellingen en beheerlogging
UC-BEH-SET-001 — Systeeminstellingen-overzicht bekijken	Systeeminstellingen-overzicht bekijken
UC-BEH-SET-002 — Systeeminstelling wijzigen	Systeeminstelling wijzigen
UC-BEH-SET-003 — Configuratiecache verversen na wijziging	Configuratiecache verversen na wijziging
UC-BEH-SET-004 — Toegankelijkheidsfeature sitebreed schakelen	Toegankelijkheidsfeature sitebreed schakelen
UC-BEH-SET-005 — Instellingstype en invoervorm afdwingen	Instellingstype en invoervorm afdwingen
UC-BEH-SET-006 — Beheerlog-overzicht raadplegen	Beheerlog-overzicht raadplegen
UC-BEH-SET-007 — Beheerlog filteren en detail openen	Beheerlog filteren en detail openen
Usecases — categorieën beheren	Categorieën beheren
UC-BEH-CAT-001 — Categorieoverzicht bekijken	Categorieoverzicht bekijken
UC-BEH-CAT-002 — Categoriebeheer openen	Categoriebeheer openen
UC-BEH-CAT-003 — Categoriegegevens wijzigen	Categoriegegevens wijzigen
UC-BEH-CAT-004 — Categoriestatus wijzigen	Categoriestatus wijzigen
UC-BEH-CAT-005 — Categoriemigratie voorbereiden	Categoriemigratie voorbereiden
UC-BEH-CAT-006 — Categorie migreren	Categorie migreren
UC-BEH-CAT-007 — Categoriegeschiedenis bekijken	Categoriegeschiedenis bekijken
Usecases — modules beheren	Modules beheren
UC-BEH-MOD-001 — Moduleoverzicht bekijken	Moduleoverzicht bekijken
UC-BEH-MOD-002 — Modulebeheer openen	Modulebeheer openen
UC-BEH-MOD-003 — Modulegegevens wijzigen	Modulegegevens wijzigen
UC-BEH-MOD-004 — Module-actiefstatus wijzigen	Module-actiefstatus wijzigen
UC-BEH-MOD-005 — Testzichtbaarheid wijzigen	Testzichtbaarheid wijzigen
UC-BEH-MOD-006 — Moduleconnectiviteit testen	Moduleconnectiviteit testen
UC-BEH-MOD-007 — Modulemigratie docentgericht uitvoeren	Modulemigratie docentgericht uitvoeren
UC-BEH-MOD-008 — Modulemigratie globaal uitvoeren	Modulemigratie globaal uitvoeren
UC-BEH-MOD-009 — Modulemigratie-proefuitvoering controleren	Modulemigratie-proefuitvoering controleren
UC-BEH-MOD-010 — Modulegeschiedenis bekijken	Modulegeschiedenis bekijken
Usecases — docentondersteuning	Docentondersteuning
UC-BEH-DOCSUP-001 — Docentenoverzicht bekijken	Docentenoverzicht bekijken
UC-BEH-DOCSUP-002 — Docentondersteuning openen	Docentondersteuning openen
UC-BEH-DOCSUP-003 — Docentstructuur inspecteren	Docentstructuur inspecteren
UC-BEH-DOCSUP-004 — Niveau-detail binnen docentcontext bekijken	Niveau-detail binnen docentcontext bekijken
UC-BEH-DOCSUP-005 — Categorie-detail binnen docentcontext bekijken	Categorie-detail binnen docentcontext bekijken
UC-BEH-DOCSUP-006 — Oefening-detail binnen docentcontext bekijken	Oefening-detail binnen docentcontext bekijken
UC-BEH-DOCSUP-007 — Concrete oefeningconfiguratie openen	Concrete oefeningconfiguratie openen
UC-BEH-DOCSUP-008 — Leerling aan niveau toevoegen	Leerling aan niveau toevoegen
UC-BEH-DOCSUP-009 — Leerling van niveau ontkoppelen	Leerling van niveau ontkoppelen
UC-BEH-DOCSUP-010 — Collaborator aan niveau toevoegen	Collaborator aan niveau toevoegen
UC-BEH-DOCSUP-011 — Collaborator van niveau ontkoppelen	Collaborator van niveau ontkoppelen
UC-BEH-DOCSUP-012 — Docent-docenttoegang forceren	Docent-docenttoegang forceren
UC-BEH-DOCSUP-013 — Eigenaarschap overdragen als beheerder	Eigenaarschap overdragen als beheerder
UC-BEH-DOCSUP-014 — Docentcontextgeschiedenis bekijken	Docentcontextgeschiedenis bekijken
Schermdocumentatie — beheerder frontpage	Beheerder frontpage
Schermdocumentatie — meldingen overzicht	Meldingenoverzicht beheerder
Schermdocumentatie — accounts	Accounts
Schermdocumentatie — site instellingen	Site instellingen
Schermdocumentatie — frontpagebeheer	Site instellingen — frontpage
Schermdocumentatie — popups	Site instellingen — popups
Schermdocumentatie — systeemberichten	Site instellingen — systeemberichten
Schermdocumentatie — handige links en pagina’s	Handige links en pagina’s
Schermdocumentatie — features	Features
Schermdocumentatie — categorieën	Categorieën beheren
Schermdocumentatie — modules	Modules beheren
Schermdocumentatie — docentondersteuning	Docent ondersteuning
Database-informatie — identiteit en autorisatie	Identiteit en autorisatie
Database-informatie — docentstructuur en leerlingtoegang	Docentstructuur en leerlingtoegang
Database-informatie — communicatie en notificaties	Communicatie en notificaties
Database-informatie — configuratie en contentbeheer	Configuratie en contentbeheer
Database-informatie — ticket- en meldingsbeheer	Ticket- en meldingsbeheer
Database-informatie — oefenruns, delen en voortgang	Oefenruns, delen en voortgang
Database-informatie — audit, historie en technische uitgangspunten	Audit, historie en technische uitgangspunten
Ontwerpbron — autorisatiematrix	Autorisatiematrix
Ontwerpbron — business rules	Business rules
Ontwerpbron — command-register	Command-register
Ontwerpbron — event-register	Event-register
Ontwerpbron — statusmodellen	Statusmodellen
FO — rollen, context en autorisatie	Rollen, context en autorisatie
FO — frontpages en overzichtsschermen	Frontpages en overzichtsschermen
FO — contentbeheer, vaste pagina’s en footer	Contentbeheer, vaste pagina’s en footer
FO — popups, templates, features en systeemnotificaties	Popups, templates, features en systeemnotificaties
FO — oefenmodules en modulepayloads	Oefenmodules en modulepayloads