9. Ticket- en meldingsbeheer

Deze pagina is de ERD-inzoomlaag voor het databasehoofdstuk ticket- en meldingsbeheer. De tabeldefinities in dat brondocument blijven leidend; deze pagina biedt een leesbare visuele ingang, zoompaden en compacte diagrammen.

9.1 Doel van deze inzoomlaag

Dit domein beschrijft het meldingen- en ticketsysteem achter de gebruikersgerichte pagina Meldingen. Het domein is functioneel rijker dan één compact ERD kan laten zien, omdat Tickets tegelijk actuele status, behandelcontext, discussie, formele sluitingen, heropeningen, technische momentopname, communicatie naar gebruikers en eventueel doorzetten naar docent raakt.

De belangrijkste ontwerpkeuzes zijn:

• Tickets bewaart de actuele hoofdtoestand van een melding.
• Lookup-tabellen zoals TicketStatuses, TicketCategories en TicketResolutionTypes begrenzen status, categorie en afsluitstatus.
• TicketAssignments bepaalt of er een actieve behandelcontext met één of meerdere beheerders bestaat.
• TicketDiscussionMessages is inhoudelijke communicatie binnen het ticket en is gescheiden van TicketHistory.
• TicketClosures is de formele bron voor oplossen, sluiten, heropentermijn en accepteren van een oplossing.
• TicketReopenRequests maakt heropenen herleidbaar zonder sluitrecords te overschrijven.
• TicketForwardedToTeacher legt de uitzonderlijke doorzetactie vast en kan via soft links verwijzen naar gegenereerde privéberichtrecords.
• TicketTechnicalSnapshots bewaart een momentopname van technische context en is geen live contextview.

9.2 Leesroute

Vraag	Start bij	Daarna kijken naar
Wat is de actuele toestand van een melding?	Tickets	TicketStatuses, CurrentResolutionTypeId, CurrentReopenDeadlineUtc en ClosedAtUtc.
Waarom ziet de gebruiker Opgelost of Gesloten?	TicketClosures	De meest recente relevante sluiting, ReopenDeadlineUtc, AcceptedByUserId en afgeleide UI-status.
Welke beheerder behandelt de melding?	TicketAssignments	Alleen actieve assignments vormen de behandelcontext; historische assignments blijven bewaard.
Waar staat de inhoudelijke communicatie?	TicketDiscussionMessages	Visibility = Internal of External bepaalt wie het bericht mag zien.
Waar staat de auditlaag?	TicketHistory	Compacte ActionType-regels, niet de volledige discussie of oplossingstekst.
Hoe werkt heropenen?	TicketReopenRequests	RequestSource, PreviousClosureId en ResultingStatusId.
Hoe werkt doorzetten naar docent?	TicketForwardedToTeacher	TicketClosures.ForwardedToTeacherId en gegenereerde privébericht-soft links.
Welke technische context had de melding bij aanmaak?	TicketTechnicalSnapshots	Snapshotvelden zoals UserAgent, PageUrl, IpAddress en UserRolesSnapshot.
Hoe wordt de gebruiker geïnformeerd?	SystemMessages in communicatie	EntityType = Ticket is een logische verwijzing, geen harde FK vanuit Tickets.

9.3 Kern-ERD binnen het ticketdomein

De ticketkern is opgesplitst in twee subdiagrammen. Het eerste diagram toont de actuele bron en waardelijsten. Het tweede diagram toont behandel-, communicatie-, audit- en snapshotrecords rond hetzelfde ticket.

9.3.1 Actuele ticketbron, waardelijsten en sluitbron

9.3.2 Behandeling, discussie, audit, doorzetten en snapshot

Interpretatie

• Eén Ticket heeft één actuele status via StatusId, maar kan meerdere historische sluitingen en heropeningen hebben.
• CurrentResolutionTypeId, CurrentReopenDeadlineUtc, ClosedAtUtc en ClosedByUserId op Tickets zijn actuele samenvattingsvelden; de formele sluitbron staat in TicketClosures.
• TicketTechnicalSnapshots is functioneel één-op-één met Tickets wanneer per ticket één primaire technische momentopname wordt vastgelegd.
• TicketForwardedToTeacher kan de oorzaak zijn van een formele sluiting met resolutietype ModuleConfiguration.
• TicketDiscussionMessages en TicketHistory blijven bewust gescheiden: discussie bevat inhoud, history bevat compacte audit.

9.4 Actor- en communicatiecontext

Vrijwel iedere mutatie in het ticketdomein heeft een actor. De actorverwijzingen zijn daarom verticaal gegroepeerd als soft links, zodat duidelijk blijft dat Users een identitybron is en geen harde database-eigenaar van ticketrecords.

Belangrijk onderscheid

Relatie	Betekenis
Tickets.CreatedByUserId	De melder. Deze gebruiker ziet de eigen melding en externe discussie zolang het account actief/toegankelijk is.
TicketAssignments.AdminUserId	Beheerder die actief of historisch aan de melding is gekoppeld.
TicketDiscussionMessages.CreatedByUserId	Actor van een discussiebericht. Null is toegestaan voor systeemgegenereerde berichten.
TicketHistory.ActorUserId	Actor van een compacte auditactie. Null is toegestaan voor volledig systeemgedreven acties.
TicketForwardedToTeacher.TeacherUserId	Docent die het gegenereerde privébericht ontvangt. Dit maakt geen docent-leerlingrelatie aan.
GeneratedPrivateMessageThreadId / GeneratedPrivateMessageId	Optionele soft links naar de reguliere privéberichtstructuur. Ticketdiscussie zelf wordt niet naar privéberichten gekopieerd en support legt geen harde database-FK naar communication.

9.5 Systeemberichtcontext

Ticketupdates kunnen een systeembericht naar de melder veroorzaken. Die relatie wordt niet als FK op Tickets opgeslagen. De communicatiebron is SystemMessages met EntityType = Ticket en EntityId = Tickets.Id.

Belangrijk hierbij:

• SystemMessages.RecipientUserId -> Users.Id is een soft link naar het identity-domein en geen harde database-FK.
• SystemMessages.EntityType = Ticket + EntityId is een beperkte logische verwijzing en geen harde database-FK naar Tickets.
• Het openen van een systeembericht voert geen ticketactie automatisch uit; ticketdetail, discussie, accepteren of heropenen controleren opnieuw autorisatie en actuele status.
• Interne beheercommunicatie veroorzaakt geen systeembericht naar de melder.

9.6 Ticket-lifecycle op hoofdlijnen

Afgeleide gebruikersstatus

Opgelost is geen backendstatus en geen record in TicketStatuses. De gebruikersgerichte status wordt afgeleid uit:

• backendstatus Closed;
• de actuele of meest recente relevante TicketClosures-registratie;
• ReopenDeadlineUtc;
• eventuele acceptatie via AcceptedByUserId en AcceptedAtUtc.

9.7 Sluiten, accepteren en periodiek verlopen

Belangrijke regel: het accepteren van een oplossing en het verlopen van de heropentermijn maken geen tweede sluitrecord aan. De bestaande sluiting blijft de formele bron.

9.8 Heropenen door gebruiker versus beheerder

Belangrijk verschil:

Flow	Ontkoppelt actieve beheerders?	Resulterende status	Reden zichtbaar voor melder?
Gebruiker heropent	Nee	InProgress of New, afhankelijk van actieve assignments	Kan als external discussie zichtbaar zijn.
Beheerder heropent	Ja	New	Interne reden; niet als gebruikersbericht tonen.

9.9 Doorzetten naar docent

Doorzetten naar docent is een samengestelde transactie en hoort daarom niet alleen in TicketHistory thuis.

Belangrijk hierbij:

• De doorzetactie maakt geen nieuwe docent-leerlingrelatie.
• De doorzetactie kent geen niveauautorisatie toe.
• De gegenereerde privéthread blijft onderdeel van het reguliere privéberichtdomein.
• De ticketdiscussie blijft in TicketDiscussionMessages; alleen het expliciet gegenereerde bericht aan de docent staat in PrivateMessages.
• De formele sluiting verwijst optioneel terug naar de doorzetactie via TicketClosures.ForwardedToTeacherId.

9.10 Discussie, history en snapshotlaag

Laag	Tabel	Soort informatie	Zichtbaarheid
Inhoudelijke discussie	TicketDiscussionMessages	Berichten, vragen, gebruikersreacties, systeemgegenereerde procesitems	External voor melder + beheer; Internal alleen beheer.
Compacte audit	TicketHistory	ActionType, actor, datum/tijd, compacte oude/nieuwe waarde	Primair beheer/audit; reguliere gebruiker ziet niet de volledige history.
Formele sluiting	TicketClosures	Oplossing, sluitreden, resolutietype, heropentermijn, acceptatie	Functioneel zichtbaar via oplossingstab; technisch bronrecord.
Heropenregistratie	TicketReopenRequests	Heropenbron, reden, vorige sluiting, resulterende status	Gebruikerreden kan extern zichtbaar zijn; beheerreden blijft intern.
Doorzetactie	TicketForwardedToTeacher	Docent, beheerder, toelichting, gegenereerde privéberichtverwijzingen	Beheergericht; melder krijgt gebruikersgerichte terugkoppeling.
Technische context	TicketTechnicalSnapshots	User agent, pagina, IP, rolmomentopname, laatst gezien	Alleen beheer/analyse; geen gebruikersgerichte actie-informatie.

9.11 Tabellen in dit domein

Tabel	Rol in het model	Brondata of afgeleid?	Belangrijkste verantwoordelijkheid
TicketStatuses	Lookup voor hoofdstatus	Brondata / vaste waardelijst	Begrenst backendstatussen zoals New, InProgress, WaitingForUser en Closed.
TicketResolutionTypes	Lookup voor afsluitstatus	Brondata / vaste waardelijst	Begrenst inhoudelijke afsluitstatussen zoals ClosedByUser of ModuleConfiguration.
TicketCategories	Lookup voor meldingscategorie	Brondata / vaste waardelijst	Classificeert meldingen zoals technisch probleem, inhoudelijke fout, wijzigingsverzoek of overig.
Tickets	Hoofdrecord van een melding	Brondata	Actuele toestand, melder, onderwerp, categorie, status, actuele sluitvelden en laatste activiteit.
TicketAssignments	Behandelcontext	Brondata / lifecycle	Actieve en historische koppeling tussen ticket en beheerder.
TicketDiscussionMessages	Inhoudelijke communicatie	Brondata	Interne en externe discussie rond een melding.
TicketHistory	Compacte auditlaag	Brondata / audit	Herleidbare actiehistorie zonder lange discussie- of oplossingstekst.
TicketClosures	Formele sluitregistratie	Brondata	Sluiten, oplossen, reactietermijn, accepteren en doorzetgerelateerde sluiting.
TicketReopenRequests	Heropenregistratie	Brondata	Heropenreden, herkomst, vorige closure en resulterende status.
TicketForwardedToTeacher	Doorzetregistratie	Brondata	Doorzetten naar docent met verwijzing naar gegenereerde privécommunicatie.
TicketTechnicalSnapshots	Technische momentopname	Snapshot-brondata	Context bij indienen van de melding, niet achteraf herberekend.

9.12 Relatie-inventaris binnen dit domein

Brontabel	Veld	Verwijst naar	Relatietype	Nullable	Betekenis
Tickets	CreatedByUserId	Users.Id	Soft link	N	Melder van het ticket.
Tickets	CategoryId	TicketCategories.Id	Harde FK	N	Gekozen meldingscategorie.
Tickets	StatusId	TicketStatuses.Id	Harde FK	N	Actuele backend-hoofdstatus.
Tickets	CurrentResolutionTypeId	TicketResolutionTypes.Id	Harde FK	J	Actuele of laatst relevante afsluitstatus.
Tickets	ClosedByUserId	Users.Id	Soft link	J	Actor van de meest recente sluitactie op de actuele toestand.
TicketAssignments	TicketId	Tickets.Id	Harde FK	N	Ticket waarvoor de beheerder gekoppeld is.
TicketAssignments	AdminUserId	Users.Id	Soft link	N	Gekoppelde beheerder.
TicketAssignments	AssignedByUserId	Users.Id	Soft link	N	Actor die de koppeling maakte.
TicketAssignments	UnassignedByUserId	Users.Id	Soft link	J	Actor die de koppeling beëindigde.
TicketDiscussionMessages	TicketId	Tickets.Id	Harde FK	N	Ticketdiscussiecontext.
TicketDiscussionMessages	CreatedByUserId	Users.Id	Soft link	J	Actor van het bericht; null voor systeemgegenereerde berichten.
TicketHistory	TicketId	Tickets.Id	Harde FK	N	Ticket waarop de auditregel betrekking heeft.
TicketHistory	ActorUserId	Users.Id	Soft link	J	Actor van de auditactie; null voor volledig systeemgedreven acties.
TicketClosures	TicketId	Tickets.Id	Harde FK	N	Ticket dat formeel gesloten/opgelost is.
TicketClosures	ClosedByUserId	Users.Id	Soft link	N	Actor van de sluitactie.
TicketClosures	ResolutionTypeId	TicketResolutionTypes.Id	Harde FK	N	Inhoudelijke afsluitstatus.
TicketClosures	ForwardedToTeacherId	TicketForwardedToTeacher.Id	Harde FK	J	Doorzetactie die bij deze sluiting hoort.
TicketClosures	AcceptedByUserId	Users.Id	Soft link	J	Melder die de oplossing accepteerde.
TicketReopenRequests	TicketId	Tickets.Id	Harde FK	N	Ticket dat wordt heropend.
TicketReopenRequests	RequestedByUserId	Users.Id	Soft link	N	Actor die heropent.
TicketReopenRequests	ResultingStatusId	TicketStatuses.Id	Harde FK	N	Status na heropenen.
TicketReopenRequests	PreviousClosureId	TicketClosures.Id	Harde FK	J	Sluiting waarop het heropenen betrekking heeft.
TicketForwardedToTeacher	TicketId	Tickets.Id	Harde FK	N	Ticket dat wordt doorgezet.
TicketForwardedToTeacher	TeacherUserId	Users.Id	Soft link	N	Ontvangende docent.
TicketForwardedToTeacher	ForwardedByAdminUserId	Users.Id	Soft link	N	Beheerder die doorzet.
TicketForwardedToTeacher	GeneratedPrivateMessageThreadId	PrivateMessageThreads.Id	Soft link	J	Gegenereerde privéthread in het communicatiedomein.
TicketForwardedToTeacher	GeneratedPrivateMessageId	PrivateMessages.Id	Soft link	J	Gegenereerd privébericht in het communicatiedomein.
TicketTechnicalSnapshots	TicketId	Tickets.Id	Harde FK	N	Eén primaire technische momentopname bij het ticket.

9.13 Belangrijkste relatiepatronen

1. Actuele status versus formele sluitbron

Tickets bevat actuele status- en sluitvelden voor snelle weergave. De formele bron voor sluiting, oplossing, heropentermijn en acceptatie staat in TicketClosures. Bij meerdere sluit-/heropenrondes blijven oude closures bestaan.

2. Behandelcontext via actieve assignments

Status New is alleen geldig zolang er geen actieve TicketAssignments bestaan. Externe beheercommunicatie, formeel oplossen/sluiten en doorzetten naar docent vereisen eerst een actieve behandelcontext.

3. Discussie is geen auditlog

TicketDiscussionMessages bevat inhoudelijke communicatie. TicketHistory bevat compacte auditregels. Vrije toelichtingen horen in discussie, oplossingstekst, sluitreden of heropenverzoek, niet in de historylaag.

4. Opgelost is afgeleid

Opgelost is geen statusrecord. Het is een gebruikersgerichte afleiding uit backendstatus Closed, de meest recente sluiting en de heropenbaarheid.

5. Doorzetten naar docent kruist twee domeinen

De ticketactie wordt vastgelegd in TicketForwardedToTeacher; de communicatie naar de docent loopt via reguliere PrivateMessageThreads en PrivateMessages. De verwijzingen naar die communicatie zijn soft links, zodat support geen harde database-FK naar het communicatiedomein krijgt.

6. Technische snapshot is geen live waarheid

TicketTechnicalSnapshots bewaart technische context op het moment van melden. Die gegevens worden niet opnieuw afgeleid wanneer de gebruiker, route, rollen of browsercontext later veranderen.

9.14 Afgedichte keuzes en onderhoud

Onderwerp	V1.0-keuze	Bron / vervolgcontrole
Ticketstatussen en resolutietypen	Geen apart ERD-waardelijstenhoofdstuk nodig. De lookupwaarden en betekenis staan in ticket- en meldingsbeheer.	Alleen uitbreiden wanneer nieuwe status- of resolutiewaarden worden toegevoegd.
TicketHistory.ActionType	De V1.0-codewaarden zijn in de database-informatie vastgelegd als gesloten domeinwaarden. Zij horen in database-informatie en code/migratie, niet als vrije SRS-waarden.	Nieuwe actiecodes vereisen code-/migratie-impactcontrole.
Periodieke TickerQ-verwerking	Geen apart ERD-sequencediagram nodig. De lifecycle in dit hoofdstuk en de schedulingbeschrijving in het Technisch Ontwerp zijn voldoende.	Alleen uitwerken wanneer de job meerdere onafhankelijke datadomeinen gaat muteren.
UI-termen versus databasewaarden	De mapping staat in de database-informatie. Opgelost blijft afgeleid en wordt niet opgeslagen als backendstatus.	Schermdocumentatie blijft leidend voor labels per schermcontext.
Ticketgerelateerde popupkeys/templates	Template- en popupkeys blijven configuratie/contentbeheer; tickets verwijzen functioneel terug via keygebruik en runtimecommunicatie.	Nieuwe keys volgen de seeddata- en placeholderregels uit configuratie/contentbeheer.

Deze punten zijn daarmee geen open ERD-blokkers meer. Zij blijven normale onderhoudscontroles bij wijzigingen aan ticketflows, templates of waardelijsten.

9.15 Status en vervolgvalidatie

Het ticketdomein is in eerste diepte uitgewerkt. De belangrijkste reviewlijn is nu of de formele bronnen voor status, sluiting, heropening, discussie en doorzetten naar docent consistent blijven met de implementatie.

Controleer bij latere wijzigingen expliciet:

• of Tickets.StatusId alleen de processtatus beschrijft en niet de afgeleide gebruikersstatus Opgelost;
• of TicketClosures de formele sluitbron blijft;
• of TicketDiscussionMessages niet wordt gebruikt als auditvervanger;
• of TicketForwardedToTeacher de enige plek blijft waar de doorzettransactie naar een docent wordt vastgelegd;
• of systeemcommunicatie naar tickets via het communicatiedomein blijft lopen en niet via losse database-URL's.