feat: Digest sender job, safety cleanup and email assembly - EXO-89539_EXO-89982_EXO-89486_EXO-89487_EXO-90020 - eXIP7.3.0.22

[azayati]

eXIP 7.3.0.22 Digest Mail Notifications — US08 "Digest sending schedule and coverage" (EXO-89539), with the email assembly shared by US06 (daily) and US07 (weekly). Spec: Tribe note 50469, §4 Scheduling / Assembly / Data.

What it does

• One hourly job (DigestSenderJob, cron exo.notification.digest.job.expression, default 0 0 * * * ?), glue only, run on its own thread, one run at a time. It never stops: the admin switch OFF stops only the email production, the claims, watermarks, deletions and cleanup go on (settled decision, spec §4 Admin switch).
• Run (DigestSender): safety cleanup (orphans + retention exo.notification.digest.retention.days, default 8) → indexed candidates → exact "due now?" in the user's timezone (DigestDueCalculator: daily.hour 18, weekly.day FRIDAY; at most one per local day / week, catch-up after a missed run, first digest the day after opt-in, no double email around a timezone change) → claim by guarded watermark UPDATE (the cross-node protection) → email → mail queue → deletion of the items covered by every enabled frequency. The two frequencies of one user are served in sequence by one task. A failure after the claim gives the occurrence back.
• Email (DigestMailBuilder + DigestMail.gtmpl): categories of the frequency only (second half of the double check), display order, cap daily.cap 5 / weekly.cap 10 with "+ N more →", subject / greeting / intro / footer links per the board texts, everything escaped, translations text-only with {i} placeholders (platform convention). Zero lines ⇒ no email, the watermark still moves.
• SPI for the addons: DigestLinePlugin (Kernel plugin declared in XML next to the category, addLineProvider on DigestCategoryRegistry) builds one DigestLine (label key + args + link) from the stored ids; a vanished object gives no line and is not counted. The five addon PRs (social, content, task, agenda, processes) follow.
• Capture side: ITEM_DATE is now the capture moment; PARAMS shrinks longest-value-first instead of being dropped.

Tests

93 digest tests green in commons-component-common, including DigestUserDAOTest and DigestItemDAOTest (the hand-written JPQL run on HSQLDB through the kernel persistence unit), DigestDueCalculatorTest (15 calendar scenarios incl. the spec's timezone edge cases), DigestMailBuilderTest (renders the real template), DigestSenderTest, DigestSenderJobTest.

Self-review close-out (3 independent rounds + refute pass)

Round	Findings	Status
1	🔴 daily sent at midnight after an opt-in before 18:00 · 🟠 release equality vs MySQL TIMESTAMP rounding · 🟠 daily/weekly race on one user · 🟠 unreadable template cached as empty · 🟠 PARAMS dropped above 2000 · 🟡 MessageFormat vs {i} · 🟡 JPQL not engine-run · 🟡 spec drifts · 🟡 duplicate label resolver · 🟢 nits	all fixed (the red one mutation-verified) except 2 accepted: spec drifts → resync list; label resolver duplicate → social PR switches to the commons bean
2	🟠 late asynchronous capture row deleted unread · 🟡 pin not discriminating · 🟡 run blocking the shared scheduler thread · 🟡 null line argument · 🟢 placeholder re-expansion · 🟢 log noise	all fixed
3	🟡 job glue untested · 🟢 huge placeholder index · 🟢 flag stuck at shutdown · 🟢 ITEM_DATE wording	all fixed; nothing open

Verified conform by the reviewers: job = glue calling the Service layer with a property cron; Service → Storage → DAO layering, constructor injection; every hand-written JPQL executed by the engine; admin-OFF semantics as settled; double check of categories; caps, counts and never-send-empty; escaping of every value put in the HTML; war: template resolution from commons-extension-webapp; mail queue contract (pluginId "digest", sender/recipient from the existing helpers).

Accepted trade-offs for the approver: no platform "one node only" job guard exists (spec assumption A2 is false) — the watermark claim is the protection; claim (Spring tx) and queueing (Kernel tx) are two transactions, release compensates; derived-name Spring Data queries are validated at the social webapp start, not in this suite.

Spec resync to propose before merge (note 50469 §4): first digest the day after opt-in; ITEM_DATE = capture moment; cleanup = orphans + retention (the category step is redundant by construction); no MailTemplateContentTransformerService pass (links absolute, escaping upstream); line providers as a second Kernel plugin; PARAMS shrinks longest-first; A2 false.

Classification: N1 (core notification path, new DAO surface and plugin SPI in commons, mass email). Human approval required, author ≠ approver.

Knowledge: none — the commons domain doc fragment (digest engine, DigestLinePlugin SPI) is drafted with the last PR of this lot, once the five addon PRs have landed the same SPI.

🤖 Generated with Claude Code

[azayati]

Addon PRs implementing the DigestLinePlugin SPI of this PR (merge this one first): Meeds-io/social#6072, Meeds-io/content#911, Meeds-io/task#642, exoplatform/agenda#1107, exoplatform/processes#493. One independent review round was run over the five together with this branch; nothing open.

[azayati]

Added (EXO-89982, from Ayoub's test of an account deletion): a user whose digest settings are gone (both frequencies read off while his work list row still exists — the settings are purged with the account) is forgotten by the job at his next occurrence: the NTF_DIGEST_USERS row and every NTF_DIGEST_ITEMS row of the user are deleted, nothing is built. No listener, no separate PR: it is part of the cleanup mechanism of the job. Tests: DigestSenderTest.testUserWhoseSettingsAreGoneIsForgotten, DigestQueriesEngineTest.testForgettingAUserDeletesAllHisItemsOnly.

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 New Critical Issues (required ≤ 0)
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE