Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send notifications ahead of time #160

Open
8 tasks
emteknetnz opened this issue Mar 7, 2022 · 1 comment
Open
8 tasks

Send notifications ahead of time #160

emteknetnz opened this issue Mar 7, 2022 · 1 comment

Comments

@emteknetnz
Copy link
Member

emteknetnz commented Mar 7, 2022

Currently the module will only send notification emails when the current date is beyond the review by date. Add functionality to also send emails ahead of time. Allow disabling the 'past a certain time' emails.

ACs

  • Add global settings of when to send ahead of time emails (60 days, 30 days, 7 days before the review date). Can use checkboxes for this, though may choose to do something else e.g. comma separated values in a textfield. If we decide we want this more configurable, it will complicate UX, possibly we'd want to make this developer configurable only
  • Retain existing behavior of sending emails when past the due date, though also add global setting to turn this off
  • Default settings is to retain the existing behavior of only sending emails when the page has past the content review date
  • Create default template for this email (similar to ContentReviewEmail.ss)
  • Create a configurable private static to allow overriding this (similar to private static $content_review_template)
  • Create a new HTMLText field for the editing the content of the email sent when for "x days until due email is sent out" separate from the existing field. Refer to this issue.
  • Unit tests probably aren't required as module currently has none
  • Ditto module documentation
@maxime-rainville
Copy link

I would start by having the intervals for the reminder be set up via private static config first. I would not make that part configurable in the CMS directly. If the chosen approach allows it to be made configurable in the CMS later, that's a plus but not essential.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants