Bug 3922 - Allow for opt-in/out status updates/notifications
Allow for opt-in/out status updates/notifications
Status: RESOLVED FIXED
Product: OJS
Classification: Unclassified
Component: Framework
2.3
PC Mac OS X 10.0
: P1 enhancement
Assigned To: PKP Support
: 1684 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-08 22:22 PST by James MacGregor
Modified: 2012-09-21 17:35 PDT (History)
1 user (show)

See Also:
Version Reported In:
Also Affects:


Attachments
Patch against PKP-lib pre-2.3. CVS (73.96 KB, patch)
2009-01-20 18:26 PST, Matthew Crider
Details | Diff
Patch against OJS pre-2.3 CVS (45.90 KB, patch)
2009-01-20 18:27 PST, Matthew Crider
Details | Diff
Images for PKP pre-2.3 CVS (49.60 KB, application/x-gzip)
2009-01-20 18:28 PST, Matthew Crider
Details
Images for PKP-lib pre-2.3 CVS (76.57 KB, patch)
2009-01-21 10:32 PST, Matthew Crider
Details | Diff
screenshot (145.36 KB, image/png)
2009-01-22 15:58 PST, James MacGregor
Details
Patch against OJS pre-2.3 CVS (87.25 KB, patch)
2009-01-26 11:43 PST, Matthew Crider
Details | Diff
Patch against PKP pre-2.3 CVS (24.76 KB, patch)
2009-01-26 11:43 PST, Matthew Crider
Details | Diff
Images for PKP pre-2.3 CVS (53.42 KB, application/x-gzip)
2009-01-26 11:45 PST, Matthew Crider
Details
Patch against PKP pre-2.3. CVS (63.77 KB, patch)
2009-01-26 13:03 PST, Matthew Crider
Details | Diff
Patch against OJS pre-2.3 CVS (88.53 KB, patch)
2009-01-28 11:47 PST, Matthew Crider
Details | Diff
Patch against PKP pre-2.3 CVS (55.13 KB, patch)
2009-01-28 11:48 PST, Matthew Crider
Details | Diff
Patch against OJS pre-2.3 CVS (78.63 KB, patch)
2009-01-28 16:16 PST, Matthew Crider
Details | Diff
Patch against OJS/OCS pre-2.3 CVS (1.25 KB, patch)
2009-03-25 12:08 PDT, Matthew Crider
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James MacGregor 2008-12-08 22:22:43 PST
This would build on the already-existing Prepared Email function, as well as the User Profile's New Issue Published email notifications. 

There are currently a certain set of functions in OJS that, when executed, can trigger an automatic notification email, such as submission of an article or registration with the site; etc. To extend automatic notifications, I would suggest the following: 

1) extending the notification trigger to all functions that require possible follow-up action, such as the uploading of a revised Author version of an article (at any time); the adding of a comment to one's published article; etc. These would be similar to Facebook notifications in that they would cover any action of note. 

2) Similarly to Facebook notifications, they should also be optional on a per-user basis. This could be controlled from the User Profile page, similarly to the New Issue Published email notifications, only on a larger scale, and possibly deserving of their own sub-page. 

I can go into more detail, with more action cases, if this sounds worth pursuing. Wordpress and phpBB also provide interesting notification options, especially with respect to thread/post comments, worth examining.
Comment 1 Matthew Crider 2008-12-12 15:19:09 PST
I'll add some notes here to keep all related notification ideas together:

-There should be a page that aggregates all notifications together in chronological order.  Clicking on a notification will take you that part of the system.

-This page would make a good candidate for a personalized RSS feed for each user (in lieu of or in addition to emails).  There may be some concerns about security however (I'm no expert with creating dynamic RSS feeds, but I know its possible to password protect feeds).

-When in a part of a system that requires attention, allow for highlighting of the specific subsection of the page (using jQuery), e.g. by highlighting the subsection or collapsing other parts of the page (I'd prefer the former, as collapsing the other parts of the page might be confusing).
Comment 2 Alec Smecher 2009-01-06 09:34:25 PST
*** Bug 1684 has been marked as a duplicate of this bug. ***
Comment 3 James MacGregor 2009-01-14 11:27:38 PST
One more note, courtesy of http://www.gavinbaker.com/2008/12/31/how-to-improve-ojs-a-readers-perspective/ and ensuing conversation with John. 

There should be an option for non-registered visitors to be able to give their email to receive notifications of new content. The idea would be to allow users to enter their email address only to be signed up to a mailing list. They would then receive email every time an Editor sends the Notify Users email (notification of new content); and possibly also whenever an announcement was posted. This should be an an optional item, and managed under Journal Setup Step 4.1. Some notes: 

- Visitors should be able to sign up for notification regardless of whether content is subscription protected; or regardless of whether registration is needed to view content;

- Should be a quick process, ie., an email field and that's it;

- Gavin's suggestion on using this as a soft-sell approach to encourage future registration/subscription should be implemented, ie. possibly have a blurb attached to the confirmation page or email, such as: "Thanks for signing up for the mailing list! If you would like to register as a reader, author or reviewer, please complete the registration form available at {url}. If you would like to subscribe for access to restricted content, see {url}."

- Should be implemented as a block, if possible. Visitors should be able to choose quickly between signing up for a mailing list; registering as a user; or subscribing. John has suggested the following layout: 

For free notification of
new journal content, 
simply enter your email: 
[                    ] [Register] 
Want to also _review_? 
Or _submit_ an article?
_Subscribe_ to protected content (would not appear if subscription disabled)
_Privacy protection policy_ [SMALLER FONT]

-- Another variation on the above: having a simple block link ("Register/Subscribe") that would lead to an interstitial page with the above options? Also, consider changing the behaviour of clicking the "Register" link on the top navigation bar to do this. 
Comment 4 James MacGregor 2009-01-14 11:39:37 PST
One more comment: Gavin's note regarding openID makes a further case for openID support: users not needing actual authorization, but who may want to register with the site anyway, should be able to sign up with their openID credentials (if the support was developed and enabled). Of course, it'd be nice to be able to take that information and elevate them to a full user with appropriate authorizations, but that's contingent on how we refactor our authentication schemes. 
Comment 5 Matthew Crider 2009-01-14 12:06:34 PST
Well, I'm almost done with the notification system (at least a rough copy, i'm hoping to get some input from others on it once its completed).  Currently, notifications only appear for registered users.  I could easily implement it so there is a public notification feed, so information such as new issues/announcements would show up in the public feed, which in turn can be subscribed to via RSS.

However, allowing people to subscribe to this via email would need some thought WRT how to best implement it, i.e. what if people don't want to be on the mailing list anymore?  I suppose one way would be to have the user input their email in a form and it will email them a link that when followed would delete the user from the mailing list.
Comment 6 Matthew Crider 2009-01-20 18:26:27 PST
Created attachment 1347 [details]
Patch against PKP-lib pre-2.3. CVS

Suggestions greatly appreciated!  The notification types (i.e. what actions to take to trigger a notification) are in the notification settings page, which is accessed via the descriptive paragraph in the notifications page (which is accessed from the navbar within a journal's context).
Comment 7 Matthew Crider 2009-01-20 18:27:01 PST
Created attachment 1348 [details]
Patch against OJS pre-2.3 CVS
Comment 8 Matthew Crider 2009-01-20 18:28:40 PST
Created attachment 1349 [details]
Images for PKP pre-2.3 CVS

These images and icons go in the PKP WAL.  Note that i've abstracted all icons out of OJS (and will do the same for the other apps) and all icons are now in PNG format.
Comment 9 Alec Smecher 2009-01-21 08:59:54 PST
Matt, the schema doesn't appear to be included here.
Comment 10 Matthew Crider 2009-01-21 10:32:15 PST
Created attachment 1350 [details]
Images for PKP-lib pre-2.3 CVS

Not sure why the schema wasn't included...
Comment 11 Michael Felczak 2009-01-22 09:04:26 PST
(In reply to comment #8)
> Created an attachment (id=1349) [details]
> Images for PKP pre-2.3 CVS
> 
> These images and icons go in the PKP WAL.  Note that i've abstracted all icons
> out of OJS (and will do the same for the other apps) and all icons are now in
> PNG format.

Matt, PNG transparency is not handled well by IE6 for Windows, which still includes many users out there. See for example Bug #3360.

There are hacks around this, e.g. http://24ways.org/2007/supersleight-transparent-png-in-ie6

I guess it depends on how many hacks we want to add to deal with IE6 oddities. We have a few already, but this one is a little more complicated and has its own issues (i.e. "Pitfalls" in the above).
Comment 12 Alec Smecher 2009-01-22 09:25:55 PST
My fault -- I asked Matt to convert over to PNG, forgetting the alpha issue. Matt, rather than fiddling with a work-around, let's just stick with GIF until the IE6 marketshare falls to a point we can be happy with (which will be pretty low, given our developing-world emphasis).
Comment 13 James MacGregor 2009-01-22 15:57:00 PST
Matt, looks great! Some issues and suggestions: 

1) Clicking on the rss2 feed returns the following errors: 

Warning: Invalid argument supplied for foreach() in /Users/jmacgreg/cvs/pkp/classes/core/PKPRequest.inc.php on line 676

Warning: Cannot modify header information - headers already sent by (output started at /Users/jmacgreg/cvs/pkp/classes/core/PKPRequest.inc.php:676) in /Users/jmacgreg/cvs/pkp/classes/core/PKPRequest.inc.php on line 31

... actually, that only happened once, and is not replicating for any feed at all now. 

2) Some locale keys seem to be blocked or nonrendered. I'll attach a screenshot in a sec. Clearing data/template cache produces no effect. 

3) Would suggest editing "Unchecking an item will prevent notifications of the event from showing up in your notification feed ..." to include a mention of emails: "... or from an email being sent to your email address."

4) For "Also send me an email for these types of notifications", take out the "Also" -- it can be an either/or. 

5) I'm not sold on the Notifications link being added to the top nav bar. It seems to be awfully prominent for something that a) will probably only be configured once; b) accessible quickly via emails/rss links. 

6) Add an option for notifications regarding new Announcements (probably filed in Other Events). 

7) Are these notification options viewable depending on the user's role? For example, if I'm logged in as an author only, I still have the option to receive notifications if a reviewer form review comes in, or if a new article has been submitted ... I should be seeing these if I'm a JM or editor, but to an author they may be confusing. Maybe they could be left viewable, but rendered unclickable and/or shaded if  the user doesn't have the appropriate role? 


8) I wonder if there's a better way to group these. I would suggest something like 

Submission 
- Author can register whether they want submission conf. notices
- Editor can register whether they want new submission notices
Review
- Editor can register for  Reviewer comments notification
Editing
- Editor, Author, copy/proof/layout dudes can register for comment notification
Site
- Article Comment Notification
- New Issue Notification
- Announcement Notification

And possibly even grouping them further under each section by role. I'm guessing visibility could at this point probably be handled nicely by JQuery, or by shading out irrelevant options as in point 7. 
Comment 14 James MacGregor 2009-01-22 15:58:13 PST
Created attachment 1351 [details]
screenshot

Screenshot to complement point 2) in above comment.
Comment 15 Matthew Crider 2009-01-22 16:17:05 PST
Thanks James.  Some comments:

> 3) Would suggest editing "Unchecking an item will prevent notifications of the
> event from showing up in your notification feed ..." to include a mention of
> emails: "... or from an email being sent to your email address."
> 
> 4) For "Also send me an email for these types of notifications", take out the
> "Also" -- it can be an either/or. 

These two suggestions are a bit contradictory in regard to how its currently set up.  Currently, the two settings are not mutually exclusive--The user must have the first checkbox checked (allow the notification to show up in the feed) for them to also receive email notifications.  So, either implement suggestion 3 and keep the functionality as is, or implement suggestion 4 and allow feed notifications (i.e. through the notification page or RSS) and email notifications to be mutually exclusive.  Your call, boss.

 
> 5) I'm not sold on the Notifications link being added to the top nav bar. It
> seems to be awfully prominent for something that a) will probably only be
> configured once; b) accessible quickly via emails/rss links. 

Sure, I just threw it in there to have somewhere to access notifications (I didn't put too much thought into it).  I'm not against it being there, but it might be a good candidate for a simple block plugin that shows a link to the feed page and the amount of read/unread notifications.  I'm open to other ideas.

> 7) Are these notification options viewable depending on the user's role? For
> example, if I'm logged in as an author only, I still have the option to receive
> notifications if a reviewer form review comes in, or if a new article has been
> submitted ... I should be seeing these if I'm a JM or editor, but to an author
> they may be confusing. Maybe they could be left viewable, but rendered
> unclickable and/or shaded if  the user doesn't have the appropriate role? 

The settings do not discriminate based on role, but if you're an author you'll never receive messages about e.g. new article submissions.  I could grey out irrelevant settings just to keep users from getting confused--good idea.
Comment 16 James MacGregor 2009-01-22 19:09:18 PST
Hi Matt, additional comments below: 

(In reply to comment #15)
> Thanks James.  Some comments:
> 
> > 3) Would suggest editing "Unchecking an item will prevent notifications of the
> > event from showing up in your notification feed ..." to include a mention of
> > emails: "... or from an email being sent to your email address."
> > 
> > 4) For "Also send me an email for these types of notifications", take out the
> > "Also" -- it can be an either/or. 
> 
> These two suggestions are a bit contradictory in regard to how its currently
> set up.  Currently, the two settings are not mutually exclusive--The user must
> have the first checkbox checked (allow the notification to show up in the feed)
> for them to also receive email notifications.  So, either implement suggestion
> 3 and keep the functionality as is, or implement suggestion 4 and allow feed
> notifications (i.e. through the notification page or RSS) and email
> notifications to be mutually exclusive.  Your call, boss.

OK, I would suggest having this be an either/or situtation -- some folks like RSS vs. email and vice versa, presumably. One possibility would be to have the delivery method selection separate from the notification selection -- that is, a user could choose to have no notifications delivered (possibly the default?); all notifications delivered by RSS; delivery by email; or delivery by both; and then could choose from a list of receivable notifications. 

> 
> 
> > 5) I'm not sold on the Notifications link being added to the top nav bar. It
> > seems to be awfully prominent for something that a) will probably only be
> > configured once; b) accessible quickly via emails/rss links. 
> 
> Sure, I just threw it in there to have somewhere to access notifications (I
> didn't put too much thought into it).  I'm not against it being there, but it
> might be a good candidate for a simple block plugin that shows a link to the
> feed page and the amount of read/unread notifications.  I'm open to other
> ideas.

How about adding this as a list item in the User Profile block, having it appear between "My Profile" and "Log Out"; and also linked to from the User Home, between "Edit My Profile" and "Change My Password"? I think the feature is cool and relevant enough to get prominent placement in these areas; but I still don't think it belongs in the topmost navigation bar. 

Additionally (and similar to what you did for Bug 3797, and also to how editorial queues are listed in the sidebar when viewing Editor-specific pages), it'd be great to have the number of unseen notifications listed next to the Notifications text, too. 
> 
> > 7) Are these notification options viewable depending on the user's role? For
> > example, if I'm logged in as an author only, I still have the option to receive
> > notifications if a reviewer form review comes in, or if a new article has been
> > submitted ... I should be seeing these if I'm a JM or editor, but to an author
> > they may be confusing. Maybe they could be left viewable, but rendered
> > unclickable and/or shaded if  the user doesn't have the appropriate role? 
> 
> The settings do not discriminate based on role, but if you're an author you'll
> never receive messages about e.g. new article submissions.  I could grey out
> irrelevant settings just to keep users from getting confused--good idea.
> 

Sounds good to me! 

Matt, I haven't yet tested the actual notification process itself -- I haven't sent myself notifications, seen what kind of information they contained, etc. I'll take a look tonight and tomorrow, and may come back with some suggestions, or other issues if I find them. One other thing we'll have to keep in mind too is to remove now-obsolete functionality -- the "New Issue Published Email Notifications" option at the bottom of the User Profile page, for example -- but this is looking great so far. 
Comment 17 Matthew Crider 2009-01-26 11:43:11 PST
Created attachment 1354 [details]
Patch against OJS pre-2.3 CVS

Updated patches with bugfixes and feature additions.
Comment 18 Matthew Crider 2009-01-26 11:43:52 PST
Created attachment 1355 [details]
Patch against PKP pre-2.3 CVS
Comment 19 Matthew Crider 2009-01-26 11:45:02 PST
Created attachment 1356 [details]
Images for PKP pre-2.3 CVS
Comment 20 Matthew Crider 2009-01-26 13:03:43 PST
Created attachment 1357 [details]
Patch against PKP pre-2.3. CVS

Previous patch was botched when uploaded.
Comment 21 Matthew Crider 2009-01-28 11:47:12 PST
Created attachment 1368 [details]
Patch against OJS pre-2.3 CVS

Another round of patches, including suggestions from James (i.e. a notification block plugin) and pagination for the notification web feed.
Comment 22 Matthew Crider 2009-01-28 11:48:24 PST
Created attachment 1369 [details]
Patch against PKP pre-2.3 CVS
Comment 23 Matthew Crider 2009-01-28 16:16:01 PST
Created attachment 1371 [details]
Patch against OJS pre-2.3 CVS

Some files were missing from the patch.
Comment 24 Matthew Crider 2009-03-18 15:01:38 PDT
Implemented.  Note that this requires a DB upgrade after patching--And its a healthy chunk of changes, so keep an eye out for bugs everyone!
Comment 25 Matthew Crider 2009-03-25 10:04:29 PDT
I forgot to commit the new icons into the WAL--I'll have to wait until I get to my home computer next week, since I modified some of the icons and removed unnecessary ones.
Comment 26 Matthew Crider 2009-03-25 12:08:40 PDT
Created attachment 1620 [details]
Patch against OJS/OCS pre-2.3 CVS

The notification block plugin was being loaded on install, causing installation to fail with a DB connection error.  This has been fixed in CVS.
Comment 27 Matthew Crider 2009-04-02 08:55:59 PDT
Icons committed.
Comment 28 Matthew Crider 2012-09-21 17:35:02 PDT
Added upgrade code for old notificiation_status table; Removed NotificationStatusDAO
https://github.com/pkp/ojs/commit/683ff963f653a4312594f4c437e5424501d4ff32
Comment 29 Matthew Crider 2012-09-21 17:35:02 PDT
Removed NotificationStatusDAO
https://github.com/pkp/ocs/commit/4b02daf293a30796d7352ee59303255cf62bac0a
Comment 30 Matthew Crider 2012-09-21 17:35:02 PDT
Added upgrade code for old notificiation_status table; Removed NotificationStatusDAO
https://github.com/pkp/ojs/commit/4070a37f1a5128160a5e0ff1cc603727b6d2af1b