Email subscriptions

[davidread]

Page to allow users to unsubscribe from emails.

[rossjones]

for ckanext-issues.

[rossjones]

Perhaps by providing a link they can visit from the email they receive. The page would turn off issues notifications and tell them that it has done so (using a unique key to identify the user).

As well as doing this, we need to store the user preference somewhere, and currently we don't have anywhere to store it.

Some options:

• Modify CKAN users to have a new field (similar to the one about activity_email_notifications and use that from issues - a more general dont_email_me flag.
• Implement the long talked about user_extras so ckanext-issues can store the information in there as issues-notifications: False

Do you have a preference @davidread ?

[davidread]

Sounds great to have a special link users can avoid having to log-in to changes these options.

I think it would be useful to offer different sorts of subscriptions. It might list:

• issues for selected publishers (selection widget)
• issues for publishers that I am editor/admin for
• issues for all publishers

user_extras is tempting, but could be controversial how it's done. A core user field would be ok if we can get it into core ckan. Another option would be to have a separate table with all these email settings, which would allow you to do a query like 'which users need emailing now dataset X has changed', whereas that would be hard if you had to scan all the JSON blobs in a users' extra field.

[rossjones]

I think getting a new field into core would be difficult, extras less so, but obviously it's a lot more work.

I think perhaps a new table for issues and default to on, if a user changes their preference we'll add an entry. That way the table will only contain users who have expressed an interest.

[davidread]

How about the table would save deviations from defaults, but the 'defaults' could be configurable, with a default-default value too. That'd allow us to turn things on and off for the majority, which is the main use case I think.

On 5 October 2015 at 18:02, Ross Jones notifications@github.com wrote:

I think getting a new field into core would be difficult, extras less so, but obviously it's a lot more work.

I think perhaps a new table for issues and default to on, if a user changes their preference we'll add an entry. That way the table will only contain users who have expressed an interest.

— Reply to this email directly or view it on GitHub https://github.com/datagovuk/ckanext-dgu/issues/175#issuecomment-145599357 .

[rossjones]

The next problem is that it only appears to ever email publishers, never the originator of an issue or comment. This makes 'only from these publishers', or 'all publishers' feel strange.

Issues should email users. At which point these settings make sense.

[davidread]

Github has a concepts of "watching" and "participating" which we might also use.

Based on: https://github.com/settings/notifications and https://github.com/watching

[x] Participating - When you participate in an issue conversation.
[x] Watching - Updates to any issues for any publishers or datasets you’re watching.
    Currently watching: 
        Cabinet Office [x]         [Unwatch all] [Add new]
        Department for Education [x]
        Fuel prices [x]
        [> show all]
    Automatic watching:
        [x] If you're made an admin or editor automatically watch the publisher and any sub-publishers
        [ ] If you're made an admin or editor automatically watch the publisher
        [ ] All datasets

How something about that? Or can we simplify?

[davidread]

maybe we can use ckan's existing 'following' infrastructure instead of calling it 'watching'.

[rossjones]

So I think this changes our model a little as now what we're saying is that we will only send notifications to users that are following, but users will have control over whether they are automatically following something (they can however unfollow specific publishers). This makes sense to me.

Rather than have an option where you can only view your 'automatic follow settings', perhaps we should also include on that page all of the ones you currently follow (like you suggest) so that we can easily remove them.

[davidread]

Great, we are singing from the same hymn sheet

[rossjones]

So far this has involved making sure we can follow publishers, and that it redirects back to referrer. So now users should be able to follow a publisher, the problem is likely to come when they can't follow issues for a specific issue, or they can follow a publisher but can't mute a specific issue.

So I think following publishers is the wrong approach. We should be doing the following on issues themselves. This way when we create an issue, we can auto-create follows based on a user's preference.

So, short version.

• Preferences say which organisations they want to auto-follow issues for.
• Follows are on an issue by issue basis
• When an issue is created, we will find all the users who are a) following this publisher, or b) have expressed an interest in this publisher's issues (via prefs) and create the follow.
• When a notification is due to be sent, we can just get all users who follow the issue.

This needs either a fix in core so that follows can be of anything, or a re-implementation in issues. The actual end result will be a mix because we don't want core to stop us implementing am_following_issue in our extension.

[davidread]

the problem is likely to come when they can't follow issues for a specific issue, or they can follow a publisher but can't mute a specific issue.

I agree, you should be able to follow an issue (under a publisher that you don't follow) or unfollow and issue (under a publisher that you do follow). Github allows exactly this for issues for datasets. We provide a button on the issue to make the change, and record each.

However (and I think you get this, but just to be clear) when a user follows a publisher it makes no sense to store a list of all its issues and record that the user is following those too. That is just implicit knowledge, worked out when the email is sent or the issue is displayed to the user.

[rossjones]

The problem with the implicit knowledge is that we then have to store the unfollows if the user 'mutes' an issue. There are though, likely to be a lot less of those than the other way around - so it might be a good approach to take. Will try that ...

[davidread]

Yep, you got it!

[davidread]

Call Drupal API to ask it to send the email (so that it can do weekly digest if necessary)