docs: record notificaciones as built, flags global, schedules editable
The docs still described the state before the last five commits: the insurance spec called for a `@Cron` literal and a manual mark-as-sent mutation, PLAN.md had step 12 as "NOT STARTED", and README's module and route lists predated seven modules. - MASS_EMAIL_NOTIFICATIONS.md: new "Send flags", "API surface" and "Scheduled runs" sections; "Cron (future)" removed — it exists. The flags table says which flags apply where, and why a debug renewal send must skip both the RenewalNotice row and `lastSuccessfulAt`. - INSURANCE_FEATURES_SPEC.md: §1 BUILT note listing the three places the build diverged from the spec; §1.1 and §1.4 marked superseded in place rather than deleted, so the reasoning stays readable. - PLAN.md: step 12 renewal emails DONE with the divergences; status paragraph rewritten. - README.md: current module/route lists, plus a "Scheduled jobs" section — a reader cloning this repo had no way to know the API sends mail on a timer. - DEPLOY_AND_MIGRATIONS.md: the cadence lives in app_settings and survives an image rollback, and the servicios sweep has no multi-replica lock. - RESUME.md: session record for the whole notificaciones arc. - RENEWAL_NOTICES.md: pointer that this is the legacy record, not what shipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -40,8 +40,13 @@ docker-compose.yml mysql + api + web
|
||||
```
|
||||
|
||||
API feature modules: `auth`, `users`, `customers`, `policies`, `properties`,
|
||||
`billing`, `bank`. Web routes: `/clientes`, `/polizas`, `/servicios`,
|
||||
`/estado-cuenta`, `/banco` (chequera), `/catalogos`, `/usuarios`, `/login`.
|
||||
`billing`, `bank`, `reports`, `notifications`, `renewals`, `mail`, `statements`,
|
||||
`policy-ocr`, `ocr`, `storage`, `settings`, `ops`.
|
||||
|
||||
Web routes: `/inicio`, `/clientes`, `/polizas`, `/servicios`, `/estado-cuenta`,
|
||||
`/banco` (chequera), `/recibos` (OCR capture), `/notificaciones` (mass email +
|
||||
renewal avisos; `/renovaciones` is an alias onto its Pólizas tab), `/reportes`,
|
||||
`/catalogos`, `/operaciones` (DB ingest/backup, ADMIN), `/usuarios`, `/login`.
|
||||
|
||||
---
|
||||
|
||||
@@ -195,6 +200,28 @@ python migration/run_all.py
|
||||
|
||||
---
|
||||
|
||||
## Scheduled jobs
|
||||
|
||||
The API runs two automatic email sweeps. Neither cadence is in the source:
|
||||
both are stored in `app_settings` and edited at `/notificaciones` →
|
||||
"Programación de envíos" (ADMIN, `setting:manage`), taking effect immediately
|
||||
without a restart. Shipped defaults:
|
||||
|
||||
| Job | Default | What it does |
|
||||
| --- | ------- | ------------ |
|
||||
| Pólizas | **on**, 06:00 daily (America/Tijuana) | Renewal avisos at 30/15 days before expiry and 7 days after. |
|
||||
| Servicios | **off** | All four mass-email jobs in order, same as "Ejecutar todos". |
|
||||
|
||||
A scheduled run never uses the UI's send flags — in particular it ignores
|
||||
`debug`, so a forgotten test toggle cannot silently stop customer mail. Full
|
||||
detail in [`docs/MASS_EMAIL_NOTIFICATIONS.md`](docs/MASS_EMAIL_NOTIFICATIONS.md).
|
||||
|
||||
Sending needs `SES_*` in the environment. Without it the API still boots and
|
||||
logs mail to stdout in dev; in production every send fails loudly and is
|
||||
recorded as `FAILED` rather than quietly going nowhere.
|
||||
|
||||
---
|
||||
|
||||
## Production notes
|
||||
|
||||
- Use `pnpm --filter @jorgecuadros/database exec prisma migrate deploy` if/when
|
||||
|
||||
Reference in New Issue
Block a user