I have just installed Workbench 1.0 (wonderful module suite by the way). It all seems to function as described, but the column of Actions in the My Workbench page is blank unless I give the user role "Bypass content access control" Node permission, even for their own content (see attached image).

CommentFileSizeAuthor
#23 workbench_edited_export.txt20.73 KBAnonymous (not verified)
#11 1269186-views-wtf-load.patch563 bytesagentrickard
Workbench Actions.png38.51 KBrosborn

Comments

stevector’s picture

stevector
he/him
commented
Project: Workbench » Workbench Moderation
polynya’s picture

polynya commented

I've had a similar problem which I traced to function workbench_access_node_access in the workbench_access module.

This function is called when the views on the "My Workbench" pages are displayed but $node doesn't contain the workbench_access field. I fixed it by adding a line like this at the top of the function.

$node = node_load($node->nid);

I'll create a patch when I get chance.

If this fixes your problem, should this issue be moved to the workbench_access project?

rosborn’s picture

rosborn commented
Project: Workbench Moderation » Workbench Access

Thanks. I've done a quick test and that did fix the problem. Moving to Workbench Access.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Postponed (maintainer needs more info)

What version of Views are you using? Does editorial access work on other pages? Does the user have _any_ node editing privileges?

rosborn’s picture

rosborn commented

I'm using Views 3 (7.x-3.x-dev from Aug. 15). If you are asking whether I can edit the pages for which the action column is blank, the answer is yes. The role I am logged in as has privilege to create/edit/delete nearly all content types (own and any content). I can toggle the display of the "Edit" link in the Actions column by turning "Bypass content access control" Node permission on and off.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

What about permissions like "Edit any Article content"?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Category: bug » support

To be more clear, I think you are having generic permissions problems. The user account must have a core Node module permission to edit / delete the node. Without it, you get access denied.

Please use Devel Node Access to debug.

rosborn’s picture

rosborn commented

Even if I give the role every single node permission and Workbench permission, I can still toggle this effect by switching "Bypass content access control" on and off. In any case, it is clear that the "Edit" action is missing even for nodes that the user clearly has permission to edit. I don't need to reinstall the Devel module to conclude that (I removed it once my site was functioning properly).

Also, this particular role passed "Check Permissions" in the Workspace Moderation module (all of them, including as a publisher). However, if there are other relevant permissions I should check, I am happy to do so.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

[edit: retracted]

When the heck did this behavior change? Apologies, I've been on vacation.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Category: support » bug
Status: Postponed (maintainer needs more info) » Active
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Needs review
StatusFileSize
new 1269186-views-wtf-load.patch563 bytes

And a proper patch.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Needs review » Postponed (maintainer needs more info)

Actually, please test the latest Views 7.x-3.x-dev and not the version from August. The maintainers indicated there has been a change in behavior in how nodes were loaded with queries and you may be using the older version that loads the 'fake' node.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

This patch is a stop-gap against a real fix in Views, which is broken in the version you are using.

class views_handler_field_node_link_edit only does a partial $node and needs to run a full node_load() before checking node_access.

Apparently, this has been fixed in later dev versions of Views, as the latest release works as expected.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

This was fixed in Views on Aug 23 with #1172970: provide a unified way to retrieve result entities.

rosborn’s picture

rosborn commented

I'll test the latest dev version of Views as soon as I can this evening - I'm at my day job at the moment but thanks for the tip.

It will be a relief when Views is finally stable. It's a bit nerve-wracking running a live site when such a fundamental module is still being regularly tweaked. But to repeat what I said at the beginning, Workbench is looking like one of the most well-produced packages I've seen in Drupal 7, and should be more widely known. Thanks for all the work.

rosborn’s picture

rosborn commented

OK - this is getting weird. I upgraded my test site (synced to the production site with identical behavior as described above) to the latest dev version of Views (Sept. 13 - datestamp = "1315875198"). Now, the Actions column of the "My Edits" table is blank whether I have "Bypass content access control" on or off -- but -- the last column of the "All Recent Content" table (i.e., the one without a column header) has an "edit" link in every row. This time the fix in #2 does not change anything.

rosborn’s picture

rosborn commented
Status: Closed (works as designed) » Active

Sorry I didn't see that this had been closed, but I don't think this has been fixed, or if it was, the latest version of Views causes another failure.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (works as designed)

Then it's a Views bug and needs to be reported or moved there.

rosborn’s picture

rosborn commented

That may be true, but I think it would be courteous to other users to classify this ticket as postponed until the Views bug is fixed. Until then, Workbench does not work "as designed". Unless I am the only one experiencing this issue, then you will have other Workbench users checking here and not knowing it's a Views bug. If I am the only one, and others understand why, then please let me know.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

No. You will get better results by reporting the issue properly to the module responsible. The status stays.

rosborn’s picture

rosborn commented

Well, someone who understands what the problem is should report it then, because I have no idea what the underlying Views bug is. All I know are the symptoms that affect Workbench. #14 above suggested that it had been fixed, but it either hasn't, or it's a different bug. Someone who understands how Workbench uses Views would have to report it to the Views issue queue.

I run a website in my spare time without any prior experience in Drupal development, or even PHP. I was reporting the bug as a courtesy. If you want people to use Workbench, then I would suggest being a little less curt with them.

sethfisher’s picture

sethfisher commented

Those arriving here should take a look at http://drupal.org/node/1388220

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new workbench_edited_export.txt20.73 KB

Nevermind - doesn't work.