More control over "Do not send notifications for this update"

The idea/s sound nice, so if you want to work on it, go ahead. However, let's make a difference:

Send/do not send:
- Nice for this module,
- It could use better wording: If the default is 'send', the checkbox should be 'Do not send notifications for this'. The opposite, should be 'Send notifications for this'. In both cases we'd have an unchecked checbox by default. Does this make sense?

Important updates:
- This would make a nice add on module, to be tried first in this package, http://drupal.org/project/notifications_extra
- Why not configurable levels of importance? If you can configure the text, we could use it for anything with the same work (Regular/Important/Critical, or Small/Big, etc, etc...)
The idea in any case I think would be to have a non persistent per-update value users can subscribe to.

Note: new features only for 4.x branch.

thank you, this was the quick fix i needed

I couldn't agree more with this change.

I tried making a module to try and alter the default, but was unable to figure out why it didn't work. I suspect it is because of the execution weight of the module. I also tried the hook_after_build() function but that didn't work either. I'll keep trying to find another workaround and post a solution. In the meantime, it would be really helpful if a variable could be added, like I tried to add in the module below, so it would be possible to override the setting, e.g. '#default_value' => variable_get('notifications_skip_updates_by_default', 1)

In our use case, our posts are edited an average of 15 times, but only pushed out via notifications two or three times. I had to disable updates until I could resolve this problem, because the 10 authors on the site kept accidentally sending them out.

I could easily hack the checkbox checked in jquery, but that seems like a dirty solution, and I think it still sends out updates when edited by someone who doesn't have the "skip sending notification updates" permission.

I'm sure there's a more elegant solution. Here's what I tried, but so far I have not been able to get it to work:

<?php
function notifications_skip_updates_form_alter(&$form, &$form_state) {
  if (module_exists('notifications_content')) {
    if (isset($form['type']) && isset($form['#node'])) {
      $types = notifications_content_types(NULL);
      $node = $form['#node'];
      if (notifications_content_type_enabled($node->type) && (empty($node->nid) && notifications_event_enabled('node', 'insert') || !empty($node->nid) && notifications_event_enabled('node', 'update'))) {
        if (user_access('skip notifications')) {
          $form['notifications']['#type'] = 'fieldset';
          $form['notifications']['#title'] = t('Notifications');
          $form['notifications']['#collapsible'] = TRUE;  
          $form['notifications']['notifications_content_disable'] = array(
            '#type'          => 'checkbox',
            '#title'         => t('Do not send notifications for this update.'),
            '#default_value' => variable_get('notifications_skip_updates_by_default', 1),
          );
        }
      }
    }
  }
}
?>

Thanks to your hint about module weights and after_build hook and with some help from here http://drupal.org/node/726282, I was able to change the default value from a module.

It could be a temporary solution while a more generic one is devised.

I suppose you have a module for your customizations.

In that module function "hook_form_alter" put something like this

function hook_form_alter(&$form, $form_state, $form_id) {
      $form['#after_build'][] = 'my_notification_after_build_function';
 // rest of hook_alter .....
}

where 'my_notification_after_build_function' is the name of another function defined like this

 function my_notification_after_build_function($form, &$form_state) {
	if(isset($form['notifications']) && isset($form['notifications']['notifications_content_disable']))
         {
		$form['notifications']['notifications_content_disable']['#value']=TRUE;
	 }
	return $form;
};

this is a bit crude since we do that for EVERY node build, more tests should be done to only do that on edit state and probably only on some form_id with some

case 'node-form':
case 'blog_post_node_form':

but it work and should be a start.

The pitfall for me was that after_build is not a 'proper' general hook but a hook you set on the form and called by the form API.

And of course straight setting the value to "true" means that in case there is an error on the form, I suspect the form will be re-displayed with notifications_content_disable set to TRUE regardless of the value the user set before (when he did an error on the form).
I still think that it is MUCH better to NOT "spam" the world by default than the contrary. ;)

I hope it helps.

I am very interested in this- I didn't see this issue when I posted #804484: Require confirmation before generating notifications. I think beyond just making the default to not send notifications, it's important to know exactly when and to whom notifications will be sent. My idea was to hook into notifications_event with a plug-in module to force all messages to be queued, and then use drupal_set_message to give admins a link to approve outgoing notifications (if any exist).

But I also like the idea of categorizing the type of event (minor, regular, critical, etc...) and allowing users to subscribe to events above a certain threshold.

@Annakan --- yes, this helps enormously. Thanks!

+1

Subscribe.

Actually, following up on #6, notifications_team already sets a message "x users have been notified" when notifications are queued. It seems like it would be almost trivial to add an "undo" link that deletes these pending notifications from the queue. I might request that in notifications_team, or see if I can roll the functionality into a separate module (but I don't have much time ATM)

Subscribing

I'm not much of a PHP programmer or I'd take a shot at this myself.
It would be nice to have control over the default of this on a per-node basis. I'm using Node Gallery and it uses one content type for the gallery and one for the actual picture nodes. When you create a new gallery you can choose not to send updates, but when it creates image nodes, it does so on the back-end so you don't have control. This means that if you upload 100 photos, it sends out 100 update notifications!

The short term option is not to allow people to subscribe to the image node content type, but that's a lot of work to set the defaults on all of the node types, and then remove the subscription from all my users.

Thanks!
-=Delty

The patch offered by GA should include the line:

'#value' => 'checked'

in the array, to indicate the change. The form item, when displayed, will not otherwise let the user know the default has been changed unless the box displays a check mark. To make it a little more flexible, I changed the parameter default instead of hard coding the array, and added a conditional:

function _notifications_content_add_disable_field(&$form, $default=1) {
...
            '#default_value'          => '$default',
            '#value'                      => ($default == 1) ? 'checked' : '',
...
}

Remember that the box must be checked when the form is submitted!

We can then change the logic in notifications_content_form_alter. The logic in the second call to _notifications_content_add_disable_field seems to try to preserve an existing entry. Laudable, but not universal. The following code will preserve the value, if present, and will default to notify users of content additions and not to notify for updates, beginning at line 151 of notifications_content.module.

if (notifications_content_type_enabled($node->type)) && (empty($node->nid) && notifications_event_enabled('node','insert') || !empty($node->nid) && notifications_event_enabled('node','update'))) {
    _notifications_content_add_disable_field($form, (isset($node->notifications_content_disable)) ? $node->notifications_content_disable : !empty($node->nid));
}

Just a note that these changes were made in 6X-2X-dev.

+1 for this issue. I recommend having a site-wide default, as suggested above, but then having each node store a default too.

Suppose the site default is not to send notifications. A new node will have the 'do not send notifications' checkbox checked. However, if a user unchecks the box, and saves the node, notifications will be sent. The next time the user edits that same node, the box will still be unchecked, despite the site default.

I don't understand what "Do not send notifications for this update" means. Does it mean that if left unchecked, users will received notifications every time the node is updated? Is there a way to turn this off, since I don't want users getting notified on default.

+1

The fact that automated or bulk node updates trigger notifications is painful.

I started hacking on this issue, and then realized that it was much easier to simply turn off "Node update" in admin/messaging/notifications/events. This works great if you never want to see notifications trigger for node edits.

For posterity, this is what I did:

/**
 * Add disable (skip notifications) field set
 */
function _notifications_content_add_disable_field(&$form, $default = 0) {
  if (user_access('skip notifications')) {
    // Add fieldset without affecting any other elements there
    $form['notifications']['#type'] = 'fieldset';
    $form['notifications']['#title'] = t('Notifications');
    $form['notifications']['#collapsible'] = TRUE;  
    $form['notifications']['notifications_content_disable'] = array(
      '#type'          => 'checkbox',
      '#title'         => t('Do not send notifications for this update.'),
      '#default_value' => $default,
      '#value'         => ($default == 1) ? 'checked' : '',
    );
  }
  else {
    $form['notifications_content_disable'] = array(
      '#type'          => 'hidden',
      '#default_value' => $default,
      '#value'         => ($default == 1) ? 'checked' : '',
    );
  }
}

I added the 'else' clause because users without the ability to skip notifications should get the default setting.

Also added the second change from #13. However, this did not seem to be working for me; the test to decide if notifications should be sent is currently empty($node->notifications_content_disable), seems to be false whenever you put anything in #default_value or #value. Didn't bother to go further than this, just turned off the feature per #17.

If I continued on this, I think that the next thing I would want to do is eliminate the negative from the setting, and change the text from "Do not send notifications for this update" to "Send notifications for this update." This change should be made in notifications, not notifications_extra, because it would not be easy for a module to negate the meaning of the checkbox. Once this change was made, it would be possible to proceed per #2 and put additional enhancements in notifications_extra.

I think #17 is really good enough for my use cases, but that's what I'd do if I wanted selectable notification on edits.

for Version 6.x-2.3 i changed the default-value

and i agree the wording in the UI (and in the code) should be something like:

„send notification“

The solution proposed is simple and ok for nodes that are edited through a user form (and I am using it satisfactory, but this does not address the concern of backend modifications. Disabling notification is of course not a solution, unless Notifications has no purpose for the given site... (Bulk modifications are not really an issue as long as the Webmaster knows what he is doing)
See
http://drupal.org/node/1198634

maybe should be a new issue; but somewhat related to this so thought i would just tack it on here... and in response to greg's comment in #17:

greg is right in that you can enable/disable separate trigger events for notifications for create or update; but this isn't exactly what these do (which is why there is likely a small bug here for those that are really picky (like myself)).

"create" actually means "the first submit with published set", which then overlaps with the incorrect concept that NO edits create a notification if the "update" event is disabled.

to be more clear (although that is likely pretty clear):

with update event disabled and create enabled:

- create a node as unpublished => no notification is fired since notifications first checks that node is published
- edit the node and set as published => a notification is generated (even though update trigger is disabled)

sort of sounds like a bug but pretty much the way this would need to work. likely bug is some sort of explanation of this on the Events config page to explain that create doesnt really mean create and edit doesnt really mean edit.

actually i wasn't exactly correct before, it is worse than i suggest. the "create" trigger is actually "any submit with a transition from unpublished to published", since the module doesn't know the difference between the first and 20th time a node goes from unpub to published.

as our application is what is really meant to be done by this module, which is:

create = notify on FIRST transition to published

meaning we only want to notify the first time the node is published. if it is accidentally unpublished at some point and then republished, we don't want a notification sent out again.

but it is hard for this module to determine when the first time it is published is, but other modules such as Published (which we happen to maintain) does keep track of this initial transition.

so with this module in place, adding the following line to a nodeapi call, prevents notifies every time we re-publish

if ($op == 'presave' && $node->published) $node->notifications_content_disable = true;