Pkp-lib: Announcement notification email should include the announcement content

[ajnyga]

This is a place holder for a soon to come pull request.

[ajnyga]

@NateWr, here is the first candidate

ojs: https://github.com/pkp/ojs/pull/2384
lib: https://github.com/pkp/pkp-lib/pull/4747

[NateWr]

Thanks @ajnyga! I'm going to have to dig in a bit here because I'm not that familiar with our notifications handling. I'll put it on my todo list for next week.

[ajnyga]

Thanks, no rush I think. The plugin I made should cover this for anyone wanting the feature, so this can be moved to 3.2.

[israelcefrin]

Just using this issue as placeholder for existing request.

Describe the problem you would like to solve
I would like to embed the announcement content into notification email message body. Currently, this notification has only a link to the website announcement detail page. On that note, embed the announcement lead into email subject also.

Describe the solution you'd like
A check-box saying for "include content in the email body" on announcement editing modal/form. And a specific template for this notification to customize even with journal logo. The current template is used by "new submission" message to editors.

Who is asking for this feature?
Journal editor would like to send the content along the link for the website.

Additional information
It is a request that has came as a side effect from an issue of empty email messages: #5094

[ctgraham]

@ajnyga ,

The plugin I made should cover this for anyone wanting the feature,

Does this refer to the PRs linked above, or to an independent plugin?

[ajnyga]

https://github.com/ajnyga/announcementEmail

[ctgraham]

Nice! Thanks!

I think I would prefer to see this implemented as a new template, so that a themer has more control of the formatting and content. If that sounds reasonable, I'd like to propose a PR where PKPNotificationManager::getNotificationMessage() fetches a template and passes $announcement rather than hardcoding the <br />'s around fixed content. I'd PR it here and the plugin, I think.

[ctgraham]

Second thought: @israelcefrin, what is the real value of making this optional? If optionalizing it is important, if we leave this as a plugin, the Manager has the opportunity to select whether they want the generic text or actual content on a journal-by-journal (or press-by-press) basis. Is there value in optionalizing this for every Announcement? I suspect not, but you may have other feedback.

[ctgraham]

Here is a draft of my template proposal:
https://github.com/ajnyga/announcementEmail/pull/1

This diverges from our current practice of storing all of our existing email structure/content as locale strings rather than templates, but I think using a template here provides a clear way for isolating the presentation from the code.

[israelcefrin]

Second thought: @israelcefrin, what is the real value of making this optional? If optionalizing it is important, if we leave this as a plugin, the Manager has the opportunity to select whether they want the generic text or actual content on a journal-by-journal (or press-by-press) basis. Is there value in optionalizing this for every Announcement? I suspect not, but you may have other feedback.

Hi @ctgraham, as long this embedding content into body being applied to announcements only I don't foresee issues making it as a plugin rather than a checkbox for every announcement.
In fact, announcements are only showing a link, and they tend to have more content text than an ordinary notification of "new submission".

[NateWr]

The following PRs add a new email template and use that when an announcement is sent. The email uses the announcement details in the subject of the email and the body:

Subject: {$title}
Body:
{$title}
{$summary}

Visit our website to read the full announcement.

It respects the opt-out setting in the user profile. And journal managers can customize the template to include the full announcement (use {$announcement}).

I take your point, @ctgraham, that making emails like this into a template would be a nice improvement. However, knowing that emails are in for some heavy refactoring over 3.3/3.4, I'd like to keep this email consistent with others in order to minimize the pain during refactoring.

In the meantime, you can modify the template under Settings > Workflow > Emails > Email Templates. And if you want access to the raw HTML, you can use the textEditorExtras plugin to add a code control to that editor.

PRs:
https://github.com/pkp/pkp-lib/pull/5910
https://github.com/pkp/ojs/pull/2768
https://github.com/pkp/ops/pull/30
https://github.com/pkp/omp/pull/821

[NateWr]

Merged for 3.2.1.

@amandastevens and @kaitlinnewson this adds a new email template in 3.2.1 for announcements. The template key is ANNOUNCEMENT and you will find a description and the default subject/body here: https://github.com/pkp/ojs/pull/2768/files#diff-040a96c2acc4dd1f5328de0cea2b8bd4. This should be added to the list of email templates in the docs hub.

[amandastevens]

Thank you for adding this feature! Will this new template be used when a notification is sent for a new issue published as well?

[NateWr]

No, we would need different language and a different link. Please feel free to recommend some language in a new issue. We'll be doing lots of work on emails in 3.3/3.4 so now is a good time to file recommendations.

[ctgraham]

In the near term, for sending the TOC with published issues, we recently wrote a plugin to embed this. It needs a functional review, but should be nearly good to go:
https://github.com/ulsdevteam/pkp-emailIssueToc

[NateWr]

Filed as an enhancement here: https://github.com/pkp/pkp-lib/issues/5953