4 Commits

Include renames

Author	SHA1	Message	Date
rmancinasandClaude Opus 5	89611da202	feat(notificaciones): global send flags + editable schedules ... The "Flags del envío" panel lived inside the Servicios tab and only governed the four bulk jobs. The pólizas half had no debug at all, so there was no way to test a renewal notice without mailing a real customer. The panel now lives in the /notificaciones shell above the tabs and both halves read it. `debug` on the renewal path diverts to the same override inbox as the servicios jobs and deliberately does NOT write the `RenewalNotice` row or advance the sweep's `lastSuccessfulAt` — the customer was not notified, so nothing may gate the letter they are still owed. `ignoreDayRestriction` and `useEmailLimit` stay estado-de-cuenta-only and are labelled as such. Both automatic sweeps are now operator-editable. The renewal cadence was a `@Cron("0 6 * * *")` literal and servicios had no automatic run at all; both now resolve through `NotificationScheduleService`, which stores the cadence in `app_settings` and reinstalls the cron job on save — no redeploy, no restart. Defaults preserve current behaviour: pólizas 06:00 daily, servicios off. A scheduled run never inherits the UI flags; it always sends for real. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 12:23:19 -07:00
rmancinasandClaude Opus 5	33833c3af9	feat(notificaciones): one send log across servicios and pólizas ... Renewal avisos left behind only a `RenewalNotice` row, whose sole job is gating: a row with `sentAt` drops the policy off the pending list. It cannot represent a failed send or a customer with no address, so the Pólizas tab had no "Registro de envíos" to show and a sent notice simply vanished from the list. Renewals now write `email_notification_log` — the same table the four bulk jobs write — as `RENEWAL_NOTICE` / `POLICIES`, with rows for failures and no-email skips too. `RenewalNotice` keeps its gating role unchanged; the two are complementary, not redundant. - extend `EmailNotificationType` (+RENEWAL_NOTICE) and `EmailNotificationServicio` (+POLICIES); `level` now carries the aviso generation on renewal rows, so every reader must branch on the type first (`notificationLevelLabel()` is the one place that lives) - backfill emailed notices (`channel = 'EMAIL'`) into the log; MAIL-channel rows are legacy printed letters and are deliberately left out - extract `NotificationLogService`/`NotificationLogModule` as the single writer, so a feature that sends mail records it without pulling the bulk-job pipelines into its module - `GET /notifications/log` and `/stats` take a comma-separated `servicio` list; each tab reads its own slice. This also fixes the "Omitidos" view, which mapped to no filter at all and showed every row - share one `NotificationLogPanel` between both tabs - pass SES_* / NOTIFICATION_ADMIN_EMAILS through the galactus compose, which was missing them entirely — mail is runtime config, not a CI secret, and the prod image sets NODE_ENV=production so a blank config fails loudly instead of falling back to stdout Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 03:01:03 -07:00
rmancinas	c0cc0d2ac2	feat(renovaciones): send renewal notices from the list, drop manual marking ... The Pólizas tab now sends. Each pending row gets an "Enviar aviso" button backed by POST /renewals/send, which renders, mails and records the notice through the same path the daily sweep uses — so a hand-sent letter is marked exactly like a swept one and drops off the pending list. Sending is now the only way a notice gets marked as sent. Remove the manual "Marcar impreso" / "Marcar EMAIL" buttons and the endpoint behind them (POST /policies/:id/renewal-notices, PoliciesService.markRenewalNotice, MarkRenewalNoticeDto): they wrote a sentAt with no mail behind it, which let the list claim a customer was notified when nothing was sent. sendOne refuses a generation that already has a sentAt (409) so a double click cannot mail the customer twice, and 400s when the customer has no email on file. Sweep and single send share the new deliver() helper.	2026-08-02 02:40:38 -07:00
rmancinasandClaude Opus 5	0332292ae9	fix(notificaciones): merge renewals into one screen, fix MailModule DI ... MailModule's provider used a `useFactory` with no `inject`, so the factory received `undefined` and `new MailService(config)` threw on `config.get`, taking the whole API down at boot. The module also wasn't actually `@Global()` even though both NotificationsModule and RenewalsModule inject MailService without importing it — that would have failed next. Replaced the factory with a plain provider (ConfigModule is already `isGlobal`) and marked the module global. On the web side, mass email and renewal notices were two menu entries doing the same job — telling a customer something by email. They are now two tabs of `/notificaciones` (Servicios and Pólizas), following the Captura pattern: `/renovaciones` still resolves, opening the same screen on its Pólizas tab so existing bookmarks keep working. The notifications page was also the last screen written in raw inline styles, with blue buttons and filter pills that appear nowhere else in the app. It now uses the shared design system: btn-primary/btn-outline, the seg segmented control, card, tx-table, pager, and the servicios/fideicomiso badges. Two supporting fixes found on the way: NOTIFICATION_STATUS_COLORS hardcoded hex instead of the theme's positive/negative/muted vars, and `.small` was referenced in 19 places across the app but never defined in globals.css. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 02:21:51 -07:00