AuditedTypes.Contains(entry.Entity.GetType()) exigeait l'egalite exacte de type, or Section est abstraite : le type runtime est toujours SectionMap, SectionQuiz... Aucune des 13 sortes de section n'etait journalisee -- soit precisement ce que l'ecran d'audit livre le 12/08 devait tracer. Resource, Configuration, Device, User et Instance, eux, passaient : ils sont concrets, et c'est ce qui rendait le trou invisible. Remplace par une remontee a la classe de base auditee (IsInstanceOfType). EntityType porte « Section », pas « SectionMap ». Des deux sorties possibles, c'est la normalisation cote serveur qui est retenue : - le filtre « Section » est deja dans l'ecran et se met a rendre des lignes sans toucher manager-app, donc sans coordonner deux repos ; - elargir le filtre front aurait coute 13 entrees de liste et 39 cles i18n, et surtout aurait laisse tout futur sous-type sortir du filtre en silence -- la meme classe de panne que celle qu'on ferme ici ; - le sous-type concret n'est pas perdu : le discriminateur TPH est une propriete du modele, donc serialisee dans NewValues (« Discriminator »: « Article »). Un test le tient. 8 tests, dont un par reflexion qui affirme que les 13 sous-types concrets resolvent bien vers Section : la liste de types d'origine n'obligeait personne a la suivre, c'est ce qui l'a laissee devenir fausse. dotnet test 171/171. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Migrations
Invite de commande
Ouvrir un invite de commande dans le répertoire de la solution
Supprimer la dernière migration
A faire uniquement si elle n'a pas encore été appliquée à la base de données
dotnet ef migrations remove
Ajouter une migration
dotnet ef migrations add
Mise à jour de la base de données
dotnet ef database update