I would like super users to be able to create content, and place it in sections of the menu (or taxonomy) that are not governed by workflow access. This appears to be currently impossible.
I would also like a super user to be able to place content into all sections of the menu (or taxonomy) that are governed by workflow access. it seems that the only way I can manage this currently is to grant that individual user (or a role) as an "editor" of every single section indicated. This is a lot of unnecessary configuration for a super user.
If the "Bypass content access control" permission also allowed users to bypass the workflow_access control then we'd have a way to get around this limitation.
| Comment | File | Size | Author |
|---|---|---|---|
| #36 | workbench_access-bypass_content_access_control-1438016-36.patch | 14.54 KB | oenie |
| #34 | workbench_access-bypass_content_access_control-1438016-34.patch | 14.35 KB | oenie |
| #14 | 1438016-bypass-wa.patch | 10.68 KB | agentrickard |
| #12 | 1438016-bypass-wa.patch | 8.33 KB | agentrickard |
| #5 | make_bypass_node_access_work-1438016-5.patch | 532 bytes | jenlampton |
Comments
Comment #1
agentrickardYou should be able to assign that user to the top-level item; the rest will be inherited.
Comment #2
jenlamptonI need to assign the user to the top-level of item of every single menu? What if I have 20 menus? What if I have 19 menus that have nothing to do with workbench_access, but I still need to have Basic pages in those menus?
Now I have to add 19 menus as "Sections" that will never be used, and add a my admin user to 20 menus that won't have any affect on their every day business. And every time I add a new menu, I need to add the menu as a section, and the admin user to that section.
That seems like a lot of work just to get nothing special to happen for this user.
Comment #3
agentrickardFair enough. But why not give them 'bypass node access' permission? Why is that not sufficient?
Comment #4
jenlamptonMy administrators have the "Bypass content access control" permission, but when they create basic pages, the "Edition Based Access" field is still there, and is still required. There's no way to create a Basic page that is is not posted into a workflow_access "section" of the site.
If this permission is supposed to allow people to get around workflow_access then I guess this is a bug. I'll see if I can figure out why it's not working the way it should.
Comment #5
jenlamptonWell, this fixed it. But I feel it's probably not the real solution. :/
Comment #6.0
(not verified) commentedspecify a second request, issue summary initiative
Comment #7
jenlamptonIt looks like the test will need to be written differently, since user 1 is an 'Administrator' and administrator's have the 'Bypass content access control' permission, that would be a good user to use to test if they can bypass worbench_access, but that user should not be used to test if it's working. I'm not sure I'm familiar enough with the testing framework to make this happen.
Comment #8
jenlamptonWhy do I keep calling workbench, workflow?
Comment #9
agentrickardThis is the original design and it is deliberate, not a bug. You can totally disable workbench access per content type. This is a new use-case.
Comment #10
jenlamptonI only need one content type to be governed by workbench_access, and it's basic page. My whole menu is made up of basic pages, but I need to have some people have access to pages some parts of the menu, and other people to pages in other parts, and super-admins need to not be limited at all. It *seems* pretty straightforward.
I think that if your suggestion of allowing super-admins "Bypass content access control" permission worked, this simple use-case would be possible. I'm not sure I understand why it's not a bug, but maybe I'm missing the actual use case. (I also don't see how this use-case differs from 1.1 in the README.txt file)
When I get it working I'll come back and learn some more about testing so we can get this in. :)
Comment #11
agentrickardThe reason it's not a bug is that we don't give user 1 any special treatment. This was deliberate to prevent admin users from breaking the permissions structure on nodes.
I think the feature request here is a new permission 'Assign to all sections' or similar, which automatically places that role in every section, so you don't have to configure user 1.
Comment #12
agentrickardHere's a patch. Needs a test and some input on how to handle the user/UID/sections page.
Adds a new permission: "Bypass Workbench Access section restrictions"
Comment #14
agentrickardHere's a patch that should pass.
Comment #15
hass commented#14: 1438016-bypass-wa.patch queued for re-testing.
Need other bug patch for verification as #1487806: Remove all EMs from settings page fails for no reason.
Comment #16
jenlamptonThanks for this, I'll give it a shot.
(I don't particularly care about user 1 either, I just noticed that user 1 was an administrator and administrators have the "Bypass content access control" permission - so if we were going to use that instead of this new permission - which also makes sense - that test would need to be rewritten since it assumed user 1 wouldn't be special)
:)
Comment #17
agentrickardWhich test?
Comment #18
jenlamptonWorkbenchAccessTestCase->testWorkbenchAccess() does it's test by loading user 1.
Comment #19
grndlvl commentedThis only seems to work if you have the top most parent of the sections as a section. For instance if you are using menus then "All of MENU_NAME" must be set as a section for this to work appropriately.
Comment #20
agentrickardYes, and that's probably a defect.
I think the other question is "do we need a new permission for this or should we use bypass node access".
Comment #21
grndlvl commentedAlso currently requires that the role you wish to bypass the settings to have "Allow all members of this role to be assigned to Workbench Access sections" otherwise even with bypass the user will get access denied when creating nodes.
Comment #22
grndlvl commentedNecessary if you are combining multiple node_access and do not wish to bypass the overall node access.
Comment #23
grndlvl commentedAlso maybe I am missing something, but why doesn't bypass well... bypass section node_access instead of attempting to give all perms for the sections. Wouldn't it be easier if we just passed back "NODE_ACCESS_IGNORE" when the bypass is set for a role? Or is that not possible?
Comment #24
agentrickardI did it this way because we still want the user to assign content to a section in most cases -- it's just that they can assign to any section without being "assigned" to that section.
Imagine the havoc if user 1 isn't assigning content to a section, but everyone else is.
Comment #25
grndlvl commentedAh right then, that's how the sections are added to the form. What if still assigned to user, but also added bypass in workbench_access_check or anywhere else where it limits permissions?
Comment #26
agentrickardWe may need to, given #19 and #21. I thought it was easier and more consistent to just auto-assign.
Comment #27
tugot25 commented#12: 1438016-bypass-wa.patch queued for re-testing.
Comment #28
agentrickard#14: 1438016-bypass-wa.patch queued for re-testing.
Comment #29.0
(not verified) commentedupdate proposed resolution
Comment #30
oenie commentedBecause i needed this patch for my project, i made an up to date version, to the latest dev branch.
Had to change some code in the workbench_access_user_load_data function to incorporate recent changes.
Feel free to test it out !
Comment #32
oenie commentedOK, it seems my last patch showed that:
a) I need to learn running tests (my bad)
b) The test of this latest feature is not really testing it, because it seems that there is no active tree to chose from.
I've added a patch that I think should do fine on the testsuite, but i'm just wondering we might need to look in a decent test of the Bypass function ?
Comment #34
oenie commentedRight, this patch works fine for me, and includes a (albeit short) test for the 'bypass workbench access' permission.
I have to mention that, due to the inclusion of that new permission, the check for 'top level access' of a hierarchy for the user 1 seems somewhat obsolete. Since that user has all permissions, he/she will always be able bypass the Workbench Access module due to the bypass workbench access permission.
Comment #35
agentrickardI need to take a longer look at this but don't know when I can...
Comment #36
oenie commentedReroll for the latest version.
Any chance of getting this reviewed ? I can imagine it's kinda hard with all the D8 work though...