Needs review
Project:
OG User Roles
Version:
6.x-4.0
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
19 Jan 2010 at 17:09 UTC
Updated:
28 May 2013 at 16:01 UTC
Jump to comment: Most recent file
Comments
Comment #1
noderunner commentedHere is what appears to happen:
When an Administrator of an Organic Group with the proper permissions creates a Webform, access is denied to the Form Components and Results. Organic Groups User Roles 4.0 provides content access control. Content Access is not installed.
The webform is published, and the node_access table is properly configured as explained: http://drupal.org/node/226987 .
Content Access Permissions were rebuilt, cron was run, and all caching was turned off and the caches cleared.
And the Authenticated User is one of the "Roles that can submit this webform: "
When the Authenticated User is given the same permissions as the Administrator, then the Webform can be accessed by both the OG Adminsitrator and the Authenticated User, but then, of course, it can be edited by any authenticated user which violates the security policy and general use case.
OGUR and OG have also assigned the roles properly:
print_r($user);
[roles] => Array
(
[2] => authenticated user
[3] => Admin
[4] => GroupMember
)
Any idea how to troubleshoot?
Comment #2
noderunner commentedIs there a weight I need to change in the database?
Comment #3
goz commentedtry this http://drupal.org/node/691460
Comment #4
noderunner commentedShould I put that code in og_user_roles.module here:
function og_user_roles_init() {
global $user;
// Try to determine group context using customized menu system functions.
$group_node = og_user_roles_determine_context();
// Assign additional user roles to current user (if any).
og_user_roles_grant_roles($user, $group_node);
}
I couldn't find hook_user or hook_init in the webform.module .
Thanks very much for helping. This is a new skill for me.
Comment #5
noderunner commentedI changed the webform module weight in the system table to -2 since og_user_roles was -1. No change in behavior.
Changing back to -1.
Comment #6
noderunner commentedThe devel module is set properly and the node_access block shows that somehow the group context or role assignment breaks from "Edit" to "Form Components" in the webform. How does that happen for the same node?
username create view update delete
user NO: by the module YES: node access NO: node access NO: node access
admin YES: administer nodes YES: administer nodes YES: administer nodes YES: administer nodes
Roles from print_r($user); for "Edit":
[2] => authenticated user
[3] => Admin
[4] => GroupMember
Roles from print_r($user); for "Form Components":
[2] => authenticated user
Comment #7
noderunner commentedTried altering module weights in the system table, again, with different weights. No change in behavior.
OGUR -2
webform -1
OG 0
OGUR -2
OG 0
webform 1
Comment #8
goz commentedMy apologies for precedent link.
I fix similar error under openatrium and ucreate module : http://drupal.org/node/691460#comment-2516602
i hope this solution will help you to.
Comment #9
noderunner commentedGoz, thanks for the suggestion. Still trying to digest it.
I've tried focusing on the Webform module without luck.
In the webform module, on a separate VM, I tried changing the 'acccess callback' for:
to . . .
Then, I saved the file, restarted MySQL and Apache. Disabled and enabled the Webform module. Toggled permissions.
Strangely, no change in behavior, at all.
Of course, OGUR 4.0, is still not showing the correct role for the user on node/%/edit/components/* while it does on node/%/edit. I really don't understand how this happens on the same node.
More and more pain.
Comment #10
sunThe cause of this may be that the local tasks of Webform do not have OG's query string (?gid=...), so there is no group context, and if there is no group context, OGUR won't do anything.
Comment #11
bribiz commentedSubscribe
Comment #12
AntiNSA commentedsubscribe
Comment #13
sunComment #14
endiku commentedA group member with the role that allows him webform editing cannot edit component. However a group Admin CAN edit webform components. Doesn't this shoot down the missing (?gid=...) issue? Why would the group admin have gid information any differently than a non-admin member with editing permissions. Interestingly a member with "administer nodes" still cannot edit the components of a webform even though they seem to have normal permissions granted by administer nodes for group nodes.
Just what does group admin provide exactly in terms of node access within an og group over specific group member permissions? That must be the key to providing a member with webform permissions the rest of their needed access.
Comment #15
pgillis commentedIt seems to me that the issue is the permission required is dependent on og_user_roles, which is dependent on the proper group context. The group Admin has some elevated permission based on a different group context that is loading? Sorry, just trying to sort this out:(
Comment #16
pgillis commentedThis issue is caused by the callback function for the webform components object being called webform_menu_load instead of node_load.
I have attached a patch that looks for anything ending in "_load" instead of looking for "node_load" as the function name.
Is there an inherent problem with this approach? The function could have been passed a type of "webform_menu" but it's being called in og_user_roles_determine_context and the object is a node type so it's quite a stretch.
Comment #17
pgillis commentedComment #18
pgillis commentedCleaned up my patch a little.
Comment #19
endiku commentedAny news on this? I have tried the patch with no noticeable difference. Non-admin group members still have no components. Anyone have any success with this patch?
Comment #20
pgillis commentedMy patch from comment 18 is not longer needed with dev version. I don't want to change status as it seems others still had problems with the patch.
Comment #21
soulfroysMy situation:
Drupal 6.26
OG 6.x-2.4+13-dev (2012-06-17)
OGUR 6.x-4.x-dev (2011-Feb-25)
Content Access 6.x-1.x-dev (2011-12-01)
TAC Lite 6.x-1.6
The patch works, tks!!!
Comment #22
victoriachan commentedPatch had problem applying (error: og_user_rolesNew.module: No such file or directory), so I'm just changing og_user_rolesNew.module to og_user_roles.module.
Thanks,
Victoria
Comment #23
victoriachan commentedHi,
Sorry, me again. That previous patch didn't work with drush make. So I have generated a new one.
Cheers,
Victoria