Weform Access Denied With 6.15 and OGUR 4.0 and 1.5

OGUR is an additional module that lets you assign roles to users in the group context. There are two versions for 6.x.: OGUR 1.5 is feature rich but OGUR 4.0 is simplified with almost all features stripped except the definition of roles for the group member and the administrator.

How do I troubleshoot this problem? What information can I provide?

Same problem with OGUR 1.5. Edited issue title to correspond.

Tested on separate installation from OGUR 4.0 .

quicksketch, you were right. The code I referenced did not add the "view" permission in 6.15. Perhaps it was for 5.x. I even tried adding the $account parameter.

I'm a bit out of my depth here, but I have a deadline next week, and unfortunately for me, this was a top 5 feature for the site. It's going to be interesting to say the least. ;-) Yikes!

For anyone interested:

http://drupal.org/node/226987#comment-2366800

Thanks

Here are the webform permissions for the different roles in the 'permission' table:

Admin:

access own webform submissions, access webform results, clear webform results, create webforms, edit own webform submissions, edit own webforms, edit webform submissions, edit webforms

Group Member:

access own webform submissions, edit own webform submissions

authenticated user:

access own webform submissions, edit own webform submissions

In hope of a workaround, as suggested in a forum post, I installed Content Access on a demo box with Webform, Organic Groups, and OG User Roles 4.0.

It shows that the webform permissions for the group admin role do not appear for webform content. The permissions for the the other content types like Poll do show in Content Access.

As well, the OG Details Block does not show the "Create Webform" for the Admin role. It does show "Create Webform" when the permission is given to the authenticated user role.

I'm really reluctant to pursue this as a workaround, though. I selected OGUR 4.0 rather than OGUR 1.5 in the interest of speed and simplicity. I plan to add a WYSIWG editor later, and that should make things difficult enough for troubleshooting.

I added the OG Admin and OG Member roles to Access Control for the Webform content type, but it still doesn't work. All of the other content types work.

Content Access didn't change any of the behavior.

What information is needed for troubleshooting beyond what has been provided?

Checked the webform_roles table and everything seems to correspond to the "Roles that can submit this webform:".

What can else can be checked to troubleshoot?

Is there a weight I need to change in the database?

The Devel module for node_acces entries appears on the "View" tab of the node, but it disappears when I try to see what is happening on "Edit"

node_access entries for nodes shown on this page
node prio status realm gid view update delete explained 
node prio status realm gid view update delete explained 
10 0 ok content_access:
all 0 1′ 0 0 All users may view this node. 

(Some of the table elements provide additional information if you hover your mouse over them.)
admin has the administer nodes permission and thus full access to all nodes.
  
Anonymous has the following access to node 10: 
•create: NO: The 'webform' module (which defines the 'webform' content type) denies this.
•view: YES: Node access allows this.
•update: NO: Node access denies this.
•delete: NO: Node access denies this.
(For per-user access permissions enable the second DNA block.)

Here the permissions are still set to allow the unauthenticated user full permissions for the webform. Otherwise, the "Edit" tab would not be visible at all.

Also, the the node_access block does not appear for any user other than admin even when the block is configured to be visibile to other roles. Is that normal behavior?

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.

When the admin user is logged in, there appears to be a callback for 'node/10/edit/components" where 10 is the the webform node. How can I see what query is made for the OG Admin user? The Devel node_access block disappears from the authenticated user even when it is configured to be displayed.

Is that the right terminology?


0.25 1 og_user_roles_menu_get_item SELECT * FROM menu_router WHERE path IN ('node/10/edit/components','node/10/edit/%','node/10/%/components','node/10/%/%','node/%/edit/components','node/%/edit/%','node/10/edit','node/10/%','node/%/edit','node/%/%','node/10','node/%','node') ORDER BY fit DESC LIMIT 0, 1

The devel module is set properly now and the node_access block shows that somehow the group context or role assignment breaks from "Edit" to "Form Components"

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

Tried altering module weights in the system table of a demo box separate from the one above. No change in behavior.

OGUR -2
webform -1
og 0

OGUR -2
OG 0
webform 1

On a separate VM, I tried changing the 'acccess callback' for:

node/%webform_menu/edit/components
node/%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,

Saved the file, restarted MySQL and Apache. Disabled and enabled the Webform module. Toggled permissions.

Strangely, no change in behavior, at all.

Sun, thanks for taking a look.

I suppose when we find which module has the bug or code that is easiest to change, we can mark the other as a duplicate. I just wanted to make the bug visible to both groups.

quicksketch, I already have a server setup for you with the debug module. Want to take a look?

I'd be glad to give you root access.

Thanks for your consideration.