Posted by noderunner on January 19, 2010 at 5:09pm
6 followers
| Project: | OG User Roles |
| Version: | 6.x-4.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | ogur, Organic Groups, organic groups user roles, webform |
Issue Summary
It seems like OGUR 4.0 and 1.5 don't get along with Webform.
The OG Admin can create a Webform if he knows the link, but then he can't add any fields or see the data.
Lots of details here: http://drupal.org/node/688810
Any idea how to troubleshoot?
Thanks.
Comments
#1
Here 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?
#2
Is there a weight I need to change in the database?
#3
try this http://drupal.org/node/691460
#4
Should 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.
#5
I 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.
#6
The 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
#7
Tried 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
#8
My 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.
#9
Goz, 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:
node/%webform_menu/edit/componentsnode/%webform_menu/edit/components/%webform_menu_component
node/%webform_menu/edit/components/%webform_menu_component/clone
node/%webform_menu/edit/components/%webform_menu_component/delete
to . . .
'access callback' => TRUE,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.
#10
The 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.
#11
Subscribe
#12
subscribe
#13
#14
A 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.
#15
It 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:(
#16
This 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.
#17
#18
Cleaned up my patch a little.
#19
Any 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?
#20
My 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.