I'm using the revisioning module to allow a pending revision of current nodes to be created, edited and reviewed prior to it replacing the current published revision. When a user subscribes to a node, they are getting notifications on every edit to the pending revision, even though they have no access to see this revision.

Is there a way to restrict notifications to only updates that are published?

Comments

danchadwick’s picture

danchadwick commented

This implies that if you have selected notifications upon creation but not update, that the notification not be send when an unpublished node is created and that it is published when the unpublished node published (i.e. status 0 -> 1).

I need this too.

jzornig’s picture

jzornig commented

I thought it did this. The module does test the $node->status. In my case the node is already published, but the updates are being made to a pending revision. I have made a change to the notifications_content_nodeapi() function in sites/all/modules/notifications/notifications_content/notifications_content.module which has achieved what I was after, but I used the values of my workflow state cck field to achieve this. So my modification is unlikely to be of use to you as is. I've put it below just in case it helps you find your own solution.


function notifications_content_nodeapi(&$node, $op, $arg = 0) {
  global $user;
  // Keep track of nodes so we don't send notifications twice for the same node. See http://drupal.org/node/722432
  static $done;

  switch ($op) {
    case 'load':
      // Store current status for later reference
      $node->old_status = $node->status;
      break;
   
    case 'update':
    case 'insert':
+      if (!$node->is_current && ($node->field_workflow_state[0]['value'] != "Approved")) break;
      // Notifications just for published nodes. If we don't have any option enabled for this content type, skip the event
TheDanScott’s picture

TheDanScott commented

Hi All,

I'd like to re-kindle this issue if possible. I'm having this issue with the current latest versions of notification and revisioning. I've made a note of this issue (along with some other quirks when these two modules are mixed) over on the revisioning project at http://drupal.org/node/1415558

With my (sometimes naive) view of Drupal, I would hope that this is something that could be sorted out using the information that core Drupal and the Revisioning module make available.

I stuck a dpm($node) in the notifications_content_nodeapi() function and saved a new (pending) revision. Here is the output that came back:

nid (String, 3 characters ) 241
uid (String, 1 characters ) 2
created (Integer) 1327420147
type (String, 4 characters ) news
language (String, 0 characters )
changed (Integer) 1327451465
title (String, 38 characters ) Spring Regatta Notice of Race released
teaser_js (String, 0 characters )
teaser_include (Integer) 1
body (String, 603 characters ) <p>Lorem ipsum dolor sit amet, consectetuer adi...
format (String, 1 characters ) 4
revision (Boolean) TRUE
log (String, 0 characters )
name (String, 6 characters ) daniel
date (String, 25 characters ) 2012-01-25 01:49:07 +1000
status (String, 1 characters ) 1
promote (Integer) 1
sticky (Integer) 0
op (String, 4 characters ) Save
submit (String, 4 characters ) Save
preview (String, 7 characters ) Preview
delete (String, 20 characters ) Delete all revisions
preview_changes (String, 12 characters ) View changes
form_build_id (String, 37 characters ) form-1341d3c686eaa73417e9f0845e2b7121
form_token (String, 32 characters ) 9e912452c8d8f0a0272d1831b10d78b5
form_id (String, 14 characters ) news_node_form
comment (String, 1 characters ) 2
menu (Array, 13 elements)
path (String, 53 characters ) beach-racing/news/spring-regatta-notice-race-re...
pid (String, 3 characters ) 207
pathauto_perform_alias (Boolean) TRUE
old_alias (String, 53 characters ) beach-racing/news/spring-regatta-notice-race-re...
taxonomy (Array, 2 elements)
field_summary (Array, 1 element)
field_picture (Array, 1 element)
field_picture_gallery (Array, 2 elements)
field_attachment (Array, 1 element)
field_related_node (Array, 1 element)
revision_moderation (Boolean) TRUE
notifications_content_disable (Integer) 0
teaser (String, 480 characters ) <p>Lorem ipsum dolor sit amet, consectetuer adi...
validated (Boolean) TRUE
current_revision_id (String, 3 characters ) 269
is_current (Boolean) TRUE
num_revisions (String, 1 characters ) 5
is_pending (Boolean) FALSE
current_title (String, 38 characters ) Spring Regatta Notice of Race released
is_new (Boolean) FALSE
old_vid (String, 3 characters ) 269
timestamp (Integer) 1327451465
vid (String, 3 characters ) 270
homepage (NULL)

The good news is that the vid value accurately reflects the (new, pending) revision that was just saved. So the question simply becomes how to check if that revision is "published". Does core Drupal offer anything that can determine that for a revision? (it seems the node->status and node->is_pending both reflect the overall node, which already has a published revision).

Does anyone have a suggestion on how this might be done in a way that is "revisions module agnostic" (since revisions is just modifying core functionality in drupal). The Node Tools module (a dependency of revisions) has a simple little function to get the "current revision" as follows:

function node_tools_get_current_node_revision_id($nid) {
  return db_result(db_query('SELECT vid FROM {node} WHERE nid=%d', $nid));
}

Would it be worth checking the revision of the node passed into nodeapi against drupal's understanding of the "current" revision (using the query above) and if they don't match then cancel the "notification"? Would such a check break any other behaviour?

If Core Drupal can't offer anything, then I guess I should be chasing up the revisioning team to ask what the best way to check a revision's status is (as I assume their module will provide some sort of API for that)?

rdeboer’s picture

rdeboer
Location Melbourne
commented

@TheSchmuck:

The reason why you are not seeing any of the additional revision info from the Revisioning module is because 'revisioning' comes after 'notifications_content' in the alphabet. Therefore notifications_content_nodeapi() is called prior to revisioning_nodeapi().

We could change this by decreasing the so-called "weight" of Revisioning. However this may have side effects on existing installs of Revisioning.

A better approach may be to call in your own hook code the function node_load($node->nid, $node->vid). This will load the correct revision (which is cached anyway) and will also invoke revisioning_nodeapi(), which will flesh out goodies like $node->is_pending etc. Try another dpm($node) to see what's in there.

Rik