Meldingen en ticketafhandeling

14.1 Doel

Het meldingen- en ticketdomein ondersteunt het registreren, behandelen, opvolgen, oplossen, sluiten, heropenen en eventueel doorzetten van meldingen.

De gebruikersgerichte naam van dit domein is Meldingen.

Het meldingenproces is een zelfstandig domein binnen OefenHub. Het staat functioneel los van privéberichten, ook wanneer het domein gebruikmaakt van systeemberichten of in een specifieke beheerflow een privébericht namens een gebruiker laat aanmaken.

Het domein ondersteunt twee hoofdperspectieven:

• eindgebruikers die eigen meldingen indienen en opvolgen;
• beheerders die meldingen behandelen, intern bespreken, extern communiceren, oplossen, sluiten, heropenen of doorzetten naar een docent.

14.2 Domeinafbakening

Onderwerp	Afbakening
Meldingen / tickets	Worden vastgelegd in Tickets en vormen het hoofdrecord van het meldingenproces.
Technische snapshot	Wordt bij aanmaak vastgelegd in TicketTechnicalSnapshots en is alleen zichtbaar voor beheerders.
Beheerderkoppelingen	Worden vastgelegd in TicketAssignments en bepalen de actieve behandelcontext.
Discussie	Wordt vastgelegd in TicketDiscussionMessages met zichtbaarheid External of Internal.
Sluitingen en oplossingen	Worden formeel vastgelegd in TicketClosures, inclusief afsluitstatus en eventuele heropentermijn.
Afsluitstatussen	Worden vastgelegd via TicketResolutionTypes en beschrijven de inhoudelijke uitkomst van een sluitactie.
Heropenverzoeken	Worden vastgelegd in TicketReopenRequests en overschrijven eerdere sluitregistraties niet.
Doorzetten naar docent	Wordt vastgelegd via TicketForwardedToTeacher en gebruikt daarnaast het privéberichtendomein voor het bericht aan de docent.
Systeemberichten	Informeren de melder of andere betrokkenen en verwijzen via EntityType = Ticket naar de melding.
Privéberichten	Worden alleen geraakt bij expliciet ondersteunde flows zoals doorzetten naar docent.
Beheerhistory	Wordt compact vastgelegd in TicketHistory. Vrije toelichtingen horen in discussie, sluiting, oplossing of heropenverzoek.

14.3 Gebruikersscope

Iedere ingelogde gebruiker met reguliere applicatietoegang mag een melding indienen, tenzij de meldingenfunctionaliteit sitebreed is uitgeschakeld.

Een eindgebruiker ziet uitsluitend eigen meldingen. Een gebruiker mag geen melding van een andere gebruiker openen, ook niet via directe URL, gewijzigd ticketnummer, browsergeschiedenis of systeemberichtcontext.

Een eindgebruiker kan binnen de eigen melding:

• de melding bekijken;
• externe discussie lezen;
• reageren zolang de melding niet functioneel gesloten is;
• de eigen melding zelf sluiten zolang dit is toegestaan;
• een aangeboden oplossing accepteren;
• een melding heropenen binnen de heropentermijn;
• eerdere externe communicatie en oplossing teruglezen.

De eindgebruiker ziet niet:

• interne beheerdiscussie;
• technische snapshots;
• beheerdernaam bij externe beheerberichten;
• gekoppelde beheerders;
• volledige beheerhistory;
• interne audit- of foutdetails.

14.4 Beheerdersscope

Beheerders mogen alle meldingen zien en behandelen binnen de beheercontext.

Een beheerder kan onder meer:

• meldingenoverzicht openen;
• zoeken en filteren;
• meldingdetails openen;
• kerngegevens, technische metadata en geschiedenis bekijken;
• zichzelf of een andere beheerder koppelen;
• beheerders ontkoppelen met verplichte reden;
• intern discussiebericht plaatsen;
• extern bericht aan melder plaatsen;
• aanvullende informatie vragen;
• melding oplossen of sluiten;
• gesloten melding handmatig heropenen;
• melding doorzetten naar docent;
• audit- en historyinformatie raadplegen.

Binnen de rol Beheerder wordt binnen de initiële scope geen onderscheid gemaakt tussen subrollen of escalatieniveaus. Alle beheerders zijn functioneel gelijkwaardig, tenzij later expliciet beheerder-subrollen worden toegevoegd.

14.5 Gebruikersoverzicht Mijn meldingen

De pagina Meldingen toont voor eindgebruikers de eigen meldingen.

De gebruikersweergave gebruikt minimaal de tabbladen:

Tabblad	Inhoud
Open	Eigen meldingen die nog niet functioneel gesloten zijn en waar geen expliciete reactie van de gebruiker gevraagd wordt.
Wacht op mij	Eigen meldingen waarvoor actie van de gebruiker nodig is.
Gesloten	Eigen meldingen die formeel gesloten, geaccepteerd, zelf gesloten of gebruikersgericht opgelost/gesloten zijn.

Het tabblad Wacht op mij wordt afgeleid uit de combinatie:

• Tickets.CreatedByUserId is de ingelogde gebruiker;
• Tickets.Status is WaitingForUser.

Deze indicatie wordt niet als losse teller opgeslagen. Dezelfde afleiding voedt ook eventuele actie-indicatie bij profielmenu of navigatie.

Per melding worden minimaal getoond:

• meldingsnummer;
• onderwerp;
• categorie;
• gebruikersgerichte status;
• laatste activiteit;
• actie naar detailpagina.

Lege toestanden zijn normaal wanneer de gebruiker geen meldingen heeft binnen een tabblad.

14.6 Melding indienen

Een gebruiker kan een nieuwe melding maken met minimaal:

• categorie;
• onderwerp;
• beschrijving.

De beschikbare categorieën zijn vooraf gedefinieerde meldingscategorieën, zoals:

• Technisch probleem;
• Inhoudelijke fout;
• Wijziging aanvragen;
• Overig.

De gebruiker kiest geen prioriteit.

Bij aanmaken verzamelt OefenHub onder water technische context, zoals pagina, user agent, rolmomentopname en andere relevante metadata. Deze technische snapshot is bedoeld voor beheeranalyse en wordt niet aan de gebruiker getoond.

Bijlagen zijn binnen de initiële scope niet toegestaan, tenzij later expliciet als aparte requirement uitgewerkt.

Na succesvolle aanmaak:

• ontstaat een Tickets-record;
• wordt een technische snapshot vastgelegd;
• krijgt de melding status New;
• ontstaat een compacte historyregel;
• ontvangt de gebruiker een systeembericht met verwijzing naar de melding.

14.7 Melding details voor gebruiker

De detailpagina toont één melding binnen de eigen gebruikerscontext.

Minimaal aanwezig zijn:

• meldingsreferentie;
• titel / onderwerp;
• gebruikersgerichte status;
• laatst bijgewerkt;
• tabblad Melding;
• tabblad Oplossing;
• tabblad Discussie.

Wanneer reactie van de gebruiker nodig is, opent de detailpagina bij voorkeur direct op Discussie en toont het tabblad een actie-indicatie.

14.7.1 Tabblad Melding

Het tabblad Melding toont de oorspronkelijke melding zoals ingediend door de gebruiker:

• datum aangemaakt;
• categorie;
• onderwerp;
• omschrijving;
• actie Melding sluiten zolang dit functioneel toegestaan is.

Zelf sluiten vereist een verplichte reden. Deze reden wordt formeel verwerkt via TicketClosures en daarnaast als extern zichtbaar discussie-item vastgelegd, zodat de reden in de gebruikersdiscussie zichtbaar blijft.

14.7.2 Tabblad Oplossing

Het tabblad Oplossing toont de actuele oplossing of een informatieve leegstaat wanneer nog geen oplossing beschikbaar is.

Wanneer een oplossing beschikbaar is, toont dit tabblad minimaal:

• datum opgelost;
• afsluitstatus;
• meldingstatus;
• heropenbaar tot;
• oplossingstekst;
• actie Oplossing accepteren waar toegestaan;
• actie Heropen melding waar toegestaan.

Heropenen door de gebruiker is alleen beschikbaar wanneer er een actuele sluiting is met een geldige heropentermijn en de oplossing nog niet is geaccepteerd.

14.7.3 Tabblad Discussie

Het tabblad Discussie toont alle externe discussieberichten bij de melding.

Gebruikersreacties zijn altijd External. De gebruiker kan niet kiezen voor intern en kan niet aan een specifieke beheerder schrijven.

Externe beheerberichten worden aan de gebruiker getoond met generieke afzender Beheerder. De echte beheerder blijft technisch vastgelegd voor audit en beheerweergave.

Interne beheerberichten zijn nooit zichtbaar voor de melder.

14.8 Statusmodel

Het meldingenproces kent backendstatussen en gebruikersgerichte statussen.

Backendstatus	Gebruikersgerichte betekenis
New	Melding is aangemaakt en heeft nog geen actieve beheerderkoppeling.
InProgress	Melding is actief in behandeling of opnieuw behandelbaar.
WaitingForUser	Beheer wacht op reactie van de melder; gebruikersgericht Wachten op reactie of Wacht op mij.
Closed	Melding is formeel gesloten; gebruikersgericht kan dit Opgelost of Gesloten zijn.

Opgelost is geen aparte backendstatus en geen aparte databasewaarde. Het is een gebruikersgerichte afgeleide toestand.

Een melding wordt gebruikersgericht als Opgelost weergegeven wanneer:

• de backendstatus Closed is;
• de meest recente relevante sluitregistratie een heropentermijn heeft;
• de heropentermijn nog niet is verlopen;
• de oplossing nog niet door de gebruiker is geaccepteerd;
• de melding niet later opnieuw is heropend.

Een melding wordt gebruikersgericht als Gesloten weergegeven wanneer:

• de gebruiker de melding zelf sluit;
• de gebruiker de oplossing accepteert;
• de heropentermijn is verlopen;
• de melding formeel gesloten is zonder actieve heropenperiode;
• de actuele sluitcontext definitief is.

14.9 Afsluitstatus versus meldingstatus

Afsluitstatus en meldingstatus zijn verschillende concepten.

Begrip	Betekenis
Backendstatus	Procesfase van de melding, bijvoorbeeld New, InProgress, WaitingForUser, Closed.
Gebruikersstatus	Gebruikersgerichte afleiding, bijvoorbeeld Nieuw, In behandeling, Wachten op reactie, Opgelost of Gesloten.
Afsluitstatus	Inhoudelijke uitkomst van een sluitactie, bijvoorbeeld Technisch opgelost of Module configuratie.
Sluitregistratie	Formele registratie van een sluitactie in TicketClosures.

Afsluitstatussen worden beheerd als vaste lookupwaarden en zijn geen vrije gebruikersinvoer.

Voorbeelden van afsluitstatussen:

• Technisch opgelost;
• Workaround voorgesteld;
• Niet reproduceerbaar;
• Functioneel verwacht gedrag;
• Gesloten door gebruiker;
• Overige maar opgelost;
• Overige maar niet opgelost;
• Module configuratie.

Voor gebruikerssluitingen wordt het resolutietype ClosedByUser gebruikt.

14.10 Behandelcontext en beheerderkoppelingen

Een melding met status New heeft nog geen actieve beheerderkoppeling.

Externe beheercommunicatie, formeel oplossen, sluiten of doorzetten naar docent mag niet rechtstreeks vanuit New plaatsvinden. De beheerder moet de melding eerst in behandeling nemen via een actieve TicketAssignment.

Een melding mag meerdere actieve beheerderkoppelingen hebben.

Bij koppelen:

• wordt duplicatekoppeling voorkomen;
• ontstaat een actieve assignment;
• wordt status waar nodig InProgress;
• wordt history vastgelegd;
• kan systeemcommunicatie aan betrokken beheerder ontstaan.

Bij ontkoppelen:

• is een reden verplicht;
• wordt de assignment soft beëindigd;
• wordt auditinformatie vastgelegd;
• wordt history vastgelegd;
• kan een intern discussie-item of systeemcommunicatie ontstaan.

Wanneer door ontkoppeling geen actieve beheerderkoppeling meer bestaat, moet de status opnieuw consistent worden bepaald volgens de domeinregels.

14.11 Interne en externe discussie

Discussieberichten worden vastgelegd in TicketDiscussionMessages.

Zichtbaarheid	Betekenis
External	Zichtbaar voor melder en beheerders.
Internal	Alleen zichtbaar voor beheerders.

Gebruikersreacties zijn altijd External.

Externe beheerderberichten:

• zijn zichtbaar voor de melder;
• tonen richting melder generiek Beheerder;
• kunnen status WaitingForUser veroorzaken wanneer informatie wordt gevraagd;
• kunnen een systeembericht of actie-indicatie voor de melder veroorzaken.

Interne beheerderberichten:

• zijn alleen zichtbaar voor beheerders;
• veroorzaken geen systeembericht aan de melder;
• wijzigen niet automatisch de gebruikersgerichte status;
• zijn bedoeld voor interne analyse, overdracht of afstemming.

Discussie is inhoudelijke communicatie. History is compacte audit. Deze lagen mogen niet worden samengevoegd.

14.12 TicketHistory

TicketHistory is de compacte auditlaag rond een melding.

History bevat minimaal:

• tijdstip;
• actor of systeem;
• actietype;
• eventueel oude waarde;
• eventueel nieuwe waarde;
• actorweergave als snapshot waar nodig.

History bevat geen lange vrije toelichtingen. Vrije tekst hoort in:

• meldingomschrijving;
• discussie;
• oplossingstekst;
• sluitreden;
• heropenreden;
• doorzettoelichting.

De reguliere gebruiker ziet niet de volledige beheerhistory. Beheerders zien history in compacte vorm voor reconstructie en audit.

14.13 Sluiten en oplossen door beheerder

Een beheerder kan een melding oplossen of sluiten wanneer:

• de melding behandelbaar is;
• er een actieve beheerderkoppeling bestaat;
• verplichte velden zijn ingevuld;
• een geldige afsluitstatus is gekozen;
• de beheerder bevoegd is binnen beheercontext.

Bij oplossen of sluiten worden minimaal verwerkt:

• formele sluitregistratie in TicketClosures;
• afsluitstatus via TicketResolutionTypes;
• oplossingstekst of sluittoelichting;
• heropentermijn waar relevant;
• status Closed;
• historyregel;
• systeembericht aan de melder;
• gebruikersgerichte toestand Opgelost zolang de heropentermijn loopt.

Een ticket kan meerdere keren gesloten worden. Iedere sluitactie wordt als afzonderlijk TicketClosures-record vastgelegd. Eerdere sluitingen worden niet overschreven of verwijderd.

14.14 Eigen melding sluiten door gebruiker

Een gebruiker kan de eigen melding sluiten zolang de melding nog niet functioneel gesloten is en de actie volgens de statusregels beschikbaar is.

Zelf sluiten vereist een verplichte reden.

Bij zelf sluiten:

• wordt een TicketClosures-record aangemaakt;
• wordt resolutietype ClosedByUser gebruikt;
• wordt ClosedByUserId gevuld met de melder;
• wordt de reden als sluitinformatie vastgelegd;
• wordt de reden ook als extern discussie-item zichtbaar gemaakt;
• wordt een compacte historyregel vastgelegd;
• wordt de melding gebruikersgericht Gesloten.

Zelf sluiten maakt geen aparte tabel en creëert geen beheerderoplossing.

14.15 Oplossing accepteren

Wanneer beheer een oplossing heeft geplaatst, kan de gebruiker de oplossing accepteren.

Acceptatie:

• maakt geen nieuw TicketClosures-record aan;
• markeert de actuele sluitregistratie als geaccepteerd via AcceptedByUserId en AcceptedAtUtc;
• beëindigt of negeert de resterende heropentermijn functioneel;
• maakt de melding gebruikersgericht Gesloten;
• legt een TicketHistory-record vast;
• kan optioneel een extern discussie-item toevoegen.

Na acceptatie kan de gebruiker dezelfde sluiting niet meer via de gewone gebruikersflow heropenen.

14.16 Heropenen door gebruiker

Een gebruiker kan een opgeloste melding heropenen zolang:

• de melding van deze gebruiker is;
• de actuele sluiting heropenbaar is;
• de heropentermijn nog niet is verlopen;
• de oplossing nog niet is geaccepteerd;
• de melding niet intussen door beheer is heropend of opnieuw gesloten;
• een verplichte toelichting is ingevuld.

Heropenen door de gebruiker:

• registreert een TicketReopenRequests-record;
• gebruikt RequestSource = User;
• legt de verplichte toelichting vast;
• laat eerdere TicketClosures intact;
• voegt een extern zichtbaar discussie-item toe;
• legt een historyregel vast;
• maakt de melding opnieuw behandelbaar;
• ontkoppelt actieve beheerders niet automatisch.

Wanneer nog actieve beheerderkoppelingen bestaan, kan de melding opnieuw InProgress worden. Wanneer geen actieve beheerderkoppelingen bestaan, kan de melding terugvallen naar New volgens de domeinregels.

14.17 Handmatig heropenen door beheerder

Een beheerder kan een gesloten melding handmatig heropenen.

Deze actie:

• is niet afhankelijk van de gebruikersgerichte heropentermijn;
• vereist een bevestiging;
• vereist een verplichte interne reden;
• wordt formeel vastgelegd in TicketReopenRequests;
• gebruikt RequestSource = Admin;
• legt waar relevant PreviousClosureId vast;
• zet de melding terug naar New;
• ontkoppelt actieve beheerderkoppelingen;
• laat eerdere sluitingen, oplossingsteksten en afsluitstatussen historisch intact.

De heropenreden hoeft niet opnieuw als los fysiek discussiebericht te worden opgeslagen. In de beheerderdetailweergave mag de reden wel als intern tijdlijn- of discussie-item worden getoond op basis van TicketReopenRequests en history.

Bij handmatig heropenen door beheer worden minimaal twee aparte historyacties vastgelegd:

1. het heropenen van de melding;
2. het ontkoppelen of resetten van actieve beheerderkoppelingen.

14.18 Periodiek verwerken van verlopen heropentermijnen

Voor verlopen heropentermijnen wordt geen aparte schedulerjob per melding aangemaakt.

In plaats daarvan draait periodiek een TickerQ-verwerking. Functioneel uitgangspunt is minimaal iedere 12 uur.

Deze verwerking:

• selecteert tickets met backendstatus Closed;
• gebruikt alleen de actuele relevante sluitregistratie;
• selecteert alleen meldingen waarvan ReopenDeadlineUtc <= nowUtc;
• sluit meldingen uit die al geaccepteerd zijn;
• sluit meldingen uit die later zijn heropend;
• sluit meldingen uit waarvan de geselecteerde sluiting niet meer de actuele sluitcontext is;
• verwerkt idempotent;
• maakt geen nieuw TicketClosures-record aan;
• verstuurt geen extra systeembericht door alleen het verlopen van de termijn;
• legt waar nodig compacte history vast;
• logt technische fouten zonder de volledige jobrun te blokkeren.

Het gevolg is dat zulke meldingen niet langer gebruikersgericht als Opgelost worden behandeld, maar als Gesloten.

Deze periodieke verwerking is ook een vangnet voor gemiste scheduleruitvoeringen, race conditions of tijdelijke jobfouten. Zolang een melding aan de criteria voldoet, wordt zij bij een volgende run opnieuw gevonden.

14.19 Doorzetten naar docent

Wanneer beheer vaststelt dat de oorzaak van een melding voortkomt uit docentconfiguratie, kan de melding worden doorgezet naar een docent.

Dit is een expliciete beheerflow en geen gewone privéberichtactie.

Doorzetten naar docent vereist:

• actieve behandelcontext;
• geldige melding;
• geldige docentkeuze;
• functionele onderbouwing dat het om docentconfiguratie gaat;
• begeleidende toelichting;
• afsluitstatus Module configuratie.

De samengestelde transactie verwerkt minimaal:

• formele sluiting van de melding;
• resolutietype / afsluitstatus Module configuratie;
• registratie in TicketForwardedToTeacher;
• systeembericht aan de melder;
• privébericht namens de melder aan de gekozen docent;
• historyregel;
• behoud van ticketcontext en auditspoor.

De actie:

• maakt geen nieuwe docent-leerlingrelatie;
• kent geen niveauautorisatie toe;
• wijzigt geen oefenconfiguratie automatisch;
• maakt geen aparte ticketkopie voor de docent;
• blijft historisch zichtbaar binnen het ticketdomein.

Het namens-bericht aan de docent blijft een privébericht binnen het berichtendomein. De afwijkende afzenderweergave geldt alleen voor dat specifieke bericht.

14.20 Beheerdersoverzicht

Het beheerdersoverzicht ondersteunt minimaal:

• overzicht van meldingen;
• filters;
• zoekfunctie;
• selectie van een melding;
• compacte meldingpreview;
• statusweergave;
• beheerderdetailweergave;
• gekoppelde beheerders;
• interne en externe discussie;
• oplossen/sluiten;
• handmatig heropenen;
• doorzetten naar docent;
• geavanceerde metadata;
• geschiedenis.

Zoeken werkt binnen de actieve filter en ondersteunt minimaal:

• meldingsnummer;
• onderwerp;
• categorie;
• discussie-inhoud.

Zoeken in compacte history is geen onderdeel van de eerste functionele zoekscope. History blijft auditgericht en niet bedoeld als vrij doorzoekbaar communicatiedomein.

14.21 Technische snapshot en geavanceerde metadata

Bij het indienen van een melding legt OefenHub technische en contextuele informatie vast in een snapshot.

Deze snapshot kan onder meer bevatten:

• user agent;
• pagina-URL;
• IP-adres waar toegestaan;
• rolmomentopname;
• relevante contextwaarden;
• timestamp van aanmaak.

De snapshot is een momentopname en wordt niet achteraf live herberekend.

De reguliere gebruiker ziet deze technische context niet. Beheerders mogen deze context gebruiken voor analyse, debugging en support.

14.22 Retentie, snapshots en anonimisering

Het meldingen- en ticketdomein moet functioneel reconstrueerbaar blijven voor bevoegde beheerders zolang meldingen, audit of supportanalyse beschikbaar moeten zijn. Dit betekent niet dat actuele persoonsgegevens onbeperkt zichtbaar blijven.

Voor retentie en anonimisering gelden minimaal de volgende functionele regels:

Onderdeel	Functionele regel
Tickets	Het ticketrecord blijft bronhouder voor de melding, status, meldercontext en lifecycle. Verwijderen van een account verwijdert tickets niet blind.
Externe discussie	Blijft zichtbaar voor de melder zolang het account actief en geautoriseerd is. Na accountanonimisering vervalt reguliere gebruikersinteractie vanuit dat account.
Interne discussie	Blijft uitsluitend beheerinformatie en wordt niet zichtbaar voor de melder.
TicketHistory	Blijft compacte auditlaag en mag niet worden overschreven door anonimisering. Actorweergave kan wel geanonimiseerd of gemaskeerd worden.
TicketClosures en TicketReopenRequests	Blijven formele lifecyclebronnen. Eerdere sluitingen, heropeningen en acceptaties worden niet verwijderd omdat een account geanonimiseerd wordt.
TicketTechnicalSnapshots	Blijven momentopnamen voor beheeranalyse zolang dat volgens beleid en beheercontext is toegestaan. Zij worden niet live herberekend en mogen na anonimisering geen onnodige actuele persoonsgegevens reconstrueren.
TicketForwardedToTeacher	Blijft historisch bewijs van doorzetten naar docent. Namens-weergave wordt waar nodig geanonimiseerd.
Systeemberichten	Ticketgerelateerde systeemberichten blijven mailboxitems volgens de berichtregels. Het openen ervan verwerkt geen ticketactie automatisch.

Exacte bewaartermijnen voor technische snapshots, beheerlogs, securitylogs en backupgegevens horen in TO, SRS of beheerbeleid. Het FO legt vast dat retentie en cleanup de ticketautorisatie, privacygrenzen en historische reconstructie niet mogen doorbreken.

Bij anonimisering van de melder geldt dat open meldingen beheerbaar mogen blijven voor audit en analyse, maar reguliere vervolginteractie vanuit het verwijderde account niet meer mogelijk is. Beheer ziet dan een geanonimiseerde melderweergave waar actuele persoonsgegevens niet langer nodig of toegestaan zijn.

14.23 Systeemberichten vanuit meldingen

Het meldingenproces gebruikt systeemberichten voor gebruikersgerichte terugkoppeling.

Voorbeelden:

• melding aangemaakt;
• aanvullende informatie gevraagd;
• beheerder heeft extern gereageerd;
• oplossing geplaatst;
• melding opgelost;
• melding gesloten;
• melding doorgezet naar docent;
• relevante heropen- of statuswijziging.

Systeemberichten verwijzen naar de melding via:

• EntityType = Ticket;
• EntityId = TicketId.

Het openen van zo’n systeembericht opent hoogstens de relevante meldingcontext. Het bericht verwerkt geen onderliggende actie automatisch.

Een gebruiker accepteert dus geen oplossing, heropent geen melding en reageert niet op een melding door alleen het systeembericht te openen.

14.24 Lege toestanden en fouttoestanden

Lege toestanden zijn normaal wanneer de gebruiker of beheerder wel toegang heeft tot de betreffende context, maar er geen meldingen of resultaten zijn.

Voorbeelden:

• geen eigen meldingen;
• geen meldingen in tabblad Open;
• geen meldingen in tabblad Wacht op mij;
• geen meldingen in tabblad Gesloten;
• geen beheerdermeldingen binnen actieve filter;
• geen zoekresultaten.

Fouttoestanden ontstaan wanneer:

• de melding niet bestaat;
• de gebruiker geen eigenaar van de melding is;
• een beheerderactie zonder beheercontext wordt gestart;
• een melding intussen gesloten, heropend of gewijzigd is;
• verplichte velden ontbreken;
• een statusovergang niet is toegestaan;
• een heropentermijn is verlopen;
• de actuele sluitcontext niet meer overeenkomt;
• de gekozen docent ongeldig is;
• een technische verwerking faalt.

Bij fouttoestanden wordt geen interne beheerinformatie, technische snapshot, discussie-inhoud of persoonsgegevens buiten de toegestane context getoond.

14.25 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — meldingen en tickets	Meldingen, tickets en beheerafhandeling
Technisch Ontwerp — communicatie	Berichten, systeemberichten, notificaties en privéthreads
Technisch Ontwerp — background jobs	Background jobs, TickerQ en periodieke verwerking
Usecases — meldingen	Meldingen
UC-GEN-TIC-001 — Melding indienen	Melding indienen
UC-GEN-TIC-002 — Mijn meldingen bekijken	Mijn meldingen bekijken
UC-GEN-TIC-003 — Melding details bekijken	Melding details bekijken
UC-GEN-TIC-004 — Reageren op melding	Reageren op melding
UC-GEN-TIC-005 — Eigen melding sluiten	Eigen melding sluiten
UC-GEN-TIC-006 — Oplossing accepteren	Oplossing accepteren
UC-GEN-TIC-007 — Melding heropenen door gebruiker	Melding heropenen door gebruiker
UC-GEN-TIC-008 — Beheerdersoverzicht meldingen bekijken	Beheerdersoverzicht meldingen bekijken
UC-GEN-TIC-009 — Melding openen als beheerder	Melding openen als beheerder
UC-GEN-TIC-010 — Beheerder koppelen of ontkoppelen	Beheerder koppelen of ontkoppelen
UC-GEN-TIC-011 — Extern bericht plaatsen	Extern bericht plaatsen
UC-GEN-TIC-012 — Intern bericht plaatsen	Intern bericht plaatsen
UC-GEN-TIC-013 — Melding oplossen of sluiten	Melding oplossen of sluiten
UC-GEN-TIC-014 — Melding heropenen door beheerder	Melding heropenen door beheerder
UC-GEN-TIC-015 — Melding doorzetten naar docent	Melding doorzetten naar docent
UC-GEN-TIC-016 — Verlopen heropentermijnen periodiek verwerken	Verlopen heropentermijnen periodiek verwerken
Schermdocumentatie — meldingen	Meldingen
Schermdocumentatie — melding details	Melding details
Schermdocumentatie beheerder — meldingen overzicht	Meldingenoverzicht beheerder
Database-informatie — ticket- en meldingsbeheer	Ticket- en meldingsbeheer
Database-informatie — communicatie en notificaties	Communicatie en notificaties
Ontwerpbron — statusmodellen	Statusmodellen
Ontwerpbron — business rules	Business rules
Ontwerpbron — command-register	Command-register
Ontwerpbron — event-register	Event-register
Ontwerpbron — popup-register	Popup-register
FO — berichten, communicatie en notificaties	Berichten, communicatie en notificaties
FO — relatiebeheer	Relatiebeheer
FO — docentfunctionaliteit	Docentfunctionaliteit