Closed (fixed)
Project:
Group Subscription
Version:
2.0.x-dev
Component:
Code
Priority:
Major
Category:
Feature request
Assigned:
Reporter:
Created:
12 Feb 2020 at 21:36 UTC
Updated:
29 Jun 2021 at 21:53 UTC
Jump to comment: Most recent
Currently the module only tracks activity for node and comment creation. If edits are made to a node those edits are only accounted for in the event the email notifications haven't already gone out. If notifications have been processed and sent, users are never notified of the changes.
Similarly if a node is initially created as unpublished and then published later it is never included in email notifications.
Last but not least, due to the provided option to exclude certain group content nodes from group subscriptions (a process where a record is added to the group_subscription_held database table) and the fact edits are not tracked there is no way to release a hold on a piece of content. The main role the hold plays is to be sure comments for the held node are not sent.
We need a way to release the hold on nodes when they are edited and add them to the subscription queue, a way to add them to the queue if they are published, and a way to remove holds in the event the settings for that particular type of group content change from optional to always send.
Comments
Comment #2
jaydarnellComment #3
jaydarnellWe need an elegant solution which can handle a few potential scenarios:
- A group content node was unpublished but is changed to published
- A group content node was originally published with subscriptions suppressed but is changed to no longer suppress subscriptions
- An old piece of group content is revised (provide a mechanism to allow for the updates to be processed as a new subscription notification)
We need to also think about permissions. We should probably give users with appropriate permissions the ability to determine exactly how we want this to function. The most straight forward way may be to modify the node edit form with a fieldset (displayed only to users with appropriate permissions) to determine when subscriptions should be sent (and provide a configurable default for cases where we don't want certain group roles to be able to control this).
We may also want to integrate this with our tracking efforts to show when subscriptions for a given piece of content were processed and sent. It could be helpful for a group administrator editing old content to know when the previous subscription notifications for the item were processed and sent.
Comment #4
artatac commentedHow about if the option to conditionally exclude particular nodes on creation, always showed but it’s state changed on save (eg showed as unticked) see screenshot. Then you always have the option of ticking it again and that tick tells SG to send a notification out (again). Just a thought. I can imagine a time where it is so important eg event date on original article was wrong and thus you have to create another new article to let people know about original article :-(
Comment #5
jaydarnellComment #6
jaydarnellartatac, just an FYI: this functionality has been prioritized on my current project so I'll be starting on this enhancement in a week or two.
Comment #7
jaydarnellA little later than expected artatac but I'm starting on this now.
Comment #8
jaydarnellThe way I've tackled this for now may not be the ultimate solution. I have some mixed feelings about the path I took for this but we'll see how it goes and I'll adjust in a future release if necessary. The module is still in alpha so we can pivot again if needed before the first stable release.
For this first pass I've added code for announcement and group content updates. If an announcement or group content node was unpublished but freshly moved to published status the item will be added to the subscription queue for processing.
The holds functionality is still in place (optionally) and I'm not truly satisfied with how it works right now but it does work. Holds override everything so published or not, if the item has a hold on it no subscriptions will be sent. You can remove a hold on a group content node during a node edit (again only if the optional permissions have been set) but that won't be enough to actually requeue it. The only way to requeue someone is to unpublish and republish it.
Again I don't really love this solution but to make a long story short I ran into some technical hurdles I didn't expect and ran out of steam before hitting the level of quality I wanted for this enhancement.
Comment #10
jaydarnellMarking this as done and will create a follow up issue to make this better.
Comment #11
jaydarnellComment #12
jaydarnell