Email Table of Contents: plugin done, please check and test

I have finally sat down, and after a few months, have managed to construct a plugin to send an HTML table of contents by email to all registered users, not a notification.

So far, it is still basic: i need to do some settings, and a preview pane. It uses the ISSUE::published Hook, so the user needs to do nothing special except publish the issue.

It also obeys the ‘send notification’ checkbox, so if this is unchecked, no email is sent. If checked, it will send the eTOC rather than the notification.

It uses a Smarty template, so it would be customizable.

Here it is: GitHub - stefesciberras/ojs-plugin-emailTOC: OJS 3 Plugin to send electronic Table of Contents to users upon publication of issue

Some things I still need to sort:

  1. I wish i knew how to nest the smarty templates, using include file=… However, I cannot figure out the proper nomenclature to use
  2. I will try to add a preview button to the Publish Issue modal, which would open a second window, not initialized by OJS, as would appear in an email window.
    I will need to learn how to add an action however…

Comments are more than welcome!

Stephen

2 Likes

Nice work @ssciberras!

I wish i knew how to nest the smarty templates, using include file=… However, I cannot figure out the proper nomenclature to use

I found this example from the DOI plugin which may be useful:

{assign var=templatePath value=$pubIdPlugin->getTemplatePath()}
{include file="`$templatePath`urnAssignCheckBox.tpl" pubId=$pubId pubObjectType=$pubObjectType}

I will try to add a preview button to the Publish Issue modal, which would open a second window, not initialized by OJS, as would appear in an email window.
I will need to learn how to add an action however…

Take a look at the Navigation Menu Item form. It has a preview button for custom pages.

A couple other things you might want to consider:

  1. Users can opt out of receiving email notifications for new issues in their profile. But your code will send to all users regardless of their settings. Check out NotificationSubscriptionSettingsDAO and NotificationSettingsForm for a way to check a user’s setting for NOTIFICATION_TYPE_PUBLISHED_ISSUE before sending the email out.
  2. You might want to record that an email has been sent for an issue in the issue settings table. It is possible to publish an issue, unpublish it, and republish it. A user error, of course, but in such cases you may want to avoid sending the email twice. Just something to consider.

Many thanks!

I will look into these shortly

It is a pleasure to give something back to the community: I had seen a number of ppl were asking for this feature. Once it is polished, is there somewhere I can submit it for general use, for people to actually find it?

Stephen

Mostly just here. The Plugin Gallery in OJS is run off an XML file that we edit with new entries. When you feel like you’re ready for that, let us know and we can guide you through some steps to polish it off and get it ready for entry.

Hi @ssciberras,

Is this plugin ready for production use yet? It looks very useful!

Thanks,
Amanda Stevens
Public Knowledge Project Team

I have been using it, it still needs some twekaing, but I have too many things to do.

How can I post it, for people to use and improve?

Step[hen

We loved the idea behind this and wrote a plugin which translates some of this work into more native OJS framework assumptions:

This ultimately should move towards being included in core: specifically, assigning the issue id as the associated id of the notification, so that the hook NotificationManager::getNotificationMessage can actually make use of the issue data.

2 Likes

This looks great and solves the exact problem I’m facing! Is this plugin still the recommended means of achieving this result in OJS v3.3? I don’t find this plugin in the Plugin Gallery there and was wondering if this functionality has been incorporated into the main application somehow.

The Pitt ULS is currently working on updating each of our plugins for compatibility with 3.3 and later.

Support in the core product for this functionality without a plugin is scheduled for 3.5:

So, I anticipate supporting this plugin for 3.3. and 3.4.

Thanks a lot for clarifying. I’ve currently just extracted the plugin directory into the plugins/generic directory of my OJS 3.3 installation, and it appears to be working okay.