Popups, templates, features en systeemnotificaties

17.1 Doel

Dit hoofdstuk beschrijft de functionele grenzen rond beheerbare feedback, systeemcommunicatie en sitebrede schakelaars.

OefenHub maakt expliciet onderscheid tussen:

• popupdefinities;
• popupregisterregels;
• popup-themes;
• systeemberichttemplates;
• featuretoggles;
• systeemnotificaties;
• mailbox-systeemberichten;
• privéberichten;
• gewone contentblokken;
• technische systeeminstellingen.

Deze onderdelen kunnen in de gebruikersinterface op elkaar lijken, maar hebben verschillende brondata, lifecycle, beheerbaarheid en autorisatieregels.

17.2 Domeinafbakening

Onderdeel	Bron / hoofdmodel	Betekenis
Popupregister	Ontwerpbron / codegedreven sleutelset	Functionele bron voor popupkeys, teksten, knoppen, acties en context.
PopupDetails	Runtime-/databaseweergave van bestaande popupdefinities	Beheerbare popupinhoud voor bestaande codegedreven popups.
Popup-themes	Ontwerpbron / codegedreven themaset	Herbruikbare defaults voor type, stijl, knoppen, sluitgedrag en inputgedrag.
Systeemberichttemplates	SystemMessageTemplates	Beheerbare inhoud van verplichte systeemcommunicatie.
Featuretoggles	SiteFeatureToggles	Sitebrede schakelaars voor expliciet togglebare functies.
Systeeminstellingen	SystemSettings	Technische of functionele configuratiesleutels met datatype en invoervorm.
Systeemnotificaties	SiteNotifications	Planbare sitebrede of doelgroepgerichte notificatie-overlays na frontpageload.
Mailbox-systeemberichten	SystemMessages	Concrete gebruikergebonden systeemberichten in de mailbox.
Privéberichten	PrivateMessageThreads / PrivateMessages	Gebruiker-naar-gebruikercommunicatie binnen toegestane relatiecontext.
Contentblokken	ContentBlocks	Tekstuele inhoud voor frontpages, vaste pagina’s en footercontexten.

Een wijziging in het ene domein mag niet impliciet brondata in een ander domein wijzigen.

17.3 Popupregister en PopupDetails

Popupgedrag is codegedreven, maar popupinhoud kan voor bestaande popupdefinities beheerbaar zijn.

Het popupregister is de functionele bron voor:

• popupkey;
• domein;
• context;
• standaardtitel;
• standaardtekst;
• knopteksten;
• knopacties;
• inputdefinitie;
• themakeuze;
• functionele intentie.

PopupDetails is de runtime-/databaseweergave die via migratie of seed uit de brondefinitie kan worden gevuld en via beheer beperkt aangepast kan worden.

Voor normale dynamische popups geldt:

• popuprecords worden niet vrij in de GUI aangemaakt;
• popuprecords worden niet vrij in de GUI verwijderd;
• technische sleutels blijven stabiel en read-only;
• technische knopacties blijven read-only;
• custom renderer-verwijzingen blijven codegedreven;
• de popupregisterregel blijft inhoudelijk leidend;
• PopupDetails beheert alleen toegestane tekstuele of presentatievelden.

17.4 Beheerbare popupvelden

Beheerbare popupvelden zijn minimaal:

• titel;
• tekst;
• zichtbare knopteksten;
• inputlabel wanneer de popupvariant dat ondersteunt;
• beheerbare toelichting wanneer functioneel ondersteund.

Read-only of codegedreven zijn minimaal:

• technische sleutel;
• domeingebruik als codeverwijzing;
• variant;
• theme;
• technische knopacties;
• custom renderer;
• afwijkende layout;
• aantal invoervelden buiten de standaardvariant;
• route- of commandokoppelingen.

Een beheerder kan dus bestaande popupinhoud corrigeren, maar niet via de GUI een volledig nieuwe popupflow ontwerpen.

17.5 Actief/inactief van popups

Voor popupdefinities is er geen functionele GUI-schakelaar waarmee beheerders willekeurig popups aan- of uitzetten.

Technisch kan een popuprecord velden bevatten die beschikbaarheid of migratiestatus ondersteunen, maar functioneel geldt:

• popups blijven codegedreven referenties;
• aanmaken en verwijderen gebeurt via code en database-migraties;
• de applicatie bepaalt wanneer een popup wordt aangeroepen;
• de beheer-GUI biedt geen algemene “popup uitschakelen”-actie;
• verplichte fout-, bevestigings- of veiligheidsfeedback mag niet per ongeluk door beheer verdwijnen.

Wanneer een popupflow niet meer gebruikt moet worden, vraagt dit een bewuste code- of migratiewijziging en niet alleen een inhoudelijke beheeractie.

17.6 Popupvarianten

Functioneel ondersteunde popupvarianten zijn minimaal:

Variant	Betekenis
InfoOnly	Informatieve popup zonder keuze of invoer.
Confirm	Bevestigingspopup met één of meer keuzes.
InputText	Popup met één tekstveld.
InputEmail	Popup met één e-mailveld.
InputTextarea	Popup met één meerregelig tekstveld.
Custom	Codegedreven popup met afwijkende layout, meerdere velden of complex gedrag.

Niet-custom varianten ondersteunen maximaal één invoerveld. Meer dan één invoerveld vereist Variant = Custom en een CustomRendererKey.

Custom-popups worden alleen gebruikt wanneer de standaard dynamische popupstructuur onvoldoende is. Zij blijven functioneel traceerbaar via een sleutel, maar de exacte layout en validatie liggen in code.

17.7 Popup-themes

Popup-themes leveren herbruikbare defaults voor presentatie en gedrag.

Een theme kan onder meer bepalen:

• visueel type;
• buttonstijl;
• sluitgedrag;
• overlaygedrag;
• standaardknoprichting;
• standaardinputgedrag;
• waarschuwing- of fouttoon.

Themes voorkomen dat dezelfde stijl- en gedragskeuzes per popup opnieuw gedupliceerd worden.

De beheerder wijzigt bij normale popupbeheeracties geen themegedrag. ThemeKey en variant blijven technische of migratiegedreven keuzes.

17.8 Popupvalidatie en historie

Voor popupbeheer gelden minimaal de volgende validatiegrenzen:

Veld	Maximale lengte
Titel	50 tekens
Popuptekst	1000 tekens
Knoptekst	20 tekens

Wanneer een popupvariant invoer ondersteunt, worden inputtype, required-status en maximale invoerlengte bepaald door de popupdefinitie en applicatievalidatie.

Wijzigingen via de GUI leggen minimaal vast:

• popup;
• actor;
• tijdstip;
• wijzigingstype;
• gewijzigd veld;
• oude waarde;
• nieuwe waarde.

Een opslaan-actie kan meerdere veldwijzigingen bevatten, maar hoort als één logisch historymoment zichtbaar te blijven.

17.9 Systeemberichttemplates

Systeemberichttemplates bepalen de inhoud van verplichte systeemcommunicatie.

Zij zijn niet hetzelfde als concrete mailbox-systeemberichten.

Laag	Betekenis
Template	Beheerbare onderwerp- en tekstbasis voor een type systeemcommunicatie.
Concrete SystemMessage	Gebruikergebonden systeembericht dat vanuit een domeinflow wordt aangemaakt.

Systeemberichttemplates worden gebruikt door domeinflows zoals:

• relatie-uitnodigingen;
• acceptatie en afwijzing van uitnodigingen;
• ontkoppelingen;
• meldingen en ticketupdates;
• niveauautorisaties;
• collaboratorwijzigingen;
• gedeelde oefeningen;
• beheerterugkoppelingen.

Beheer wijzigt bestaande templates, maar maakt geen nieuwe technische referenties aan.

17.10 Beheerbare templatevelden

Beheerbare velden zijn minimaal:

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

Read-only of codegedreven zijn minimaal:

• referentienaam;
• technische actie;
• entitytype-keuze;
• routering;
• commandokoppeling;
• verplichte systeemcommunicatieflow;
• aanmaken of verwijderen van template-records.

Een beheerder mag een verplicht systeembericht dus niet verwijderen of functioneel uitschakelen door de template aan te passen.

17.11 Templatevalidatie en placeholders

Voor systeemberichttemplates gelden minimaal de volgende validatiegrenzen:

Veld	Maximale lengte
Onderwerp	50 tekens
Berichttekst	1000 tekens
Optionele knoptekst	20 tekens

Placeholdergebruik is codegedreven.

Alleen expliciet ondersteunde placeholders mogen worden gebruikt. Beheer mag geen willekeurige runtimevariabelen afdwingen.

Bij opslaan controleert het systeem minimaal:

• toegestane placeholders;
• ontbrekende of onbekende placeholders;
• onveilige inhoud;
• lengtebeperkingen;
• verplichte velden;
• ondersteunde knoptekst bij actieknop;
• dat technische acties read-only blijven.

Templatewijzigingen leggen minimaal actor, tijdstip, veldnaam, oude waarde en nieuwe waarde vast.

17.12 Featuretoggles

Featuretoggles zijn sitebrede schakelaars voor functies die expliciet aan of uit gezet mogen worden.

Een featuretoggle is niet bedoeld voor verplichte kernfunctionaliteit.

Minimaal functioneel te ondersteunen toggles zijn:

Feature	Functionele betekenis
Registratie toegestaan	Bepaalt of nieuwe registratie als applicatieflow beschikbaar is.
Inloggen toegestaan	Bepaalt of reguliere login functioneel beschikbaar is.
Vriendschappen toegestaan	Bepaalt of vriendschap en gerelateerde acties beschikbaar zijn.
Privéberichten toegestaan	Bepaalt of nieuwe privéberichtacties beschikbaar zijn.
Live meekijken toegestaan	Bepaalt of live meekijken gestart kan worden.
Oefeningen delen toegestaan	Bepaalt of leerlingen afgeronde oefeningen kunnen delen.
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:

• het uitschakelen van privéberichten verwijdert geen bestaande privéberichtthreads;
• het uitschakelen van meldingen verwijdert geen bestaande tickets;
• het uitschakelen van toegankelijkheid verwijdert geen opgeslagen toegankelijkheidswaarden;
• het uitschakelen van live meekijken verwijdert geen bestaande auditregels;
• het uitschakelen van delen verwijdert geen bestaande gedeelde oefeningen.

17.13 Featuretogglehistorie

Featuretogglewijzigingen zijn beheeracties en moeten herleidbaar zijn.

Minimaal vast te leggen zijn:

• featurekey;
• oude waarde;
• nieuwe waarde;
• actor;
• tijdstip;
• eventuele reden wanneer de beheerflow dit vereist.

Featurekeys volgen een centrale sleutelset. Afwijkende schrijfwijzen in oudere documentatie moeten naar de actuele sleutelset worden geconsolideerd.

17.14 Systeeminstellingen

Systeeminstellingen zijn configuratiesleutels met een datatype en invoervorm.

Zij verschillen van featuretoggles:

Featuretoggle	Systeeminstelling
Schakelt een functie aan of uit.	Bevat een configureerbare waarde.
Heeft meestal boolean-gedrag.	Kan boolean, integer, tekst, keuze of andere gecontroleerde waarde zijn.
Gaat over beschikbaarheid.	Gaat over functionele of technische configuratie.

Nieuwe systeeminstellingen ontstaan via code en migratie. De beheerder wijzigt alleen bestaande ondersteunde instellingen.

Systeeminstellingen mogen niet gebruikt worden als vrije opslagplaats voor ongedocumenteerde runtimevariabelen.

17.15 Systeemnotificaties

Systeemnotificaties zijn planbare en beheerbare notificatie-overlays die boven een reeds geladen frontpage of rolgerichte startpagina worden getoond.

Zij zijn nadrukkelijk geen:

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

Systeemnotificaties worden opgeslagen in SiteNotifications.

Minimale beheerbare gegevens zijn:

• doelgroep;
• notificatietype;
• titel;
• tekst;
• startdatum/-tijd;
• optionele einddatum/-tijd;
• weergaveregel;
• wijzigingsgeschiedenis.

Datums en tijden worden in UTC opgeslagen en in de gebruikersinterface naar lokale tijd vertaald.

17.16 AudienceType en ContextType

Systeemnotificaties gebruiken AudienceType.

Contentblokken en footercontext gebruiken ContextType.

Deze waarden zijn niet uitwisselbaar.

Begrip	Gebruik
AudienceType	Doelgroep van een systeemnotificatie, bijvoorbeeld Public, Authenticated, Teacher, Student, Guardian of Admin.
ContextType	Rendercontext voor contentblokken of footeropbouw, bijvoorbeeld Public, NoRole, Admin, Teacher, Student of Guardian.

NoRole is dus een content-/frontpagecontext voor ingelogde gebruikers zonder actieve rol. Authenticated is een doelgroep voor alle ingelogde gebruikers ongeacht rol.

Een systeemnotificatie mag doelgroepcontext niet afleiden uit een contentcontext alsof dit dezelfde laag is.

17.17 NotificationType

Systeemnotificaties ondersteunen minimaal:

Type	Betekenis
Info	Informatieve melding.
Warning	Waarschuwende melding met hogere attentiewaarde.

Deze types zijn code-enums of sleutelwaarden, geen vrij invoerbare beheerlabels.

17.18 DisplayRule

Systeemnotificaties ondersteunen minimaal twee weergaveregels.

DisplayRule	Betekenis
Always	Niet permanent als gezien registreren. Na sluiten niet direct opnieuw tonen binnen dezelfde notificatiereeks, maar bij later bezoek opnieuw mogelijk.
OncePerBrowser	Clientside onderdrukking op notificatie-id via browserwaarde. Geen server-side seen-tabel.

Bij OncePerBrowser onthoudt de browser dat de notificatie in die browser al is getoond of gesloten.

Deze browserwaarde:

• bevat geen persoonsgegevens;
• bevat geen autorisatiedata;
• bevat geen profielcontext;
• bevat geen identity-providerinformatie;
• is geen server-side bron van waarheid;
• bepaalt geen doelgroep of rechten.

Een wijziging aan een bestaande notificatie doorbreekt de browsermarker niet automatisch. Wanneer beheer gewijzigde of belangrijkere informatie opnieuw zichtbaar wil maken, moet een nieuwe notificatie worden gepubliceerd en de oude worden beëindigd.

17.19 Systeemnotificatiegedrag aan gebruikerszijde

Voor weergave aan gebruikers gelden de volgende regels:

• de frontpage of rolgerichte startpagina laadt eerst normaal;
• daarna controleert de applicatie of actieve systeemnotificaties getoond moeten worden;
• systeemnotificaties blokkeren het laden van de frontpage niet;
• er wordt maximaal één systeemnotificatie tegelijk getoond;
• bij meerdere relevante notificaties wordt de oudste aangemaakte notificatie eerst getoond;
• na sluiten controleert de applicatie direct of een volgende relevante notificatie beschikbaar is;
• notificaties met Always mogen binnen dezelfde notificatiereeks niet direct opnieuw verschijnen;
• notificaties met OncePerBrowser worden in dezelfde browser niet opnieuw getoond zolang de browsermarker bestaat.

Tijdens een actieve leerling-oefenrun worden systeemnotificatie-overlays niet boven de oefening geplaatst. De leerling mag door de webapp niet worden afgeleid tijdens het oefenen.

17.20 Systeemnotificatiebeheer

De beheerpagina voor systeemnotificaties ondersteunt minimaal:

• Actief & gepland;
• Afgelopen 31 dagen;
• Alle verlopen.

View	Betekenis
Actief & gepland	Notificaties die nu actief zijn of gepland staan.
Afgelopen 31 dagen	Recent verlopen notificaties die nog laagdrempelig te raadplegen of te hergebruiken zijn.
Alle verlopen	Complete verlopen historie, read-only.

Een handmatige uitschakelactie vult EndAtUtc met het actuele UTC-tijdstip.

Labels zoals actief, gepland, bijna verlopen en verlopen zijn afgeleide UI-statussen.

De persistente waarheid bestaat uit:

• inhoud;
• doelgroep;
• notificatietype;
• weergaveregel;
• startmoment;
• eindmoment;
• aanmaak- en wijzigingsinformatie.

Bijna verlopen betekent functioneel dat de ingestelde einddatum minder dan 24 uur in de toekomst ligt. Deze status wordt niet apart opgeslagen.

17.21 Systeemnotificatiehistorie

Wijzigingen aan systeemnotificaties moeten op veldniveau herleidbaar zijn.

Minimaal vast te leggen zijn:

• notificatie;
• gewijzigd veld;
• oude waarde;
• nieuwe waarde;
• actor;
• tijdstip.

Zowel inhoudswijzigingen als wijzigingen in planning, doelgroep, weergaveregel en handmatige uitschakeling worden auditbaar vastgelegd.

Historyrecords worden niet aangepast of verwijderd.

17.22 Relatie tot mailbox-systeemberichten

Systeemnotificaties en mailbox-systeemberichten hebben verschillende doelen.

Systeemnotificatie	Mailbox-systeembericht
Sitebrede of doelgroepgerichte overlay.	Gebruikergebonden mailboxitem.
Wordt na frontpageload getoond.	Staat in het berichtenoverzicht.
Heeft AudienceType.	Heeft ontvanger en eventueel EntityType + EntityId.
Geen gelezenstatus per gebruiker op server.	Heeft gelezen/ongelezenstatus.
Geen systeemmessage-template-instance.	Kan uit een systeemberichttemplate ontstaan.
Geen mailboxretentie.	Volgt mailbox- en systeemcommunicatieregels.

Een systeemnotificatie mag niet worden gebruikt als vervanging voor verplichte gebruikergerichte systeemcommunicatie, zoals een relatie-uitnodiging of ticketupdate.

17.23 Relatie tot popupfeedback

Systeemnotificaties en popups hebben ook verschillende doelen.

Systeemnotificatie	Popup
Wordt na frontpage- of contextload getoond.	Wordt getoond als reactie op een concrete actie, validatie of fout.
Wordt beheerd via SiteNotifications.	Wordt aangestuurd via popupregister en PopupDetails.
Heeft doelgroep, planning en displayrule.	Heeft popupkey, variant, theme, knoppen en eventueel input.
Is geen popupregister-popup.	Is geen systeemnotificatie.

Beheer mag deze mechanismen niet door elkaar gebruiken.

17.24 Relatie tot contentbeheer

Contentblokken, vaste pagina’s en footerbeheer horen bij het contentbeheerdomein.

Zij verschillen van popups, templates, features en notificaties:

• contentblokken vullen vaste pagina- en frontpageposities;
• popups geven actiegerichte feedback;
• templates leveren inhoud voor systeemcommunicatie;
• features schakelen functies;
• systeemnotificaties tonen tijdelijke overlays.

Het uniforme contentblokmodel is geen pagebuilder en hoort niet te worden gebruikt voor popup- of notificatiegedrag.

17.25 Lege toestanden en fouttoestanden

Lege toestanden zijn normaal wanneer er geen beheerbare items binnen een view zijn.

Voorbeelden:

• geen actieve systeemnotificaties;
• geen geplande systeemnotificaties;
• geen recent verlopen notificaties;
• geen zoekresultaten bij popupbeheer;
• geen zoekresultaten bij templatebeheer;
• geen featurewijzigingen in de history;
• geen popuphistory voor een nooit gewijzigde popup.

Fouttoestanden ontstaan wanneer:

• een popupkey niet bestaat;
• een popupvariant ongeldige velden bevat;
• een custom popup geen renderer heeft;
• een template onbekende placeholders bevat;
• een systeemberichttemplate verplichte tekst mist;
• een featurekey onbekend is;
• een systeemnotificatie ongeldige datums bevat;
• EndAtUtc vóór StartAtUtc ligt;
• een doelgroep of displayrule niet in de centrale sleutelset zit;
• een beheerder een read-only technische waarde probeert te wijzigen.

Bij fouttoestanden wordt geen technische payload, stacktrace, token of interne identifier aan gewone gebruikers getoond.

17.26 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — communicatie	Berichten, systeemberichten, notificaties en privéthreads
Technisch Ontwerp — readmodels en badges	Readmodels, tellers, badges, caching en materialisatie
Technisch Ontwerp — background jobs	Background jobs, TickerQ en periodieke verwerking
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
Schermdocumentatie — popups beheren	Popups beheren
Schermdocumentatie — systeemberichten	Systeemberichten
Schermdocumentatie — features	Features
Database-informatie — configuratie en contentbeheer	Configuratie en contentbeheer
Database-informatie — communicatie en notificaties	Communicatie en notificaties
Ontwerpbron — popup-register	Popup-register
Ontwerpbron — popup-themes	Popup-themes
FO — berichten, communicatie en notificaties	Berichten, communicatie en notificaties
FO — contentbeheer, vaste pagina’s en footer	Contentbeheer, vaste pagina’s en footer
FO — beheerderfunctionaliteit	Beheerderfunctionaliteit