The organic groups module currently handles its own email notifications. However having the subscription module and organic groups running side-by-side is not satisfactory because users can get notifications for the same content from both modules. The way forward is to write a plug-in for the subscription module that handles the organic groups notifications.

Developers who would like to work on this and would appreciate a small amount of sponsorship can contact me via my contact form.

The corresponding issue in the OG issue tracker is at http://drupal.org/node/197658

Comments

salvis’s picture

salvis
he/his
CreditAttribution: salvis commented

Thanks!

I believe this would have to remain a project of its own (with someone dedicated to supporting it for the long term), so that the two modules can evolve independently.

gustav’s picture

gustav CreditAttribution: gustav commented

Yes, I would be happy to be its long-term maintainer or co-maintainer. However, until the plugin module is released and has its own issue queue, I think this thread would be the best place to discuss it.

salvis’s picture

salvis
he/his
CreditAttribution: salvis commented

Sure, you're welcome to use this thread (or even a few more).

miglius’s picture

miglius CreditAttribution: miglius commented

Currently the subscription module is contained in one file and there is no easy way to write plug-ins with other types of subscriptions. Here http://drupal.org/node/212994 I propose refactoring of the subscription module in a way that various plug-ins could be written without altering of the original code.

gustav’s picture

gustav CreditAttribution: gustav commented

miglius: thank you for your interest. The subscription module has recently been refactored in the way you propose. Please take a look at the 5.x-2.0-beta9 release at http://drupal.org/node/211816. The organic groups plug-in will indeed be written as a separate module and will not require code changes in the core subscription modules.

miglius’s picture

miglius CreditAttribution: miglius commented

Nice, will look at 5.x-2.0-beta9 release more deeply. Thanks.

gustav’s picture

gustav CreditAttribution: gustav commented

Good news: develCuy has agreed to work on the organic groups subscriptions plug-in.

The plug-in will allow users to subscribe to content type by group in the same way in which one can already subscribe to content type by author. This raises an interface issue. Currently the user's subscription administration page (user/1/subscriptions/type) has a column called "Author". I guess we could add another column called "Group" to that table. However, given the fact that you can subscribe to content type only either by author or by group, for each subscription only one of the columns will have content. So it would be more sensible to have a single column. This would also be more scalable when other subscription modules want to do something similar. The big question is: is the subscriptions module API powerful enough to allow this?

The organic groups subscriptions plug-in will also allow users to subscribe to all posts to a particular group. So it should also have a tab on the user admin screen for showing all those subscriptions. This page should probably look similar to user/1/subscriptions/type but without the author column. There is no problem there, I think.

salvis’s picture

salvis
he/his
CreditAttribution: salvis commented

Good, and I see you already have a project at http://drupal.org/project/subscriptions_og.

Adding a subpage to user/1/subscriptions is certainly fine and should be easy. Look at subscriptions_blog_ui.module for an example. Adding to the node form as well as inserting into the queue should be fine, too.

Contributing additional rows into the user/1/subscriptions/type table is an interesting idea, but I don't think we've foreseen that direction of extension. To quote chx on whether it's feasible in the current model: we're "unsure." However, he said, he'd help you if needed.

That table is created in subscriptions_content_type_form(): first it retrieves the existing subscriptions, which can have an author_uid or -1. Then it retrieves the content types and creates additional (inactive) subscriptions for those content types that don't already have a non-author-specific (-1) row. Finally, it uses subscriptions_form_helper() to convert those subscriptions into table rows (and turn the author_uids into author names).

You could hook_form_alter, or you could replace subscriptions_content_page_type() and wrap subscriptions_content_type_form(), to insert your rows into the table. This is probably doable, but not easy. Getting your rows back out on submit might be a little harder.

The {subscriptions} records are filtered with WHERE s.module = 'node' AND s.field = 'type'. I don't see a good, scalable way to piggy-back on those keys, so you probably have to go for your own module name.

gustav’s picture

gustav CreditAttribution: gustav commented

Many thanks for this very helpful and detailed reply. It will help to implement such a "content type in group" subscription in the future. I decided that the initial version of the subscriptions_og plugin will provide only the basic "Subscribe to this group" functionality, no subscription by content type.

develCuy and I are in the early stages of coming up with the specifications for version 1.0 of the new module. We hope to post something here later today.

gustav’s picture

gustav CreditAttribution: gustav commented

We now have a specification for the og plugin module at http://develcuy.elblog.de/subscriptions_og/. I would like to encourage everyone to make comments.

rconstantine’s picture

rconstantine CreditAttribution: rconstantine commented

About the spec:

On the first page it says:

Users do not have to be a member of a group to subscribe to notifications for that group.

I am wondering if this will take into account

  • whether the post is public or not
  • what type of group it is - ex. closed, open, etc.

    • It seems to me that some combinations of the above two items should not allow nodes to be sent to non-group members.

    On the user interface page:

    The node section describes a fieldset with potentially a gazillion items in it. I would prefer a jquery tabbed popup. The tabs would be one per plugin - OG for one, Taxonomy for another, plus one for the main stuff, etc. Perhaps it could degrade into the cluttered version.

    I love the option presented in 'Membership List' and the one to set a default for new subscribers. I have several sites that need some groups to default to notifications and other groups to default no notifications.

    The rest on that page is great too.

    On the admin interface page:

    Everything seems fine and I can't think of anything to add.

    On the general considerations page:

    seems reasonable

gustav’s picture

gustav CreditAttribution: gustav commented

rconstantine, many thanks for your thoughts about the features.

Regarding the feature to allow users to subscribe to notifications from groups that they are not a member in: these notifications of course only include nodes that are visible to the user anyway. The philosophy is that if the user can see a particular post on the site then there is no reason why the user should not be allowed to get an email about it as well.

The importance of making sure the user can not get a notification about a node that they are not allowed to see is explicitly stated as a point on the General Considerations page of the specifications. Part of the project is to test this rigorously.

I share your concern about the long list of subscription options that the subscriptions module would show to the user on a node page when the admin enables all the options. I think that the best solution to that is to give the admin the ability to limit which subscription types show up on every node page. For example I think that the option of subscribing to a user's blog does not need to be shown on every post in the blog, it is enough if it is shown on the user's main blog page. Similarly the ability to subscribe to a taxonomy term could be moved to that term's listings page. The subscriptions_og module already follows that new philosophy by providing a "Subscribe to this group" link on the group home page so that the admin can safely turn it off on all the individual nodes from that group.

Converting the "Subscribe" fieldset into a popup is a great idea. However this is not something the subscriptions_og plugin needs to be concerned about, it is something the subscriptions_ui module could do.

salvis’s picture

salvis
he/his
CreditAttribution: salvis commented
Version: 5.x-2.0-beta9 » 5.x-2.0
Status: Active » Fixed

Congratulations for the Organic Groups Subscriptions release! I hope your issue with the release management will be cleaned up soon.

@gustav/develCuy: Please check the front page and let me know if there's something wrong/missing/whatever with my references to your numerous contributions.

Thank you for your support!

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.