TCMProject.Events 26.9.19.1

• net10.0

  • No dependencies.

TCMProject.Events: PersonUpdatedV1.Gender pasa a int? -- CAMBIO INCOMPATIBLE al compilar, compatible en el cable. Hasta ahora el sexo era obligatorio y no existia forma de decir "no se informo": el alta ponia OTHER por defecto, asi que ese valor significaba a la vez "esta persona es Otro" y "nadie pregunto". Con el campo sobrecargado la interfaz tenia que elegir una de las dos lecturas -- eligio "no informado", y en consecuencia Otro era una opcion que el desplegable ofrecia y no se podia guardar. Ahora null es "no se informo" y OTHER vuelve a significar solo Otro. ORDEN DE ADOPCION OBLIGATORIO: primero los CONSUMIDORES (medicalhistory y scheduleeasy, cuyas columnas ya son int?), despues el PRODUCTOR (tcmaccounts). Al reves, un null enviado por accounts llega a un consumidor que todavia espera int y el mensaje muere o -- peor -- deserializa como 0, que es MALE: un sexo inventado en la ficha de un paciente. Los demas paquetes se republican solo por la version compartida, sin cambios. Nota anterior (26.9.18.3) - TCMProject.Audit: SnapshotAll(). Para entidades que son RENGLONES DE UN DOCUMENTO --una linea de receta-- el evento de update lleva TODOS los campos (los quietos con old == new) y no solo los que cambiaron. Sin esto, editar la duracion de un medicamento emitia DurationQuantity 5 -> 3 y nada mas: imposible componer la frase completa en el historial, porque el nombre y la dosis no viajaban. Es opt-in POR ENTIDAD y NO cambia el contrato: mismo AuditFieldChange, unas filas chicas mas por evento. NO usar en entidades con campos grandes --cada guardado re-copiaria el blob aunque no cambie--; para eso esta Truncate. Guarda anti no-op: un Attach+Update sin ningun cambio real NO emite evento aunque SnapshotAll este activo, porque una foto de puros iguales seria ruido que ademas parece actividad. Los demas paquetes se republican solo por la version compartida, sin cambios. Nota anterior (26.9.16.1) - TCMProject.Utilities: PermissionEnum PLATFORM_IMPERSONATE_USER=124, dentro del rango 121-129 reservado para PLATFORM_*. Es el permiso del "login as" del panel: abrir una sesion auditada como otro usuario para reproducir un problema de produccion. Va SEPARADO y no reusa PLATFORM_CREATE_CROSS_TENANT_USER=104 a proposito: entrar como alguien no es lo mismo que crear un usuario, y con un permiso compartido quien puede lo uno puede lo otro -- el mismo error que ya se corrigio separando aprobar de crear un descuento. Como todo permiso nuevo, NO cae solo sobre los roles existentes: hay que sembrarlo. Ver knowledge-base/platform/identity/login-as-auditado.md. Los demas paquetes no cambian. Nota anterior (26.9.15.2) - TCMProject.Events: se ELIMINA AppointmentNoShowV1. Era el contrato piloto del bus, elegido a proposito por ser inofensivo -un hecho consumado que nadie consumia con efecto de negocio- para ejercitar outbox, RabbitMQ y consumidor de punta a punta. Cumplio esa funcion: el ciclo completo quedo demostrado por el pipeline de auditoria, que cruza cuatro procesos con un contrato real. Ningun servicio del ecosistema lo referenciaba fuera de scheduleeasycore, y alli solo lo usaban el consumidor de humo y los tests de outbox, que pasan a un contrato de prueba propio. CAMBIO INCOMPATIBLE si alguien lo usaba: las versiones anteriores siguen en nuget.org. AuditChangeRecordedV1 NO se toca. Nota anterior (26.9.10.1) - TCMProject.Messaging: sin TransactionScope, el flush se dispara por el evento SavedChanges del DbContext y no por un ISaveChangesInterceptor del contenedor. Medido: EF Core no descubria ese interceptor desde DI y los sobres quedaban sin soltar en jobs, consumidores y comandos con SkipCommandTransaction. El evento no depende de como se haya registrado el contexto, y este paquete no controla el AddDbContext del servicio. Nota anterior (26.9.9.5) - TCMProject.Messaging: el outbox ENTREGA SOLO tras el commit. Publicar alcanza. Antes, PublishAsync encolaba y el sobre quedaba en la tabla como propiedad del nodo esperando un flush que en algunos caminos no llegaba nunca; el agente de durabilidad no lo tocaba porque solo reclama sobres de nodos MUERTOS. Sintoma: cero errores, la publicacion parece correcta, y la cola no recibe nada mientras el outbox crece. Ahora la garantia vive en el outbox y no en quien publica. Con TransactionScope, PublishAsync se suscribe a TransactionCompleted: eso solo REGISTRA una funcion, no abre conexiones; el flush corre cuando el evento dispara, o sea despues del commit, y solo si Status es Committed. Sin TransactionScope (jobs, consumidores, SkipCommandTransaction), OutboxFlushInterceptor suelta al terminar el SaveChanges, que ahi ya commiteo por su cuenta; EF Core lo descubre solo del contenedor. NO se suelta durante el SaveChanges a proposito: con la conexion de EF abierta, el flush abre una SEGUNDA conexion, .NET promueve a transaccion distribuida y Postgres responde 55000 prepared transactions are disabled, abortando tambien el cambio de negocio. El flush va con TransactionScopeOption.Suppress o intentaria enlistarse en la transaccion recien cerrada. MultiFlushMode AllowMultiples: con el default OnlyOnce, un sobre encolado DESPUES de un flush se descarta en silencio (JasperFx/wolverine issue 1825). NUEVO Outbox:StaleMinutes (10 por defecto) libera los sobres que nadie solto; es la RED y no el camino, alto a proposito para que en operacion normal el outbox este vacio y la metrica de profundidad siga sirviendo de alarma. SaveChangesAndFlushAsync queda OBSOLETO: suelta dentro del TransactionScope, antes del commit final. TCMProject.Audit no cambia. Nota anterior (26.9.9.4) - TCMProject.Utilities: recupera PLATFORM_RESEND_EMAILS=121 en main (publicado en 26.8.25.6 y en uso por tcmadmingateway; las 26.9.x lo habian perdido y rompian la compilacion del gateway). Ademas, permisos de Ulandin (26.9.9.3): ModuleEnum.PLATFORM_ULANDIN (anexado al final, enum sin valores explicitos) y PermissionEnum PLATFORM_VIEW_ULANDIN=122 / PLATFORM_MANAGE_ULANDIN=123, dentro del rango 121-129 reservado para PLATFORM_*; el 121 sigue reclamado por la rama de reenvio de correos. El seeder de tcmaccounts los concede solo a Owner/Administrator de TCM-X al adoptar esta version. Los demas paquetes se republican solo por la version compartida, sin cambios. Nota anterior (26.9.9.2) - TCMProject.Audit: primera version. Log de cambios campo a campo -quien cambio que, cuando, valor anterior y nuevo- para las APIs del ecosistema. Se engancha via DbContextOptions: no hay que tocar ningun handler ni repositorio. Fase 0 del RFC (knowledge-base/platform/infrastructure/audit-trail-design.md). OJO AL ADOPTAR: AddTcmAudit REVIENTA el arranque si Messaging:Enabled=false o Messaging:RabbitMq:Enabled=false. No es capricho: el outbox aguanta que el broker se CAIGA -el sobre queda persistido y se recupera solo- pero SIN transporte configurado Wolverine no encuentra ruta, dispara NoRoutesFor y descarta el mensaje sin persistirlo. Para auditoria eso rompe el requisito 6 y encima en silencio. Un servicio adopta la auditoria DESPUES de tener broker, no antes. La auditoria es opt-in por entidad y por campo (leccion de Salesforce: auditar todo multiplica el volumen de escritura); lo que no se declara con audit.Entity de T o [Audited], no se audita. Deny-list global: RowVersion, AppCreatedBy, AppCreationDate, AppLastUpdatedBy y AppLastUpdatedDate nunca se auditan -son ruido, el encabezado ya los trae- sin ella cada update generaria tres diffs de basura. Valores en JSON invariante, no ToString(), para que un decimal o un DateTime no queden distintos segun la cultura del servidor. Redact() guarda solo el hash; Truncate() guarda hash mas longitud por encima del umbral. FailOpen es el unico modo: un fallo de captura NO tumba la escritura de negocio, se loguea con severidad alta. TCMProject.Events suma los contratos de auditoria (AuditChangeRecordedV1, AuditFieldChange y sus enums) y sigue SIN dependencias, para que TCM.AuditApi pueda referenciarlo sin heredar EF ni el transporte. TCMProject.Messaging no cambia de contenido; se republica porque Audit lo referencia por ProjectReference y la dependencia queda fijada a esta misma version. Verificado con 20 tests, sin Postgres ni RabbitMQ: deny-list, opt-in, redactado, truncado, delete, impersonacion, captura por SavingChanges Y SavingChangesAsync -RepositoryBase.Update usa el sincrono, cubrir solo el asincrono dejaria sin auditar dos servicios enteros-, y que la validacion reviente cuando falta transporte.