[Aging Content - Banner] Drupal: Implement Full Width Banner Aging Content Notification Emails MVP

[jilladams]

Background

Now that the components are all in place. We are free to create our first MVP for Aging Content notifications.

Description

To provide timely information to Veterans and other users of VA.gov, and ensure banners are replaced and/or monitored, we need to implement the ability for the notification system to send notification emails based on a cadence specific to particular content types.

Full-Width banners will only display for seven (7) days, and notifications will be sent three days before the 7th day (telling them they need to edit to add a note that it is still needed, or archive the banner by the seventh day), then the morning of the 7th day (telling them they need to either edit to add a note that the banner is still needed, or archive).

To accomplish this, we will need to:

• Create a "ExpirableContent" interface for all content entities. It will help form the foundation for other content types, blocks, and any content entity to have an expiration date. The interface will allow content entities to opt into having an expiration, and contain methods for retrieving and setting the expiration date(s) for a given content entity.
• Add a field (computed, likely) that calculates the expiration date of the FWB. Expiration for FWB occurs 7 days after the editor last saves a published FWB. This field then will provide a token value that can be used in Message templates.
• Create the "expiring" Message Template. The "expired" Message Template exists, but we need to create another for expiring.
• Create a new ECA Model for triggering the "expiring" notifications.
• Document the framework
• Write tests

ACs

Beta Give feedback

1. "Expired" email message is sent daily to all editors of published, expired FWB nodes.
2. "Expiring" email message is sent daily to all editors of published, expiring FWB nodes.
3. Recipient for both email notification types is the current node revision author (the user who last saved the node), rather than the original node author.
4. The framework can accept a list of allowed recipients, such that the notifications can be delivered to hand-picked users only, allowing for a staged roll out.

Text for Emails

Day 4 Email

Subject: Please update or archive your Full-width banner by [Day 7 Date]

Please plan to archive, or edit to extend display of, your published Full-width banner titled [content title / link] by [Day 7 Date].

As a reminder, Full-width banners are to be used for emergencies or actions a veteran needs to take and should display for 7-days, unless there’s a compelling reason to extend display of the content.

If you do need to extend the display of the banner, simply edit with a comment to that effect, and the 7-day countdown window will reset.

For more information, you can read this Knowledge Base article for tips and best practices to manage compliance.

Need help?

If you are a Vet Center Director or Outreach Specialist who needs assistance accessing Drupal CMS, please email the CMS Support Team at support@va-gov.atlassian.net.
If you want to refresh your skills, need ideas, or have questions about creating content for your webpages, you can find How to Guides and Training videos in the Drupal CMS Knowledge Base or drop in during office hours.
If you received this email and no longer have a role at a Vet Center, please inform us by emailing the CMS Support Team at support@va-gov.atlassian.net.
Coming Soon:

Banners will be permanently auto-archived at the end of Day 7, unless edited to reset the 7-day timeframe. We will give ample notice before this functionality is implemented.
Notifications and auto-archiving of Home Page Benefit Promo Blocks
Notifications and auto-archiving of Home Page News Spotlight Blocks

Day 7 Email

Subject: Action Needed: Your Full-width banner has displayed for seven (7) days

Your Full-width banner has displayed for seven days. In order to meet the purpose of this type of content, please plan to archive, or edit to extend display of, your published Full-width banner titled [content title / link] by [date].

As a reminder, Full-width banners are to be used for emergencies or actions a veteran needs to take and should display for 7-days, unless there’s a compelling reason to extend display of the content.

If you do need to extend the display of the banner, simply edit with a comment to that effect, and the 7-day countdown window will reset.

For more information, you can read this Knowledge Base article for tips and best practices to manage compliance.

Need help?

If you are a Vet Center Director or Outreach Specialist who needs assistance accessing Drupal CMS, please email the CMS Support Team at support@va-gov.atlassian.net.
If you want to refresh your skills, need ideas, or have questions about creating content for your webpages, you can find How to Guides and Training videos in the Drupal CMS Knowledge Base or drop in during office hours.
If you received this email and no longer have a role at a Vet Center, please inform us by emailing the CMS Support Team at support@va-gov.atlassian.net.
Coming Soon:

Banners will be permanently auto-archived at the end of Day 7, unless edited to reset the 7-day timeframe. We will give ample notice before this functionality is implemented.
Notifications and auto-archiving of Home Page Benefit Promo Blocks
Notifications and auto-archiving of Home Page News Spotlight Blocks

[FranECross]

@dsasser If you decide you want to split out implementing the actual notification email, I ran across a ticket that Jill created last year that we can use. If not, then I can close this one. Thanks!

[FranECross]

@dsasser I added the text for the two emails to the description.

[dsasser]

@FranECross are we going to limit this MVP rollout to a set of test users? If so, I need the email address of folks that we want to target for the staggered rollout as I'll need to put them into the system. We can also leave the system off (it won't send any emails) until we get those test users, if they aren't available by the time we need to deliver this ticket.

[FranECross]

@dsasser Dave mentioned we would have a set of folks to reach out to. I'll check with him and get back to you; and concur that we can close the ticket and not send emails until we get the info for a bit. Thanks so much! You ROCK!

[jilladams]

Noting: @FranECross @davidconlon if we have updates on the emails of test users, that's outstanding for this ticket.

[dsasser]

Status Update 3/29/24

BLUP: We are adding to the framework a way to configure any content entity type (node, block, taxonomy term, etc) to be "expirable". This is adding to the scope of the original work here, and approximately 5 points will remain for next sprint.

When approaching the idea of making content expire, we knew we wanted to leverage Views, rather than hard-coding queries in code. And it was possible to create a View of expired FWB nodes using a View and no custom code or additional changes were needed. We did this by querying for any FWB who's "last saved by an editor" field was more than 7 days old:

While this functions to get the results from the View, it doesn't expose a value that can be accessed in the Message template directly. For this, we planned to create a computed field which would be attached to the entity. This computed field would leverage a new ExpirableContent interface (PHP code), to calculate the expiration date. Since computed fields are also now exposed as tokens, we planned to use this token in the Message template. Further, we planned to use this computed field in the View as a filter, to get away from the ugliness that is the current query.

Unfortunately, we found out that computed fields cannot be used as Views filters without a serious compromise to performance. So we needed a persistent data storage solution. Diving into building a new field caused us to consider the two aspects of data we are working with:

1. The expiration date and warning dates for single entity (node, block, etc)
2. "Expirable" information for a given content entity type

The field would store the data for 1. and we were looking to use a PHP interface for 2...

Create a "ExpirableContent" interface for all content entities. It will help form the foundation for other content types, blocks, and any content entity to have an expiration date. The interface will allow content entities to opt into having an expiration, and contain methods for retrieving and setting the expiration date(s) for a given content entity...

We saw this as an opportunity to improve on the expirable interface by making it configurable in the Drupal UI, rather than by having them do so in code.

We now have a way to define any content entity as "expirable" in the UI:

[jilladams]

Ok - noting: we need to review the new fields ^ with @thejordanwood for labeling / helptext, if that hasn't happened already. Smart to do that before we're committed to machine names, if possible.

[FranECross]

Ok - noting: we need to review the new fields ^ with @thejordanwood for labeling / helptext, if that hasn't happened already. Smart to do that before we're committed to machine names, if possible.

Ticket for Jordan created #17691

[jilladams]

Mid-sprint: light yellow partially bc we need to review with CMS team, and finalize moving parts.

[dsasser]

Status Update 4/11/24

I met with the Platform CMS team and they have signed off on the "expirable content" module approach.

One of the things Edmund asked I do is to make the module public on Drupal.org so we could start getting community feedback sooner than later. I have done this, so now the new approach is a community-provided module rather than a "custom" one. Any future changes that need to be made to the expirable_content module will be made against this new public project.

Now that the expirable content work is complete (insofar as we are aware), I'm moving into the final phase of this issue which is primarily configuring the ECA rule, View, and Message template for the warning message. Next I'll fold in some documentation and testing.

[dsasser]

Status update 4/16/24

Now that the Expirable content module is "complete" (there are always maintenance and bug fixes to be expected over time), the ECA rule, View, and Message templates have been configured. This completes the base configuration and setup necessary to start testing the end-to-end solution, which I have started doing.

There are a number of bugs/final tasks that I'm sorting through currently, including:

• Duplicate messages are sent in some cases
• ECA is reporting a recursive error of some kind that I haven't delved into
• Cut a new alpha of the Expirable content module (some bugs were fixed in the Views integration)
• provide a way to "seed" the initial expiration and warning dates FWBs
• Warning notification is using the wrong template

All that said, I think it is important to note that we have built both a functional notification framework, as well as an expirable content framework, and these are working together in concert to be able to deliver messages like this:

Additional screenshots:

[FranECross]

Thanks, @dsasser! Great accomplishments!

[dsasser]

Mid-Sprint update 4/24/24

I have completed the bulk of the work for this issue, including fixing these bugs noted previously.

✅ Duplicate messages are sent in some cases
✅ ECA is reporting a recursive error of some kind that I haven't delved into
✅ Cut a new alpha of the Expirable content module (some bugs were fixed in the Views integration)
✅ provide a way to "seed" the initial expiration and warning dates FWBs
✅ Warning notification is using the wrong template

This means that we have effectively built all the functionality required for this MVP.

What remains:

• Fixing failing phpunit tests. This should be a quick fix providing the problem is what I'm thinking.
• Folding in the UX changes to the Expirable Content config form. A small-ish amount of work.

Additional tasks:

• Tests
• Documentation

I don't see either of these as ACs for the MVP, however, so @FranECross let me know if you have any specific thoughts on wether we should be cutting tickets for those tasks (or linking them here if we have already done so and I couldn't find them).

Also I think now is a good time to start thinking about manual QA, release plan, and PR review heft.

[FranECross]

@dsasser Thanks for this update and all your hard work!

• Re Tests & Documentation: I thought I had tickets for tests and documentation, but don't see them. I'll get those created first thing Thursday morning (4/25).
• I'll create a Release Plan ticket
• I can help with manual QA

Question: Were you going to also create a demo video, and would you like me to create a ticket for that too?

[FranECross]

@dsasser Thanks for the review, and here's PM sign-off! Woot! 🎉

[jilladams]

End of sprint:

• Fixing failing phpunit tests. This should be a quick fix providing the problem is what I'm thinking.
• Folding in the UX changes to the Expirable Content config form. A small-ish amount of work. -- [UX] Provide verbiage for fields in Drupal Aging Content Developer Configuration UI #17691. Need a Drupal ticket to implement the changes.
• Tests ticket created - [Aging Content] Write unit tests for the notifications framework (& full-width alert/banner if applicable) #18005
• Documentation ticket created - [Aging Content] Draft or edit existing Architectural document  #18007
• PR final review & merge - VACMS-15506 aging content fwb mvp with expirable content module #17732
• Test matrix document - Fran intends to create, not ticketed, won't block closing this ticket.

[FranECross]

New ticket created for the item in comment above (shown below): #18019

• Folding in the UX changes to the Expirable Content config form. A small-ish amount of work. -- [UX] Provide verbiage for fields in Drupal Aging Content Developer Configuration UI #17691. Need a Drupal ticket to implement the changes.

[dsasser]

Merged!

[dsasser]

Verified changes are in prod: