feat: Digest email lines for request notifications - EXO-89486_EXO-89487 - eXIP7.3.0.22 - #493
Merged
Merged
Conversation
…- eXIP7.3.0.22 One Kernel line plugin declared next to the digest category: the email line of each digest notification type is built at send time from the stored ids, a vanished object gives no line. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
eXIP 7.3.0.22 Digest Mail Notifications — US06 "Daily digest email content" / US07 weekly (EXO-89486): the email lines of the notification types this addon owns. Spec: Tribe note 50469 §4 Assembly. Depends on the SPI of Meeds-io/commons#775 (
DigestLinePlugin), to be merged first.What it does
ProcessesDigestLinePluginforCreateRequestPluginandRequestCommentPlugin:New request: "{title}" ({process})and{actor} commented on your request "{title}", linking to the request / its comments.REQUEST_ID, set by the two listeners) — the digest keeps ids only and reads the request fresh at send time.ProcessesService.getWorkById(long workId): an id-only read for the platform (the per-user read only returns the requests the user created, and a new request is announced to the managers).NotificationUtils.getRequestCommentsLinknow returns aString.The line plugin is a Kernel plugin declared in XML next to the digest category (
addLineProvideronDigestCategoryRegistry): at send time commons asks it for one line per waiting item, built fresh from the stored ids; a vanished object gives no line and is not counted. Wordings are text-only keys with{i}placeholders in the plugin's own notification bundle, the arguments are escaped by commons.Self-review close-out (one independent round over the five addon branches + commons)
getWorkById(recipient, id)returns null for managers, so no "New request" line could ever be builtgetRequestCommentsLinkreturnedObjectStringVerified conform: parameter names match the keys the notification plugins store; the services are looked up lazily from the Kernel on the job thread; links are built without an HTTP request; each key lives in the bundle declared as the plugin's
bundlePath; the XML block sits in the existingDigestCategoryRegistrytarget; wordings equal the board text.Classification: N2 (addon plugin over an existing SPI; the two notification plugins and listeners gain an additive
REQUEST_IDargument).Knowledge: none — the domain doc fragments of this lot (digest line plugin per addon) are drafted with the last PR of the lot.
🤖 Generated with Claude Code