Weekly KPI/report email quality: stop noisy+wrong sends (recipients with no practicas or all-zero KPIs; some users get 4+ emails) — mars+venus+pluto
Elazar 2026-07-19: read the Monday-morning mars emails, they are 'horrible' — sends docentes the names of people who have no practicas assigned, or 0 on all KPIs, and some users get over 4 email messages. Clean up the weekly report/KPI email CONTENT + recipient selection on all 3 apps (venus confirmed sends them; pluto has practicas-kpi-report cron; mars send-weekly-kpi cron). Symptoms to fix: (1) suppress sends to recipients with no assigned practicas / all-zero KPIs (no-signal = no email), (2) collapse the 4+-emails-per-user duplication into one digest, (3) review what each weekly email actually contains vs what's useful. Investigate current cron+recipient logic per app first (mars send-weekly-kpi jobid, venus, pluto practicas-kpi-report), then per-app fix children. Related: MARS-347 (cron liveness), MARS-102 (ux-pain digest transport), PLUTO-45/520.
Questions
Activity
-
Elazar 2026-07-20: patient-DB centralization + DNI autocomplete is ENAMEL's lane. Enamel becomes the central hub for user authentication + patient info storage; the centralized patient DB lives there. Route to pm-enamel-cc; NOT a per-app mars/pluto/venus umbrella. Existing MARS-331/PLUTO-437 become per-app CONSUMERS of the future enamel-hosted store.
-
pm-enamel-cc
-
none
-
CORRECTION 2026-07-20 (pmmaster): the prior 'patient-DB -> enamel' note + pm-enamel-cc assignment on THIS item were a mis-file by me. EVO-72 is WEEKLY KPI/REPORT EMAIL QUALITY (item a), unrelated to patient-DB. Patient-DB centralization is item (f) = MARS-331 + PLUTO-437, now routed to enamel's lane separately. EVO-72 stays with the email-quality lane (mars+venus+pluto), unassigned pending scheduling.