Shared lookupOptions NULL scope confirmed intentional; no backfill

Sub-tickets

Activity

• db-terra-ca created · 1w ago
• db-terra-ca titleChanged · 1w ago
  Shared lookupOptions scope: decide intended cross-app categories
• db-terra-ca descriptionChanged · 1w ago
  was: SELECT-only shared project eprpywqwzsvrjeaforei, 2026-10-06: public.lookupOptions has ownerAppKey NULL in 8 categories, 55 rows total, all active/undeleted: accessIssueReason 2, antecedenteGrupo 6, appEventCategory 17, correctionRequestStatus 4, documentoType 5, rolEnPractica 5, supportTicketCategory 6, supportTicketStatus 10. Source census of current Terra src and Enamel app/src: documentoType labels are rendered by BOTH apps (Terra practica/paciente picker and Enamel usuarios/historia-clinica forms). accessIssueReason values are consumed by BOTH filing paths but neither renders lookupOption.label; both use local copy/derived reason. rolEnPractica labels render in Terra practica form; no Enamel UI consumer found. supportTicketCategory and supportTicketStatus labels render in Enamel soporte UI; Terra admin queue uses subject and raw statusValue, not lookup labels. appEventCategory is a telemetry code in Terra; no label rendering found. antecedenteGrupo and correctionRequestStatus have no direct app-source category reference found; Terra renders antecedentesCatalog.grupo, a different relation. Thus a shared NULL owner value is a real cross-app label coupling for documentoType; other categories have different consumers/limits and should not be assumed to render in both. No ownerAppKey backfill or label edit authorized: deciding which app owns each shared label is a product/shared-schema decision. Need owner ruling and targeted review before any DML.
• db-terra-ca note · 1w ago
  Enamel-side evidence is SOURCE ONLY, not owner approval or live UI proof: /home/rob/Documents/work/pensanta/websites/enamel-pensanta-com/app/src/app/solicitar-acceso/actions.ts derives reason noProfile server-side and inserts accessIssueReports with APP_KEY from app-keys (Enamel); this path does not render lookupOptions.label. Enamel lane must confirm intended cross-app sharing for its categories. Terra source shows /solicitar-acceso and /identidad-en-revision send noProfile and identidadEnRevision with appKey terra. PM muwr37s61pum rules NO ownerAppKey changes under any circumstance; this row is read-only intent classification.
• db-terra-ca descriptionChanged · 1w ago
  was: SELECT-only shared project eprpywqwzsvrjeaforei, 2026-10-06: public.lookupOptions has ownerAppKey NULL in 8 categories / 55 rows, all active and undeleted: accessIssueReason 2, antecedenteGrupo 6, appEventCategory 17, correctionRequestStatus 4, documentoType 5, rolEnPractica 5, supportTicketCategory 6, supportTicketStatus 10. NULL is the intentional shared scope, not a missing owner. The live fn_reportAccessIssue validates active reasonValue with (ownerAppKey IS NULL OR ownerAppKey=appKeyArg), returning invalidReason on mismatch. Terra passes noProfile or identidadEnRevision and appKey terra; Enamel passes noProfile and appKey enamel. Reassigning either shared accessIssueReason row to one app would silently refuse the other app's submissions. No ownerAppKey UPDATE is authorized. Current source consumer census: both apps render documentoType lookup labels (Terra practica/paciente form, Enamel usuarios/historia-clinica forms). Both consume accessIssueReason codes, but their form copy is local and neither renders lookupOptions.label. Terra renders rolEnPractica labels; no Enamel UI consumer found. Enamel renders supportTicketCategory and supportTicketStatus labels; Terra admin queue prints a raw status code rather than these labels. appEventCategory is telemetry vocabulary; no label rendering found. No direct app-source category references found for antecedenteGrupo or correctionRequestStatus; Terra's antecedentesCatalog.grupo is a different relation. These are source-bounded findings, not a live visual UI proof. Decision requested: for each category, is cross-app sharing intentional? Where yes, keep NULL. Where not, design app-specific rows and scoped readers with both apps' owner review; do not reassign an existing shared row. No data change or label edit until that decision.
• db-terra-ca titleChanged · 1w ago
  Shared lookupOptions NULL scope confirmed intentional; no backfill
• db-terra-ca completed · 1w ago
  PM muws03pfbezr decided no ownerAppKey backfill: all 55 NULL rows across eight named categories retain deliberate shared scope. Read-only census and source-bounded consumer mapping preserved in description. No write performed.
• db-terra-ca decision · 1w ago
  PM final muws1scc4ej9: YES, INTENTIONALLY SHARED for ALL EIGHT categories: accessIssueReason (2), antecedenteGrupo (6), appEventCategory (17), correctionRequestStatus (4), documentoType (5), rolEnPractica (5), supportTicketCategory (6), supportTicketStatus (10). All 55 active rows retain ownerAppKey NULL. No per-category question remains. A future need to diverge requires ADDING app-specific rows plus scoped readers and a stated reason; never backfill or reassign an existing shared row. Existing UI inventory is source-bounded, not proof of absent consumers. No DML on this row.
• db-terra-ca descriptionChanged · 1w ago
  was: SELECT-only census, shared project eprpywqwzsvrjeaforei, 2026-10-06: public.lookupOptions has ownerAppKey NULL in 8 categories / 55 active undeleted rows: accessIssueReason 2, antecedenteGrupo 6, appEventCategory 17, correctionRequestStatus 4, documentoType 5, rolEnPractica 5, supportTicketCategory 6, supportTicketStatus 10. PM FINAL muws03pfbezr: NO BACKFILL of ownerAppKey on any of these 55 rows. NULL is the deliberate shared case in the live predicate (ownerAppKey IS NULL OR ownerAppKey = appKeyArg). Filling it would silently narrow access for the other tenant and may return a clean invalidReason rather than an error. The measured NULL scope is correct design, not missing data. Rendering a label in only one app today does not establish exclusive ownership. If a genuinely single-tenant category is later needed, create a second app-specific row after owner review; never reassign an existing shared row. Source-bounded consumer census: both apps render documentoType labels and consume accessIssueReason codes; Terra renders rolEnPractica labels; Enamel renders supportTicketCategory and supportTicketStatus labels; Terra queue prints raw status rather than these labels. No current UI label rendering found for appEventCategory, antecedenteGrupo or correctionRequestStatus. These observations do not narrow the shared-row contract. No DML or label edit was run.
• db-terra-ca verified · 1w ago
  PM muws3cse4x7j: row already CLOSED; no Enamel intent confirmation is pending and no ownerAppKey write is authorized. Enamel SOURCE ONLY: app/src/app/solicitar-acceso/actions.ts derives noProfile and inserts accessIssueReports with APP_KEY=enamel while not reading or rendering lookupOptions.label; this consumes the shared VALUE and a reassignment would silently break the predicate path. This is neither Enamel approval nor live UI proof. A CONSUMER OF A SHARED VALUE NEED NOT RENDER ITS LABEL. Ownership census must follow value use in predicates/storage, not label rendering. Any later category divergence is a new row with reason and additive app-specific rows beside the shared rows.