Access denied error at node/%nid/draft when changing status on non-initial revision

I what's happening is that the "access denied" appears because there is no longer a draft version. Perhaps we should be redirecting to node/%node if there is no draft. That patch was working on the form processing, I'm not sure why it's not redirecting in this case.

Are you operating as the site admin or a different user? If a different user, what permissions does that user have?

Thanks Seth,

I am not able reproduce this on my testing site.

-I take a published node and create a new draft.
-I am now on node/%node/draft
-I use the moderation form and moderate to published.
-When I do this, I am redirected to node/%node

Is that what you are doing?

I tested on both the dev and 1.0. I don't think that should make a difference.

I'm seeing the same behaviour on all my sites starting today (after we updated to Drupal 7.9 - may be related?)

The following error appears with the Access Denied message:

Notice: Undefined property: stdClass::$uri in workbench_moderation_moderate_form_submit() (line 1635 of /var/www/drupal-7.9/profiles/uw_base_profile/modules/contrib/workbench_moderation/workbench_moderation.module).

(Currently using 1.0, haven't tried dev yet but will)

Same as @kolafson. We are also on Drupal 7.9.

I'm able to reproduce this after switching to 7.9.

Small patch. I think this bug was introduced with http://drupal.org/node/1057242

+++ b/workbench_moderation.moduleundefined
@@ -1646,6 +1646,9 @@ function workbench_moderation_moderate_form_submit($form, $form_state) {
+      if (empty($form['node']['#value']->uri['path'])) {
+        $form['node']['#value']->uri = entity_uri('node', $form['node']['#value']);
+      }

We should just be doing this instead (always calling entity_uri() when you need it rather than relying on $object->uri):

if ($uri = entity_uri('node', $form['node']['#value'])) {
  $form_state['redirect'] = array($uri['path'], $uri['options']);
}

Thanks Dave.

Patch in #11 worked for us, thank you for taking care of this so quickly!

Looks good. Let's commit it.

http://drupalcode.org/project/workbench_moderation.git/commit/1b24d859da...

This is no longer working for us. Not sure what upgrade caused it to break, but we are getting the access denied errors again. Changing:

  $form_state['redirect'] = array($uri['path'], $uri['options']);

to just

  $form_state['redirect'] = $uri['path'];

seemed to fix it here. Not sure what the purpose of the uri[options] was. This is on 1.x-dev and drupal 7.12. Here is the patch to change this:

I was still running into this issue even with the above patches applied. Throwing a dpm in form.inc I found that despite us setting $form_state['redirect'] in workbench_moderation_moderate_form_submit, the value was not making it all the way through to drupal_redirect_form() in includes/form.inc.

After some head scratching, I noticed that the form_state value we are dealing with in workbench_moderation_moderate_form_submit breaks the convention of the rest of the hooks involved in the processing of the form, and takes $form_state as a LOCAL variable. This means that when we add redirect (or anything for that matter) to the variable, nothing is actually added to the object that gets passed off to the other hooks.

Making $form_state a passed by reference variable in workbench_moderation_moderate_form_submit allows us to add the 'redirect' key, which then makes it through to drupal_redirect_form, fixing this error, and redirecting users to the proper page. Patch attached.

Could you give me a more detailed breakdown of the user permissions you have when you get the access denied?

The patch in 17 is formally correct.

Committed.

6bdb20e..c3d3da6  7.x-1.x -> 7.x-1.x