Hi,

I'm using:

- Revisioning
- Module grants
- workflow

I followed the tutorials:
http://drupal.org/node/408968
http://drupal.org/node/408052

Everything works great apart from one really annoying bug.

I have the same workflow states as in the tutorial, "In Draft", "In Review" and "Live". I've left the node access permissions alone for the said content types, only set create permissions there. The view, edit and delete are set in the workflow module, per state.

Now, the bug is that when a role has the delete permission, the "Delete" shows up fine. but when attempting to delete, the page redirects to the home page and the node doesnt delete. But, it works if the node has more that one revision.

Anyone has this problem?

Comments

harcher’s picture

After more testing, I can now confirm that a revision will not delete if it's node is in the 'unpublished' state. (i.e. in the {node} table, if the status attribute for this node row is '0')

So it's got nothing to do with the number of revisions there are, as I initially mentioned. It's wether the node is published or not.

so, in the file revisioning.module (starting at line 936):

if (module_grants_node_access('delete', $node)) {
    $link['title'] = $num_revisions == 2 ? t('Delete both revisions') : format_plural($num_revisions, 'Delete', 'Delete all @count revisions');
    $link['href'] = "node/$nid/delete";
    $links[] = $link;
  }

this 'if' statement runs and hence adds the 'Delete' link to the page. However, when hitting this delete link, takes us to the delete confirm page. Then confirming this deletion takes us to home page and nohting is deleted. So it ran this function with node.module:

/**
 * Delete a node.
 */
function node_delete($nid) {

  $node = node_load($nid);

  if (node_access('delete', $node)) {
    db_query('DELETE FROM {node} WHERE nid = %d', $node->nid);
    db_query('DELETE FROM {node_revisions} WHERE nid = %d', $node->nid);

    // Call the node-specific callback (if any):
    node_invoke($node, 'delete');
    node_invoke_nodeapi($node, 'delete');

    // Clear the page and block caches.
    cache_clear_all();

    // Remove this node from the search index if needed.
    if (function_exists('search_wipe')) {
      search_wipe($node->nid, 'node');
    }
    watchdog('content', '@type: deleted %title.', array('@type' => $node->type, '%title' => $node->title));
    drupal_set_message(t('@type %title has been deleted.', array('@type' => node_get_types('name', $node), '%title' => $node->title)));
  }
}

But the 'if' statement there returns FALSE. So nohting gets deleted!

Can anyone shed some light on this please? is this a bug?

rdeboer’s picture

Title: Unable to delete current revision » Unable to delete node when not published
Assigned: Unassigned » rdeboer

The behaviour you report, if confirmed, is definitely not what it should be.
I have to look into it a bit deeper.

harcher’s picture

Is there a quick fix for this?

rdeboer’s picture

Thank you for your report hga77, but unfortunately I can't reproduce your findings....

Using the latest development versions of both Module Grants and Revisioning on my system I can successfully delete nodes that are Published or Unpublished. I have tried this for nodes with 1 revision as well as for nodes with 2 or more revisions.

In these experiments I didn't have Workflow installed.
Would your Workflow settings be the differentiating factor?

harcher’s picture

Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Thanks for looking into this.

It might be workflow, I'll have to test this and post back.

boringgeek’s picture

I am experiencing pretty much the same thing. When clicking delete on any revision or clicking "delete all revisions" from the view revisions tab, I get directed to the home page and nothing is deleted.

I am using the revisioning module in conjunction with the workflow module, but am doing this as an administer with all permissions. To make it more interesting, I can delete the node all together by clicking the checkbox next to it and selecting "delete node" from the "content" screen under the "content management" section.

In the workflow the administrator role has crud permissions on content in any state.

Hope this helps.

Thanks for your work on this module Rik, it really is a godsend.

rdeboer’s picture

Status: Postponed (maintainer needs more info) » Needs review

I've investigated this a bit more with Workflow installed and can now reproduce hga77's scenario -- always a great step towards a solution! The issue is that the core access function is being called, whereas Workflow's access grants should have been applied instead. I will fix this soon.

I cannot reproduce boringgeek's findings: when logged in as someone with the "administer nodes" permission or when logged in with uid=1, you should be able to delete any node, regardless of its publication status. And that's exactly what happens on my system.

Regarding the redirection....
Normally, upon deletion of a node via the revision summary page (i.e. ".../node/1234/revisions") the deleter is redirected to the ".../accessible-content" page. However, if the deleter has no permission to view any of the tabs on the accessible-content page, they'll be redirected to <front> (aka your home page). Does that seem consistent with what you guys observe?

rdeboer’s picture

Title: Unable to delete node when not published » Unable to delete node when not published and Workflow enabled
Status: Needs review » Needs work

While I'm fixing this.... 3 workarounds (which you'd probably already discovered yourselves)
1) move content to a state where it can be published and then delete
or
2) under Administer >> User management >> Permissions, section "node module", tick delete any **type** content for the role(s) and type(s) in question
or
3) get the user to call the admin and request (s)he performs the delete

Rik

harcher’s picture

Thanks RdeBoer for looking into this. Much appreciated.

And also thanks for suggesting solutions. I went with No.2 at the end. This just means that a role can delete a node regardless of its workflow state. Which is the opposite to what we are trying to achieve.

Thanks for all your hard work :)

rdeboer’s picture

Status: Needs work » Fixed

Fixed in 6.x-3.x (16-Dec-09).

Status: Fixed » Closed (fixed)

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