okay, so here's my situation: a registered user can get notifications for a POST or TYPE of post (content type) - and it catches creation and comments (but not updates/edits per config options), this is standard "notifications module" stuff (which includes comments, though not technically replies to your reply stuff)

this means that if i'm registered than i can subscribe to a post, get updates when comments are posted - although they may not be related to my own reply

BUT if i allow registered users to access "comment notify" and also "notifications" there is a very strong chance that they may click on "subscribe to this post" and also enter a comment and click "notify me of followups to (all replies/my own reply etc)" - it seems intuitive, but there is a strong chance that users will not get the difference and will simply do both - click when viewing, then comment and click again and then start seeing what looks and feels "mostly" like duplicate emails - unsure of which one should be unsubscribed to remedy the dupes...

as a result, what this module would benefit from is a mild rethinking of applications for registered users (for anonymous it is *awesome*)...in particular, i'm thinking:

1) control/limit options displayed to "type of user" - as in, NOT display if notifications/subscriptions are enabled for that content type - or restrict by content type (which puts burden back on user to compare where this module is accessible versus where he may have enabled notifications for that content type - maybe an easiest approach?)

2) become 'notifications aware" as a module - meaning if a user has notifications OR subscriptions modules enabled, this module says so on configuration like "warning, you have X module enabled - this may result in duplicate content and this is why you will not see this module's options appear on content types for which you have (subscriptions/notifications) enabled. please review your configuration"

does this make sense? the followups to my own reply is wonderful, but odds are that 'notifications' is mostly taking care of this for content types for which it is enabled....

right now my only alternative is to ONLY make this available to 'anonymous users' - which kinda makes sense too ;)

Comments

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented
Category: feature » support
Status: Active » Fixed

Thanks for raising this issue. It definitely can be confusing for users to have all of these modules installed/enabled.

I think the simplest thing is to limit comment_notify to anonymous and notifications for authenticated users.

I don't feel that it should be comment_notify's job to understand all the possible configurations of Notifications and Subscriptions modules which could lead to a confusing UI for the end user. That would require a lot of work initially and on an ongoing basis that I'm not interested in doing (which is why I'm switching this to a support request and marking it fixed).

If someone else wanted to create a patch to get this to work with notifications/subscriptions and then get a reviewer to confirm that the patch works I'd be willing to commit it.

zilla’s picture

zilla CreditAttribution: zilla commented

actually, you're right - it's really not your burden, or if anything it's some kind of equal burden on all modules with similar functionality...which makes zero sense in the long haul

instead of a patch, how about adding this paragraph to the project documentation? (including the readme.txt at some level)

Suggested Usage/Typical Scenario for Comment Notify

Comment Notify is currently the simplest way to keep Anonymous users engaged with your website by allowing them to subscribe to comments (all comments or replies to their own comments). This is a popular 'blogging' platform feature that you can see all over the internet when site visitors are allowed to comment without registration but also want to stay on top of an ongoing discussion.

If you currently use NO other content notification/subscription framework (modules or actions/triggers and workflows), then this is an ideal solution for both anonymous or registered users alike. It will keep them engaged in dialogue while keeping site performance lean through integration with the optional Queue Mail module.

Note: If you are currently using a module for registered user notifications, including the Notifications Module or the Subscriptions Module, it makes sense to adjust permissions so that Comment Notify is enabled for only Anonymous Users.

Why? Because unless you are very careful with your configuration, users may wind up accidentally subscribing to "notifications" for a post through Notifications Module at the same time as "notifications" from the Comment Notify module. This could produce what 'feels like' duplicate content from a user perspective when in fact Drupal is just seeing two modules doing their own jobs.

Currently, comment notify is an "all or nothing" utility for comments across all Content types within an installation. As a result, it will be quite tricky to manipulate settings for either the Subscriptions or Notifications modules to reduce the likelihood of duplicate content appearing before users (again, what "feels like' duplicate content is in fact what Drupal is seeing as two different modules doing two different things).

...sorry, it's a bit wordy, but you get the idea ;)

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented
Category: support » task
Status: Fixed » Active

That is a bit wordy;)

is an "all or nothing" utility for comments across all Content types

That's also not true - see admin/settings/comment_notify where you can limit this.

How about this:

COMPATIBILITY NOTE
------------------------
Comment Notify is not built to work on sites where other mail related modules are installed (modules like Actions, Notify, Subscriptions, and Organic Groups are popular examples). If you install both Comment Notify and one of these other mail modules on your site in addition to Comment Notify it may send duplicate messages and/or have user interface elements that will appear to be duplicates and confuse your site visitors.

The suggested configuration in these instances is to separate Comment Notify and whatever other mail module you have installed. Common ways to separate them are by content type or user permissions.

zilla’s picture

zilla CreditAttribution: zilla commented

i hear you, and maybe even just add, "....please refer to individual module documentation for other modules to explore the best configuration for your own site" (i am wordy, damn..)

the only thing to be careful with is that where you say it 'may send duplicate messages' it sounds like you could be talking about some kind of error or problem, that was why i made that original comment about "what feels like duplicate content,but is in fact two modules doing their own jobs (to send the same stuff)"

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented
Title: what is required to have this live peacefully alongside 'notifications' - please consider » provide advice to have this live peacefully alongside 'notifications' - please consider
Version: 7.x-1.x-dev » 5.x-2.x-dev
Status: Active » Patch (to be ported)

Committed this to 6.x.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented
Status: Patch (to be ported) » Closed (fixed)

This module is no longer actively developed for Drupal 5. If someone wishes to take over as the 5.x maintainer I would consider it, but these days everyone should really upgrade to Drupal 6.x.