6. Ticket- en meldingsbeheer

Deze sectie beschrijft het meldingen- en ticketsysteem achter de gebruikersgerichte pagina “Meldingen”, inclusief meldingstatus, afsluitstatus, gekoppelde beheerders, discussie, geschiedenis, technische context, heropenen en doorzetten naar docent.

6.1 TicketStatuses

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketStatuses	Lookup – Meldingen	Vaste tabel met toegestane hoofdstatussen voor meldingen/tickets.	Tickets, TicketReopenRequests

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van de status. GUID wordt in de applicatiecode gegenereerd; geen database-default.
Code	nvarchar(50)	-	N	N	-	J	N	J	Technische code, bijvoorbeeld New, InProgress, WaitingForUser, Closed.
Name	nvarchar(100)	-	N	N	-	J	N	N	Gebruikersvriendelijke naam van de status.
IsActive	bit	1	N	N	-	N	N	J	Lookup-waarde actief/inactief. Niet via GUI beheerbaar.

Validaties / constraints

• Code is uniek.
• Alleen vooraf gedefinieerde statussen zijn toegestaan.
• Wijzigen of toevoegen gebeurt uitsluitend via databasewijziging of migratie, niet via GUI.

Business rules

• Deze tabel bevat alleen de backend-hoofdstatus van een ticket: Nieuw, In behandeling, Wachten op gebruiker en Gesloten. Technische codewaarden blijven Engelstalig, bijvoorbeeld New, InProgress, WaitingForUser en Closed.
• Gebruikersgerichte labels mogen in de applicatie afwijken van de technische statusnaam. Zo kan WaitingForUser in de UI worden weergegeven als Wachten op reactie of binnen het overzicht als Wacht op mij.
• Opgelost is geen afzonderlijke database- of backendstatus. Dit is een gebruikersgerichte afgeleide toestand op basis van de meest recente sluitactie en de actuele heropen-deadline.
• Wanneer een ticket backendstatus Gesloten heeft en de meest recente relevante TicketClosure een ReopenDeadlineUtc in de toekomst heeft, wordt dit gebruikersgericht als Opgelost weergegeven.
• Wanneer een ticket backendstatus Gesloten heeft en de relevante ReopenDeadlineUtc is verlopen of niet meer als actieve heropenperiode geldt, wordt dit gebruikersgericht als Gesloten weergegeven.
• Nieuw is uitsluitend geldig wanneer er geen actieve beheerderkoppeling bestaat.

Lifecycle / gedrag

• Lookup-waarden worden niet hard verwijderd.
• Deactiveren heeft de voorkeur boven verwijderen wanneer historie behouden moet blijven.

Designkeuzes

• Statuswaarden worden bewust los van Tickets gehouden om referentiële integriteit en heldere statusovergangen te ondersteunen.

Gebruikersgerichte statusmapping

UI-label	Technische bron	Opslagregel
Nieuw	TicketStatuses.Code = New	Alleen geldig zonder actieve beheerderkoppeling.
In behandeling	TicketStatuses.Code = InProgress	Minimaal één actieve beheerderkoppeling of actieve behandelcontext.
Wachten op reactie / Wacht op mij	TicketStatuses.Code = WaitingForUser	Afgeleid voor de gebruiker die moet reageren; de exacte labelvariant is schermcontext.
Opgelost	TicketStatuses.Code = Closed + actuele TicketClosures.ReopenDeadlineUtc in de toekomst, zonder acceptatie	Niet opslaan als TicketStatuses-waarde.
Gesloten	TicketStatuses.Code = Closed zonder actieve heropenperiode of na acceptatie/zelfsluiting	Niet opslaan als aparte afgeleide status.

Foreign keys op databaseniveau

• Geen harde foreign keys op databaseniveau binnen deze tabel.

Functionele / logische verwijzingen zonder harde FK

• De velden Code functioneren als code-, enum- of sleutelwaarden en verwijzen bewust niet via een harde foreign key.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.2 TicketResolutionTypes

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketResolutionTypes	Lookup – Meldingen	Vaste tabel met afsluitstatussen die aangeven hoe een ticket inhoudelijk is afgerond.	Tickets, TicketClosures

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van het resolutietype. GUID wordt in de applicatiecode gegenereerd; geen database-default.
Code	nvarchar(50)	-	N	N	-	J	N	J	Technische code, bijvoorbeeld TechnicalFixed, ModuleConfiguration of ClosedByUser.
Name	nvarchar(100)	-	N	N	-	J	N	N	Gebruikersvriendelijke naam van de afsluitstatus.
IsActive	bit	1	N	N	-	N	N	J	Lookup-waarde actief/inactief. Niet via GUI beheerbaar.

Validaties / constraints

• Code is uniek.
• Alleen vooraf gedefinieerde resolutietypen zijn toegestaan.
• Beheer gebeurt niet via GUI maar via databasewijziging of migratie.

Business rules

• Resolutietypen staan los van de hoofdstatus.
• Een ticket kan alleen een resolutietype hebben wanneer het formeel is gesloten of vanuit een sluitactie wordt afgerond.
• Omdat TicketClosures.ResolutionTypeId verplicht is, moet ook een gebruikersactie waarbij de melder de melding zelf sluit of een oplossing accepteert een resolutietype krijgen.
• Voor gebruikerssluitingen wordt een vast resolutietype gebruikt, bijvoorbeeld Code = ClosedByUser met gebruikersvriendelijke naam Gesloten door gebruiker.
• ClosedByUser is bedoeld voor acties waarbij de melder zelf de melding sluit of de geboden oplossing accepteert; beheerderoplossingen gebruiken een inhoudelijk resolutietype dat de aard van de oplossing beschrijft.

Lifecycle / gedrag

• Lookup-waarden worden in principe niet verwijderd.
• Inactiveren is toegestaan wanneer een type niet langer gebruikt mag worden.

Designkeuzes

• Afzonderlijke resolutietabel voorkomt vermenging tussen processtatus en inhoudelijke uitkomst van een sluitactie.

Foreign keys op databaseniveau

• Geen harde foreign keys op databaseniveau binnen deze tabel.

Functionele / logische verwijzingen zonder harde FK

• De velden Code functioneren als code-, enum- of sleutelwaarden en verwijzen bewust niet via een harde foreign key.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.3 TicketCategories

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketCategories	Lookup – Meldingen	Vaste tabel met categorieën waaronder een gebruiker een melding kan indienen.	Tickets

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van de categorie. GUID wordt in de applicatiecode gegenereerd; geen database-default.
Code	nvarchar(50)	-	N	N	-	J	N	J	Technische code, bijvoorbeeld TechnicalIssue, ContentIssue, ChangeRequest, Other.
Name	nvarchar(100)	-	N	N	-	J	N	N	Gebruikersvriendelijke naam van de categorie.
IsActive	bit	1	N	N	-	N	N	J	Lookup-waarde actief/inactief. Niet via GUI beheerbaar.

Validaties / constraints

• Code is uniek.
• Alleen vooraf gedefinieerde categorieën zijn toegestaan.
• Beheer gebeurt via databasewijziging of migratie, niet via GUI.

Business rules

• Categorieën bepalen de functionele aard van de melding en zijn doorzoekbaar in het meldingenoverzicht.

Lifecycle / gedrag

• Lookup-waarden worden niet hard verwijderd wanneer ze historisch in bestaande meldingen worden gebruikt.

Designkeuzes

• Losse categorietabel maakt filtering en consistente rapportage mogelijk zonder vrije tekstvarianten.

Foreign keys op databaseniveau

• Geen harde foreign keys op databaseniveau binnen deze tabel.

Functionele / logische verwijzingen zonder harde FK

• De velden Code functioneren als code-, enum- of sleutelwaarden en verwijzen bewust niet via een harde foreign key.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.4 Tickets

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
Tickets	Meldingen	Hoofdtafel van het meldingen/ticketsysteem. Bevat de actuele toestand van een melding.	TicketCategories, TicketStatuses, TicketResolutionTypes, TicketAssignments, TicketDiscussionMessages, TicketHistory, TicketTechnicalSnapshots, TicketClosures

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van het ticket. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketNumber	nvarchar(30)	-	N	N	-	J	N	J	Mensleesbaar meldingsnummer voor zoeken en verwijzingen.
CreatedByUserId	uniqueidentifier	-	N	N	Users.Id	N	N	J	Soft link naar identity.Users.Id; gebruiker die de melding heeft aangemaakt. Geen harde database-FK vanwege modulegrens.
CreatedAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip waarop de melding is aangemaakt.
Subject	nvarchar(200)	-	N	N	-	N	N	J	Onderwerp van de melding. Doorzoekbaar.
Description	nvarchar(max)	-	N	N	-	N	N	N	Beschrijving van de melding.
CategoryId	uniqueidentifier	-	N	J	TicketCategories.Id	N	N	J	Categorie van de melding.
StatusId	uniqueidentifier	-	N	J	TicketStatuses.Id	N	N	J	Actuele hoofdstatus van het ticket.
CurrentResolutionTypeId	uniqueidentifier	-	N	J	TicketResolutionTypes.Id	N	J	J	Laatste of huidige afsluitstatus indien van toepassing.
CurrentReopenDeadlineUtc	datetime2	-	N	N	-	N	J	J	Actuele deadline tot wanneer de gebruiker de laatste sluiting mag heropenen.
ClosedAtUtc	datetime2	-	N	N	-	N	J	J	Tijdstip van de meest recente sluitactie zolang het ticket gesloten is.
ClosedByUserId	uniqueidentifier	-	N	N	Users.Id	N	J	J	Soft link naar identity.Users.Id; gebruiker die het ticket het meest recent formeel heeft gesloten. Geen harde database-FK vanwege modulegrens.
LastActivityAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Laatste functionele activiteit binnen het ticket, bijvoorbeeld nieuw bericht of statuswijziging.

Validaties / constraints

• TicketNumber is uniek.
• StatusId is verplicht.
• CurrentResolutionTypeId en sluitvelden mogen alleen gevuld zijn wanneer het ticket backendstatus Gesloten heeft of wanneer de actuele toestand rechtstreeks voortkomt uit de meest recente formele sluitactie.
• De gebruikersgerichte toestand Opgelost wordt niet via een aparte StatusId opgeslagen, maar afgeleid uit de sluitcontext en de actuele heropen-deadline.

Business rules

CurrentResolutionTypeId heeft alleen betekenis in of na een sluitcontext en wordt functioneel bepaald door de meest recente formele sluitactie van het ticket.

• Een ticket kent één backend-hoofdstatus en eventueel een actuele afsluitstatus.
• Voor gebruikers wordt het onderscheid tussen Opgelost en Gesloten afgeleid uit de meest recente sluitactie en CurrentReopenDeadlineUtc; dit onderscheid vereist geen extra statusrecord.
• Een ticket dat op WaitingForUser staat en door de huidige gebruiker is aangemaakt, telt als actie voor die gebruiker. Deze afleiding voedt onder meer de teller of actie-indicatie bij het profielmenu, het menu-item Meldingen en het tabblad Wacht op mij.
• Zoeken gebeurt binnen de actieve filter en ondersteunt meldingsnummer, onderwerp, categorie en discussie-inhoud, maar niet geschiedenis.
• Een ticket kan aan één of meerdere beheerders gekoppeld zijn.

Lifecycle / gedrag

• De hoofdtafel bewaart alleen de actuele toestand.
• Historische sluitingen, discussies, koppelingen en heropenacties worden in aparte tabellen geregistreerd.

Designkeuzes

• Actuele toestand op Tickets en historische detailregistratie in subtabellen voorkomt dubbele betekenis van één record en ondersteunt herhaald sluiten en heropenen.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: CategoryId -> TicketCategories.Id; StatusId -> TicketStatuses.Id; CurrentResolutionTypeId -> TicketResolutionTypes.Id.

Functionele / logische verwijzingen zonder harde FK

• CreatedByUserId en ClosedByUserId zijn soft links naar identity.Users.Id. Zij worden niet als harde database-FK afgedwongen, zodat het supportdomein historisch leesbaar blijft bij accountlifecycle- en anonimiseringsverwerking.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.5 TicketAssignments

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketAssignments	Meldingen	Koppelingen tussen een ticket en één of meerdere beheerders die eraan werken of gewerkt hebben.	Tickets, Users

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van de beheerderkoppeling. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketId	uniqueidentifier	-	N	J	Tickets.Id	N	N	J	Bijbehorend ticket.
AdminUserId	uniqueidentifier	-	N	N	Users.Id	N	N	J	Soft link naar identity.Users.Id; gekoppelde beheerder. Geen harde database-FK vanwege modulegrens.
AssignedAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip waarop de beheerder is gekoppeld.
AssignedByUserId	uniqueidentifier	-	N	N	Users.Id	N	N	J	Soft link naar identity.Users.Id; gebruiker die de koppeling heeft gelegd. Geen harde database-FK vanwege modulegrens.
UnassignedAtUtc	datetime2	-	N	N	-	N	J	J	Tijdstip waarop de beheerder is ontkoppeld.
UnassignedByUserId	uniqueidentifier	-	N	N	Users.Id	N	J	J	Soft link naar identity.Users.Id; gebruiker die de ontkoppeling heeft uitgevoerd. Geen harde database-FK vanwege modulegrens.
UnassignReason	nvarchar(max)	-	N	N	-	N	J	N	Optionele toelichting bij het ontkoppelen.
IsActive	bit	1	N	N	-	N	N	J	Geeft aan of de beheerder momenteel actief gekoppeld is.

Validaties / constraints

• Actieve combinatie TicketId + AdminUserId is uniek.
• Unassign-velden mogen alleen gevuld zijn wanneer IsActive = 0.

Business rules

Bij het beëindigen van een actieve tickettoewijzing is een reden verplicht. Deze reden wordt pas vastgelegd op het moment dat de toewijzing wordt ingetrokken of beëindigd en is niet van toepassing bij het initiële toewijzen van een beheerder aan een ticket.

• Een ticket kan aan één of meerdere beheerders gekoppeld zijn.
• Zolang er geen actieve koppeling is, is status Nieuw toegestaan.
• Koppelen of ontkoppelen genereert een discussie-item, een geschiedenisregel en een systeembericht aan de betrokken beheerder.

Lifecycle / gedrag

• Koppelingen worden niet hard verwijderd.
• Ontkoppeling wordt vastgelegd door IsActive = 0 plus auditinformatie.

Designkeuzes

• Aparte assignmentlaag voorkomt de onjuiste aanname dat een ticket altijd precies één eigenaar heeft en ondersteunt volledige lifecycle per beheerder.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: TicketId -> Tickets.Id.

Functionele / logische verwijzingen zonder harde FK

• AdminUserId, AssignedByUserId en UnassignedByUserId zijn soft links naar identity.Users.Id. De geldigheid van de beheerder- en actorcontext wordt applicatief gecontroleerd via Identity/Authorization-contracten.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.6 TicketDiscussionMessages

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketDiscussionMessages	Meldingen	Inhoudelijke discussie binnen een ticket, inclusief interne, externe en systeemgegenereerde berichten.	Tickets, Users

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van het discussiebericht. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketId	uniqueidentifier	-	N	J	Tickets.Id	N	N	J	Bijbehorend ticket.
MessageType	nvarchar(30)	-	N	N	-	N	N	J	Type bericht: UserMessage, AdminMessage of SystemMessage.
Visibility	nvarchar(20)	-	N	N	-	N	N	J	Zichtbaarheid van het bericht: Internal of External.
Body	nvarchar(max)	-	N	N	-	N	N	N	Inhoud van het bericht of systeemgegenereerde tekst.
CreatedAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip waarop het bericht is geplaatst.
CreatedByUserId	uniqueidentifier	-	N	N	Users.Id	N	J	J	Soft link naar identity.Users.Id; actor van het bericht. Null voor systeemgegenereerde berichten. Geen harde database-FK vanwege modulegrens.

Validaties / constraints

• MessageType en Visibility worden centraal gestandaardiseerd.
• CreatedByUserId mag null zijn wanneer MessageType = SystemMessage.

Business rules

Gebruikersreacties vanuit de meldingsdetailpagina zijn altijd External. Internal-berichten zijn uitsluitend bedoeld voor communicatie tussen beheerders onderling.

• Discussie is inhoudelijke communicatie en staat los van geschiedenis.
• Interne berichten zijn alleen zichtbaar voor beheerders en kunnen systeemberichten of actie-indicaties naar gekoppelde beheerders veroorzaken.
• Externe beheerderberichten zijn zichtbaar voor gebruiker en beheerders en triggeren een systeembericht of actie-indicatie naar de gebruiker wanneer er een update of vraag is.
• Externe gebruikersberichten zijn zichtbaar voor beheerders en gebruiker en kunnen systeemberichten of actie-indicaties naar gekoppelde beheerders veroorzaken.
• Wanneer een beheerder een External bericht plaatst, wordt de beheerdernaam in de gebruikersinterface niet getoond; de gebruiker ziet generiek Beheerder. CreatedByUserId blijft wel technisch vastgelegd voor audit en beheer.
• Wanneer de gebruiker zelf een melding sluit, wordt de verplichte sluitreden naast TicketClosures ook als External gebruikersbericht vastgelegd, zodat de reden in de discussie zichtbaar blijft.
• Systeemgegenereerde discussie-items zijn geen handmatige berichten.

Lifecycle / gedrag

• Discussieberichten worden niet hard verwijderd.
• De discussie blijft onderdeel van de volledige ticketgeschiedenis.

Designkeuzes

• Één discussietabel met MessageType en Visibility houdt de weergave compact, terwijl semantisch onderscheid tussen intern, extern en systeem behouden blijft.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: TicketId -> Tickets.Id.

Functionele / logische verwijzingen zonder harde FK

• CreatedByUserId is een soft link naar identity.Users.Id. Null blijft toegestaan voor systeemgegenereerde discussieregels.
• De velden MessageType en Visibility functioneren als code-, enum- of sleutelwaarden en verwijzen bewust niet via een harde foreign key.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.7 TicketHistory

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketHistory	Meldingen	Compacte auditlaag van acties rondom een ticket.	Tickets, Users

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van het historyrecord. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketId	uniqueidentifier	-	N	J	Tickets.Id	N	N	J	Bijbehorend ticket.
OccurredAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip van de actie.
ActorUserId	uniqueidentifier	-	N	N	Users.Id	N	J	J	Soft link naar identity.Users.Id; actor die de actie heeft uitgevoerd. Null voor volledig systeemgedreven acties. Geen harde database-FK vanwege modulegrens.
ActionType	nvarchar(50)	-	N	N	-	N	N	N	Gesloten domeinwaarde die het soort ticketactie benoemt.
OldValue	nvarchar(500)	null	N	N	-	N	J	N	Vorige compacte snapshotwaarde indien van toepassing.
ActorDisplayNameSnapshot	nvarchar(200)	-	N	N	-	N	J	N	Naamweergave van de actor op het moment van de actie.
NewValue	nvarchar(500)	null	N	N	-	N	J	N	Nieuwe compacte snapshotwaarde indien van toepassing.

Validaties / constraints

• ActionType is verplicht. OldValue en NewValue worden gebruikt wanneer de actie een compacte voor/na- of actor/doelwaarde nodig heeft.
• History bevat geen lange toelichtingen of vrije discussie-inhoud; leesbare tekst wordt in de applicatie geformatteerd op basis van ActionType, OldValue en NewValue.
• De V1.0-baseline voor ActionType bestaat uit de gesloten codewaarden Created, Assigned, Unassigned, StatusChanged, DiscussionAdded, Closed, Reopened, SolutionAccepted, ForwardedToTeacher, ReopenDeadlineExpired en TechnicalSnapshotCaptured.
• Uitbreiding van deze codewaarden gebeurt via code en migratie/seeddata, niet via vrije beheerinvoer.

Business rules

• Geschiedenis is een compacte auditlaag met datum/tijd, actor, ActionType en optionele compacte snapshotwaarden.
• Toelichtingen horen in discussie of in gespecialiseerde subtabellen zoals TicketClosures of TicketForwardedToTeacher.
• Acties zoals gebruiker sluit melding, oplossing geaccepteerd, heropend, reactie geplaatst en status gewijzigd worden als compacte ActionType-gedreven auditregels vastgelegd.
• TicketHistory wordt niet gebruikt als gebruikersgerichte statusgeschiedenis; de reguliere gebruiker ziet de functionele ticketinformatie, oplossing en externe discussie, niet de volledige auditlaag.

Lifecycle / gedrag

• Historyrecords worden niet gewijzigd of verwijderd, behalve in uitzonderlijke technische herstelprocedures.

Designkeuzes

• Door history los te houden van discussie blijft de beheerweergave compact en auditgericht. ActionType-gedreven formattering voorkomt vrije, dubbel opgeslagen actietekst.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: TicketId -> Tickets.Id.

Functionele / logische verwijzingen zonder harde FK

• ActorUserId is een soft link naar identity.Users.Id. Null blijft toegestaan voor volledig systeemgedreven historyregels.
• ActionType functioneert als gesloten domeinwaarde en verwijst bewust niet via een harde foreign key.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.8 TicketClosures

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketClosures	Meldingen	Formele registratie van iedere sluitactie op een ticket, inclusief oplossingstekst en heropendeadline.	Tickets, Users, TicketResolutionTypes, TicketForwardedToTeacher

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van de sluitactie. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketId	uniqueidentifier	-	N	J	Tickets.Id	N	N	J	Bijbehorend ticket.
ClosedAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip van de sluitactie.
ClosedByUserId	uniqueidentifier	-	N	N	Users.Id	N	N	J	Soft link naar identity.Users.Id; gebruiker die deze sluitactie heeft uitgevoerd. Geen harde database-FK vanwege modulegrens.
ResolutionTypeId	uniqueidentifier	-	N	J	TicketResolutionTypes.Id	N	N	J	Afsluitstatus die bij deze sluitactie hoort.
SolutionText	nvarchar(max)	-	N	N	-	N	N	N	Oplossingstekst of formele sluittoelichting. Bij gebruikerssluiting bevat dit veld de verplichte reden van de gebruiker.
ReopenDeadlineUtc	datetime2	-	N	N	-	N	N	J	Absolute deadline tot wanneer de gebruiker deze sluiting mag heropenen. Een deadline in het verleden of gelijk aan ClosedAtUtc betekent dat er geen actieve heropenperiode meer is.
ForwardedToTeacherId	uniqueidentifier	-	N	J	TicketForwardedToTeacher.Id	N	J	J	Koppeling naar de docentdoorzetactie indien de sluiting daarvan het gevolg is.
AcceptedByUserId	uniqueidentifier	null	N	N	Users.Id	N	J	J	Soft link naar identity.Users.Id; gebruiker die de aangeboden oplossing heeft geaccepteerd. Geen harde database-FK vanwege modulegrens.
AcceptedAtUtc	datetime2	null	N	N	-	N	J	J	Moment waarop de melder de aangeboden oplossing heeft geaccepteerd.

Validaties / constraints

• Een ticket kan meerdere closure-records hebben.
• ResolutionTypeId is verplicht.
• ReopenDeadlineUtc is verplicht. Wanneer een sluitactie niet actief heropenbaar moet blijven, wordt ReopenDeadlineUtc gezet op ClosedAtUtc of een ander moment dat niet in de toekomst ligt.
• Bij zelf sluiten door de melder wordt het resolutietype ClosedByUser gebruikt en is een sluitreden verplicht. Bij accepteren van een door beheer aangeboden oplossing wordt geen nieuwe sluiting aangemaakt; de bestaande actuele sluitregistratie wordt gemarkeerd met acceptatieactor en acceptatiemoment.

Business rules

Bij iedere beheerder-sluitactie met een oplossing wordt automatisch een reactietermijn vastgelegd. ReopenDeadlineUtc wordt berekend op basis van een sitebreed instelbare waarde in dagen.

• Een ticket kan meerdere keren gesloten worden.
• Iedere sluitactie wordt als apart record opgeslagen.
• De gebruikersgerichte toestand Opgelost wordt afgeleid wanneer de meest recente relevante sluitactie nog een ReopenDeadlineUtc in de toekomst heeft.
• De gebruikersgerichte toestand Gesloten wordt afgeleid wanneer de relevante ReopenDeadlineUtc is verlopen of wanneer de gebruiker de melding zelf sluit of de oplossing accepteert.
• Voor het verlopen van heropentermijnen wordt geen afzonderlijke TickerQ-taak per ticket aangemaakt. Een periodieke TickerQ-verwerking draait minimaal iedere 12 uur en zoekt gesloten meldingen waarvan de actuele heropentermijn inmiddels verlopen is en nog niet als definitief verwerkt of geaccepteerd is.
• Wanneer de gebruiker de melding zelf sluit, wordt een TicketClosures-record aangemaakt met ResolutionTypeId = ClosedByUser, ClosedByUserId = de melder en SolutionText = de verplichte sluitreden.
• Wanneer de gebruiker een oplossing accepteert, wordt de bestaande actuele sluitregistratie definitief voor de gebruiker. Dit wordt vastgelegd via AcceptedByUserId en AcceptedAtUtc op TicketClosures, plus een TicketHistory-record en optioneel een External TicketDiscussionMessages-record zoals Gebruiker heeft de oplossing geaccepteerd.
• De verplichte sluitreden bij zelf sluiten wordt ook als External TicketDiscussionMessages-record opgeslagen, zodat deze in de discussie zichtbaar blijft.
• TicketHistory bevat alleen de compacte auditregel; TicketClosures bevat de formele sluitregistratie.

Lifecycle / gedrag

• Closure-records worden niet aangepast of verwijderd.
• De actuele gesloten toestand op Tickets weerspiegelt steeds de meest recente sluitactie. De gebruikersgerichte weergave Opgelost of Gesloten wordt applicatief bepaald op basis van de actuele sluitcontext en ReopenDeadlineUtc.
• De periodieke TickerQ-verwerking is idempotent: wanneer een eerdere run, scheduler-trigger of serverproces het verlopen van een heropentermijn heeft gemist, wordt dezelfde melding bij een volgende run alsnog opgepakt zolang zij aan de criteria voldoet.

Designkeuzes

• Aparte sluitregistratie voorkomt informatieverlies wanneer een ticket meerdere keren wordt heropend en opnieuw wordt gesloten.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: TicketId -> Tickets.Id; ResolutionTypeId -> TicketResolutionTypes.Id; ForwardedToTeacherId -> TicketForwardedToTeacher.Id.

Functionele / logische verwijzingen zonder harde FK

• ClosedByUserId en AcceptedByUserId zijn soft links naar identity.Users.Id. De formele sluitbron blijft binnen het supportdomein; gebruikerscontext wordt applicatief gevalideerd.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.9 TicketReopenRequests

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketReopenRequests	Meldingen	Registratie van heropenacties door gebruiker of beheerder, inclusief reden en herkomst.	Tickets, Users, TicketStatuses, TicketClosures

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van de heropenregistratie. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketId	uniqueidentifier	-	N	J	Tickets.Id	N	N	J	Bijbehorend ticket.
RequestedByUserId	uniqueidentifier	-	N	N	Users.Id	N	N	J	Soft link naar identity.Users.Id; gebruiker die het ticket heropent. Geen harde database-FK vanwege modulegrens.
RequestedAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip van heropenen.
RequestSource	nvarchar(20)	-	N	N	-	N	N	J	Herkomst van de heropenactie: User of Admin.
Reason	nvarchar(max)	-	N	N	-	N	N	N	Verplichte reden van heropenen.
ResultingStatusId	uniqueidentifier	-	N	J	TicketStatuses.Id	N	N	J	Status waarin het ticket na heropenen terechtkomt. Bij gebruikerheropening wordt dit afgeleid uit actieve beheerderkoppelingen; bij beheerderheropening is dit New.
PreviousClosureId	uniqueidentifier	-	N	J	TicketClosures.Id	N	J	J	Laatste sluitactie waarop dit heropenen betrekking heeft.

Validaties / constraints

• Reason is verplicht.
• RequestSource wordt centraal gestandaardiseerd.
• Wanneer het heropenen betrekking heeft op een bestaande sluiting, moet PreviousClosureId ingevuld zijn.

Business rules

• Heropenen door gebruiker en door beheerder zijn verschillende flows, maar worden beide expliciet vastgelegd.
• Heropenen door de gebruiker maakt de melding opnieuw behandelbaar zonder actieve beheerders te ontkoppelen. Bestaat er nog een actieve beheerderkoppeling, dan resulteert de status in InProgress; zonder actieve beheerderkoppeling resulteert de status in New. Handmatig heropenen door een beheerder zet het ticket altijd terug naar New en ontkoppelt actieve beheerders, zodat de melding opnieuw kan worden opgepakt.
• Heropenen door gebruiker is alleen toegestaan vóór de deadline van de betreffende sluiting.
• De reden voor heropenen is verplicht en wordt in TicketReopenRequests vastgelegd. Daarnaast wordt de heropening als TicketHistory-record vastgelegd en kan de reden bij gebruikerheropening als External TicketDiscussionMessages-record zichtbaar blijven in de discussie. Bij beheerderheropening blijft de reden intern beheergericht en mag deze niet als gebruikersbericht aan de melder worden getoond.
• De actie-indicatie Wacht op mij wordt niet opgeslagen in deze tabel; die wordt afgeleid uit de actuele ticketstatus WaitingForUser in combinatie met CreatedByUserId van het ticket.

Lifecycle / gedrag

• Heropenrecords worden niet aangepast of verwijderd.
• Een ticket kan meerdere reopen-records hebben over de tijd.

Designkeuzes

• Aparte heropenregistratie maakt herhaald sluiten en heropenen volledig herleidbaar zonder de historylaag te overbelasten.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: TicketId -> Tickets.Id; ResultingStatusId -> TicketStatuses.Id; PreviousClosureId -> TicketClosures.Id.

Functionele / logische verwijzingen zonder harde FK

• RequestedByUserId is een soft link naar identity.Users.Id. De heropenactie wordt binnen het supportdomein opgeslagen; actorvalidatie loopt via Identity/Authorization-contracten.
• RequestSource functioneert als gesloten domeinwaarde en verwijst bewust niet via een harde foreign key.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.10 TicketForwardedToTeacher

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketForwardedToTeacher	Meldingen	Registratie van de actie waarbij een ticket namens de gebruiker wordt doorgezet naar een docent.	Tickets, Users, PrivateMessageThreads, PrivateMessages, TicketClosures

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van de doorzetactie. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketId	uniqueidentifier	-	N	J	Tickets.Id	N	N	J	Bijbehorend ticket.
TeacherUserId	uniqueidentifier	-	N	N	Users.Id	N	N	J	Soft link naar identity.Users.Id; docent naar wie de situatie is doorgestuurd. Geen harde database-FK vanwege modulegrens.
ForwardedAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip van doorzetten.
ForwardedByAdminUserId	uniqueidentifier	-	N	N	Users.Id	N	N	J	Soft link naar identity.Users.Id; beheerder die het ticket heeft doorgezet. Geen harde database-FK vanwege modulegrens.
AdminExplanation	nvarchar(max)	-	N	N	-	N	N	N	Toelichting van de beheerder richting docent.
GeneratedPrivateMessageThreadId	uniqueidentifier	-	N	N	PrivateMessageThreads.Id	N	J	J	Soft link naar communication.PrivateMessageThreads.Id; gegenereerde privéberichtthread richting docent. Geen harde database-FK vanwege modulegrens.
GeneratedPrivateMessageId	uniqueidentifier	-	N	N	PrivateMessages.Id	N	J	J	Soft link naar communication.PrivateMessages.Id; eerste gegenereerde privébericht in die thread. Geen harde database-FK vanwege modulegrens.

Validaties / constraints

• TeacherUserId en AdminExplanation zijn verplicht.
• Per formele sluitactie wordt hoogstens één doorzetregistratie naar een docent vastgelegd.

Business rules

• Doorzetten naar docent is een zware domeinactie: de melding wordt automatisch gesloten met resolutietype Module configuratie, de gebruiker krijgt een systeembericht en er wordt een privébericht namens de gebruiker naar de geselecteerde docent verstuurd.

Lifecycle / gedrag

• Doorzetrecords worden niet gewijzigd of verwijderd.
• Herleidbaarheid naar gegenereerde privécommunicatie blijft behouden.

Designkeuzes

• Deze actie wordt apart gemodelleerd omdat zij meerdere neveneffecten heeft die niet zuiver in TicketHistory of TicketClosures passen.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: TicketId -> Tickets.Id.

Functionele / logische verwijzingen zonder harde FK

• TeacherUserId en ForwardedByAdminUserId zijn soft links naar identity.Users.Id.
• GeneratedPrivateMessageThreadId en GeneratedPrivateMessageId zijn soft links naar respectievelijk communication.PrivateMessageThreads.Id en communication.PrivateMessages.Id. Zij worden niet als harde database-FK afgedwongen vanwege de modulegrens tussen support en communication.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.11 TicketTechnicalSnapshots

Tabelnaam	Categorie	Doel / verantwoordelijkheid	Gerelateerde tabellen
TicketTechnicalSnapshots	Meldingen	Momentopname van technische context op het moment dat een melding wordt aangemaakt.	Users, Tickets

Veldnaam	Type	Default	PK	FK	Verwijst naar	Unique	Nullable	Index	Opmerking
Id	uniqueidentifier	-	J	N	-	J	N	J	Primaire sleutel van de snapshot. GUID wordt in de applicatiecode gegenereerd; geen database-default.
TicketId	uniqueidentifier	-	N	J	Tickets.Id	J	N	J	Bijbehorend ticket. Eén ticket heeft één primaire technische momentopname.
UserAgent	nvarchar(1000)	-	N	N	-	N	N	N	Volledige user agent string van het verzoek waarmee de melding werd ingediend.
PageUrl	nvarchar(1000)	-	N	N	-	N	N	N	Pagina waarop de gebruiker zich bevond bij het indienen van de melding.
IpAddress	nvarchar(64)	-	N	N	-	N	N	N	IP-adres van de gebruiker op het moment van melden.
UserRolesSnapshot	nvarchar(500)	-	N	N	-	N	N	N	Tekstuele momentopname van de rollen van de gebruiker tijdens het melden.
LastSeenAtUtc	datetime2	-	N	N	-	N	J	N	Laatst gezien-tijdstip zoals bekend op het moment van registreren.
CapturedAtUtc	datetime2	sysutcdatetime()	N	N	-	N	N	J	Tijdstip waarop de snapshot is vastgelegd.

Validaties / constraints

• TicketId is uniek wanneer per ticket slechts één primaire snapshot wordt vastgelegd.
• Momentopnamevelden worden niet achteraf herschreven op basis van latere gebruikerscontext.

Business rules

• Technische metadata in Geavanceerd is een snapshot van het moment van melden en geen live berekende context.
• Deze technische snapshot is bedoeld voor beheer en foutanalyse. De reguliere gebruiker hoeft deze metadata niet te zien en krijgt ook geen aparte melding dat deze informatie beschikbaar is voor beheer.

Lifecycle / gedrag

• Technical snapshots worden in beginsel niet aangepast of verwijderd door reguliere functionele processen.
• Per ticket wordt één primaire technische momentopname vastgelegd van de context op het moment van melden. Alleen in uitzonderlijke technische herstelprocedures mag correctie plaatsvinden wanneer aantoonbaar foutieve of onvolledige snapshotdata is opgeslagen.
• De snapshot blijft historisch gekoppeld aan het ticket, ook wanneer de onderliggende pagina of andere context later wijzigt of niet meer actief beschikbaar is.

Designkeuzes

• Technische context is bewust in een aparte snapshottabel ondergebracht en niet rechtstreeks in Tickets, zodat het hoofdrecord van de melding functioneel compact blijft en technische momentopname los beheerbaar en uitbreidbaar is.
• De tabel legt de situatie vast zoals die was op het moment van melden en is nadrukkelijk geen live herleidbare contextview. Waar een context betrouwbaar naar een vaste entiteit kan verwijzen, kan een foreign key gebruikt worden; aanvullende technische en tekstuele context blijft echter bewust als snapshot opgeslagen zodat reconstructie mogelijk blijft wanneer brondata later wijzigt.

Foreign keys op databaseniveau

• Harde foreign keys op databaseniveau: TicketId -> Tickets.Id.

Functionele / logische verwijzingen zonder harde FK

• De velden PageUrl, IpAddress bevatten inhoudelijke of technische contextwaarden en zijn daarom logische samenhang zonder harde foreign key.

FK + snapshot

• FK + snapshot: niet van toepassing binnen deze tabel.

6.12 Meldingenlifecycle en gebruikers-/beheerflows

6.12.1 Ticketaanmaak en technische snapshot

• Een nieuwe melding wordt vastgelegd als Tickets-record met status New, categorie, onderwerp, beschrijving, melder en uniek meldingsnummer.
• Bij aanmaak wordt één primaire technische momentopname vastgelegd in TicketTechnicalSnapshots.
• De technische snapshot is beheerinformatie en wordt niet als live context opnieuw berekend.
• Het indienen van een melding kan een SystemMessages-record veroorzaken met EntityType = Ticket, maar de meldingstatus blijft eigendom van het ticketdomein.

6.12.2 Gebruikersoverzicht en afgeleide statussen

• De gebruikersweergave Mijn meldingen toont uitsluitend tickets waarvoor Tickets.CreatedByUserId de ingelogde gebruiker is.
• De tab Wacht op mij is een afleiding uit Tickets.Status = WaitingForUser in combinatie met de meldercontext.
• De gebruikersgerichte toestand Opgelost is geen opgeslagen ticketstatus. Deze wordt afgeleid uit Status = Closed, de actuele sluitregistratie en een nog geldige ReopenDeadlineUtc zonder geaccepteerde oplossing.
• Na acceptatie van een oplossing wordt de melding gebruikersgericht Gesloten, ook wanneer de oorspronkelijke heropentermijn historisch nog zichtbaar is.

6.12.3 Actieve behandelcontext voor beheeracties

• Externe beheercommunicatie, formeel oplossen/sluiten en doorzetten naar docent mogen niet rechtstreeks vanuit status New worden uitgevoerd.
• Een beheerder moet de melding eerst via TicketAssignments aan minimaal één beheerder koppelen. Daardoor ontstaat een actieve behandelcontext en wordt de status InProgress.
• Interne oriëntatie, lezen en selecteren door beheerders mag wel op een nieuwe melding plaatsvinden zonder actieve assignment.
• Status New blijft uitsluitend geldig zolang er geen actieve beheerderkoppeling bestaat.

6.12.4 Externe en interne discussie

• Gebruikersreacties zijn altijd TicketDiscussionMessages met Visibility = External.
• Externe beheerderberichten zijn zichtbaar voor melder en beheerders, maar tonen richting melder generiek als Beheerder; de werkelijke beheerder blijft via CreatedByUserId auditbaar.
• Interne beheerderberichten hebben Visibility = Internal, zijn nooit zichtbaar voor de melder en veroorzaken geen mailboxbericht richting melder.
• Discussieberichten zijn inhoudelijke communicatie; compacte actiehistorie hoort in TicketHistory.
• Systeemgegenereerde discussie-items mogen zichtbare procesinformatie tonen, maar vervangen geen gespecialiseerde tabellen zoals TicketClosures, TicketReopenRequests of TicketForwardedToTeacher.

6.12.5 Sluiten, oplossen en accepteren

• Sluiten door de melder maakt een nieuw TicketClosures-record met resolutietype ClosedByUser en de verplichte sluitreden in SolutionText.
• De sluitreden van de melder wordt daarnaast als External TicketDiscussionMessages-record vastgelegd, zodat deze in de discussie zichtbaar blijft.
• Oplossen of sluiten door beheer maakt een formele TicketClosures-registratie met inhoudelijk resolutietype, oplossing/sluittoelichting en ReopenDeadlineUtc.
• Het accepteren van een oplossing maakt geen tweede TicketClosures-record aan. De actuele sluitregistratie wordt gemarkeerd via AcceptedByUserId en AcceptedAtUtc.
• Acceptatie beëindigt de functionele heropenmogelijkheid voor de melder en wordt via TicketHistory vastgelegd.
• Het verlopen van de heropentermijn wordt periodiek verwerkt door een TickerQ-job die minimaal iedere 12 uur gesloten meldingen controleert met een actuele sluitregistratie waarvan ReopenDeadlineUtc <= nowUtc, zonder acceptatie en zonder latere heropening.
• De periodieke verwerking maakt geen nieuwe TicketClosures aan en herschrijft de oplossing niet; zij legt waar nodig alleen een compacte TicketHistory-regel vast dat de melding na verlopen heropentermijn definitief gesloten is geworden.
• Omdat dezelfde periodieke job steeds opnieuw op criteria zoekt, vangt zij gemiste of mislukte eerdere scheduleruitvoeringen op bij een volgende run.

6.12.6 Heropenen

• Heropenen door de gebruiker is alleen toegestaan binnen de heropentermijn en alleen zolang de actuele sluiting nog niet door de gebruiker is geaccepteerd.
• Heropenen door de gebruiker ontkoppelt geen actieve beheerders. De resulterende status is InProgress wanneer nog een actieve beheerderkoppeling bestaat en New wanneer er geen actieve beheerderkoppeling bestaat.
• Handmatig heropenen door beheer is niet afhankelijk van de gebruikersgerichte heropentermijn.
• Handmatig heropenen door beheer ontkoppelt actieve beheerders, zet de melding terug naar New en vereist een verplichte interne reden.
• Bij handmatig heropenen door beheer worden minimaal twee aparte TicketHistory-acties vastgelegd: één voor heropenen en één voor het ontkoppelen of resetten van actieve beheerderkoppelingen.

6.12.7 Doorzetten naar docent

• Doorzetten naar docent is een samengestelde transactie: ticketdoorzetregistratie, formele sluiting met resolutietype ModuleConfiguration, systeembericht aan de melder, privébericht namens de melder aan de docent en auditregistratie.
• De doorzetactie gebruikt TicketForwardedToTeacher voor de domeinregistratie en PrivateMessages.SendAsUserId voor de functionele afzenderweergave namens de melder.
• Doorzetten naar docent mag alleen vanuit een actieve behandelcontext en niet rechtstreeks vanuit New.
• De doorzetactie maakt geen nieuwe docent-leerlingrelatie en kent geen nieuwe niveau-autorisatie toe.

6.13 Account-lifecycle binnen meldingenbeheer

6.13.1 Accountanonimisering en meldingencontext

• UC-GEN-ACC-005 raakt het meldingen- en ticketdomein wanneer het te anonimiseren account melder, beheerder, toegewezen beheerder, discussie-actor, sluitactor, heropenactor of doorzetactor is.
• Accountanonimisering verwijdert geen tickets, ticketdiscussies, ticketgeschiedenis, sluitregistraties, heropenverzoeken, doorzetrecords of technische snapshots.
• Open meldingen blijven opvolgbaar voor bevoegde beheerders, maar persoonsgegevens van het geanonimiseerde account mogen niet meer als actuele gebruikersidentiteit worden getoond.
• Historische verwijzingen naar Users.Id blijven functioneel bestaan waar zij nodig zijn voor herleidbaarheid, autorisatiecontrole, audit of beheeranalyse. De zichtbare identiteit komt na anonimisering uit het geanonimiseerde Users-record of uit eerder vastgelegde snapshots.
• Accountanonimisering maakt geen nieuwe melding aan en sluit open meldingen niet automatisch. Sluiten, oplossen, accepteren en heropenen blijven ticketdomeinacties.

6.13.2 Tickets waarbij de melder wordt geanonimiseerd

• Wanneer Tickets.CreatedByUserId verwijst naar het te anonimiseren account, blijft het ticket bestaan.
• De melder kan na anonimisering niet meer reageren, de oplossing accepteren, de melding zelf sluiten of heropenen vanuit dat account.
• Beheerders mogen de melding blijven behandelen voor zover de meldingstatus en autorisatie dat toestaan.
• Gebruikersgerichte vervolgacties voor het geanonimiseerde account worden niet meer aangeboden, omdat Users.IsActive = false reguliere OefenHub-toegang blokkeert.
• Systeemberichten richting het geanonimiseerde account worden niet gebruikt als actief vervolgkanaal. Bestaande systeemberichten blijven historisch onderdeel van het communicatiedomein.

6.13.3 TicketAssignments bij accountanonimisering

• Wanneer het te anonimiseren account actief gekoppeld is als beheerder via TicketAssignments.AdminUserId, wordt de actieve assignment beëindigd.
• Beëindiging van een actieve beheerderkoppeling door accountanonimisering wordt vastgelegd met een UnassignedAtUtc-waarde en, waar het datamodel dit toelaat, met UnassignedByUserId als systeem- of uitvoerende actor.
• Daarnaast wordt minimaal een compacte TicketHistory-regel toegevoegd, zodat zichtbaar blijft dat de behandelcontext is aangepast door accountanonimisering.
• Het beëindigen van een assignment door accountanonimisering zet de melding niet automatisch op Closed en maakt geen oplossing of sluitregistratie aan.
• Wanneer na beëindiging geen actieve beheerderkoppeling meer bestaat, wordt de verdere statusafleiding door de ticketregels bepaald. Een melding wordt niet stilzwijgend afgehandeld enkel omdat een beheerderaccount is geanonimiseerd.

6.13.4 TicketDiscussionMessages, TicketHistory en zichtbare identiteit

• TicketDiscussionMessages.CreatedByUserId wordt niet hard verwijderd wanneer de actor later wordt geanonimiseerd.
• Richting reguliere gebruikers wordt een geanonimiseerde gebruiker niet opnieuw als herleidbare persoon getoond. Beheerweergaven mogen technische herleidbaarheid behouden via audit en geanonimiseerde systeemidentiteit.
• TicketHistory.ActorUserId blijft een historische actorverwijzing. De historyregel wordt niet herschreven naar vrije tekst, maar de UI moet rekening houden met geanonimiseerde gebruikersweergave.
• Interne en externe discussie-inhoud wordt niet automatisch inhoudelijk herschreven door accountanonimisering. Waar vrije tekst persoonsgegevens bevat, valt eventuele verdere schoning buiten deze generieke accountflow en vereist afzonderlijk beleid.

6.13.5 TicketClosures en TicketReopenRequests

• TicketClosures.ClosedByUserId en TicketClosures.AcceptedByUserId blijven historische verwijzingen wanneer de betreffende gebruiker later wordt geanonimiseerd.
• Een bestaande sluiting of acceptatie wordt niet ongedaan gemaakt door accountanonimisering.
• TicketReopenRequests.RequestedByUserId blijft historische herleidbaarheid bieden, maar de zichtbare gebruikersidentiteit volgt na anonimisering de algemene anonimiseerregels.
• Een geanonimiseerd/inactief account kan geen nieuwe heropenactie starten.

6.13.6 TicketForwardedToTeacher en namens-verzending

• TicketForwardedToTeacher.TeacherUserId en ForwardedByAdminUserId blijven historische verwijzingen wanneer één van deze accounts later wordt geanonimiseerd.
• Een bestaande doorzetregistratie wordt niet verwijderd of inhoudelijk herschreven.
• Wanneer een privébericht namens de melder is aangemaakt, blijft de berichtregistratie bestaan volgens het communicatiedomein. De zichtbare identiteit van de namens-gebruiker volgt de anonimiseerregels uit Users en eventuele berichtspecifieke snapshots.

6.13.7 Technische snapshots

• TicketTechnicalSnapshots blijven een momentopname van het moment van melden.
• Accountanonimisering herberekent technische snapshots niet en verwijdert deze niet automatisch.
• Snapshotvelden die persoonsgegevens kunnen bevatten worden niet als actuele bron van gebruikersidentiteit gebruikt. Zij blijven beheer- en analysegegevens waarvoor toegangsbeperking en privacybeleid gelden.

6.13.8 Geen nieuwe ticketentiteiten

• UC-GEN-ACC-005 introduceert geen nieuwe ticket- of meldingentabellen.
• De impact wordt verwerkt via bestaande tabellen, zoals Tickets, TicketAssignments, TicketDiscussionMessages, TicketHistory, TicketClosures, TicketReopenRequests, TicketForwardedToTeacher en TicketTechnicalSnapshots.
• De primaire accountwaarheid blijft Users.IsActive in combinatie met de geanonimiseerde identiteit en account lifecycle-logging.