OGUR does not work for me after OG update 1.3
| Project: | OG User Roles |
| Version: | 6.x-1.5 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | SomebodySysop |
| Status: | won't fix |
Jump to:
Hi,
first of all: thank you very much for this really nice and important module!
I managed to set up TAC integration by your kind step-by-step how-to, and everything worked fine. Later, I had to move on from TAC to CA (Control Access), as tagging with terms made some troubles, and content type based permissions withing groups resulted a much easier structure. After disabling (but not uninstalling TAC) everything worked fine also, even after rebuilding the permissions (admin/content/node-settings/rebuild).
But then: upgrading OG from 1.2 to 1.3 (as it has some improvements in connected with notifications) suddenly "kills" the system, and OG roles are not interpreted. I mean: no permissions are granted based on roles (create/edit nodes, memberships etc.).
My multinode UI looks like this now:
all - AND - 0
caa - OR - 2 (well, I do not know what this means...)
car - AND - 0
ogr - OR - 1
I really cannot figure out what could be the problem after upgrading.
#1
OG release notes do not indicate any changes with respect to grants between 1.2 and 1.3. Theoretically, if it worked in 1.2 should work as well in 1.3. http://drupal.org/node/429608
What did your UI look like before? You are or are not using TAC/OG Integration?
Did you rebuild permissions (administer->post settings->rebuild permissions) after upgrade?
Turn off TAC/OG integration. Do OG roles work then?
#2
Thank you very much for your really fast and kind reply!
My issue is really strange I know, and have no idea what could have happened, but tried to figure out after your highlights.
My multinode UI was just the same before, and I do use TAC/OG Integration for the Content Access.
As you suggested, I rebuild the permissions again without any success, and also disabled TAC/OG Intergration, but that did not help neither...
So now: I have some roles in groups, and checked in mysql, that users' roles are all right (and the table changes when I set roles). But the permissions are not granted by them, so a "group-admin" cannot create new content or manage users' roles.
What is extremely strange is if I set a "group-founder" role to a user, than he/she will be able to administer the group.
It also strange, that users are not listed in a view by "if the member is an admin in group", so I think the main system just not sees the roles table...
I also checked global permissions and everything looks just like the same before upgrading.
#3
OGUR roles are added to the $user object, which operates independant of og. The only way og could affect the assignment of ogur role permissions is if ogur can't make out the group context. Unless there has been a change in og which specifically nullifies ogur roles, my guess is that something other than og changed in your environment, and this is the cause of this particular problem.
Go to ogur settings and enable "og_user_test" debug table: http://drupal.org/node/164038.
Next, logged in as a user in question, go to a group where you should have the role permissions and try to do something that requires the permission(s).
Post the output from the og_user_test table here, along with a description of what we see (roles, users, urls), what should be happening and what is happening. Remember, we don't know the details of your site, so you'll need to be as descriptive as possible. Don't post multiple pages of output detail here, just the few lines of relevant output (i.e., user goes to group, tries to do something, gets access denied or something). This output will tell us for sure if ogur is correctly assigning the role(s) to the user.
Thanks.
#4
Thank you very much again for your really helpful reply rich in details.
That might be true that other changes was made also, because I had some other modules' upgrade also - but as tested: I experienced the issues only after upgrading the OG.
But anyway, I tried as you instructed (og_user_test) and suddenly everything is all right! I really do not understand, maybe some other issue also occured, I will look after this more deeply tomarrow, and replay the issue from the begining.
Really strange! :)
I close the issue for now as everything looks fine (althought does not makes sense for me), after testing I will report back.
#5
As I replayed now the whole upgrade again, I can see in the 'og_user_test' that everything looks good in OGUR:
| 2009-04-20 04:47:55 du | 1335 | username | 27 | og_user_roles_all_roles | 2 | group context: | | /node/27/revisions (http://example.domain/k%C3%B6z%C3%B6ss%C3%A9gi_feladatok/a_honlap_elk%C3...) | node | 27 | revisions | | Roles Returned: (authenticated user,írási_jogosultságok,csoport_tag,csoport_admin) |BUT:
| 2009-04-20 04:47:55 du | 1335 | username | 0 | og_user_roles_all_roles | 0 | group context: | | /node/27/revisions (http://example.domain/k%C3%B6z%C3%B6ss%C3%A9gi_feladatok/a_honlap_elk%C3...) | toboggan | denied | | | Roles Returned: (authenticated user,írási_jogosultságok) |The roles explained:írási_jogosultságok: global role (to post and write comments)
csoprot_tag: group-role (default member)
csoport_admin: group-role (group admin)
So the toboggan modul could make the mess?
Yesterday it just started to work fine after some modifications (enabling TAC, diasabling TAC Integration and later enabling), now I try to test out, what should have been done...
Any suggestion is welcomed, and thank you very much again for having looked into the issue!
#6
Well, I was too fast when I wrote that everything is all right.
Most of the permissions work great (edit, posting nodes, managing users) but some does not work (eg. revisions). Permissions are set, and nothing changed while upgrade.
I tried also just upgrading OG and no other modules, but the same result occured: revisions tab can bee seen at group nodes, but after clicking it with a group-admin user, it gets to an 'access denied' page.
It's getting more and more strange for me.
I will report back, if any other result could be reached.
#7
I reopened with new title the issue, as described above.
That might be a special case with my system, other users' feedback would be welcomed.
#8
Sorry to post so many comments... But just discovered, that TAC Integration works fine!
That's why group-admins cannot reach revisions (as there can be set the edit/post/delete permissions). Site admin can acces revisions!
But when I disable TAC, the Content Access Integraton, which was working before, stops working. And if all TAC Integration is switched off, the global rules does not apply also (eg.: group admin has the right to edit group node, and the tab can be seen on the page, but after clicking it: "Access Denied').
#9
Honestly, I'm lost. The only thing I see which makes sense is:
| 2009-04-20 04:47:55 du | 1335 | username | 27 | og_user_roles_all_roles | 2 | group context: | | /node/27/revisions (http://example.domain/k%C3%B6z%C3%B6ss%C3%A9gi_feladatok/a_honlap_elk%C3...) | node | 27 | revisions | | Roles Returned: (authenticated user,írási_jogosultságok,csoport_tag,csoport_admin) |This is how it should be (although I have no idea why your referrer is so wierd).
OGUR is only going to give you the permissions of a group role while in group context.
Clearly:
| 2009-04-20 04:47:55 du | 1335 | username | 0 | og_user_roles_all_roles | 0 | group context: | | /node/27/revisions (http://example.domain/k%C3%B6z%C3%B6ss%C3%A9gi_feladatok/a_honlap_elk%C3...) | toboggan | denied | | | Roles Returned: (authenticated user,írási_jogosultságok)is NOT in group context. Now, why this is, I don't know. You'll need to explain a bit more about why arg(0) = toboggan while your url is: node/27/revisions.
#10
Thank you very much again for looking into the issue!
I was playing with the permissions and with the test table (og_user_test) for a while to be able to identify the problem with my low skills, but without any success.
Now, I switched off everything in the multinode UI, disabled TAC Integration, also disabled TAC, CA and ACL modules and rebuilt the permissions. What is really strange (as before I thought that CA could be the problem) that after the group admins have no rights to edit the node, but the 'edit', 'revisions' tabs can be seen, but the page gives 'Access Denied'.
Posting new group post is somehow possible, and it works like charm (with: ognodeadd)!
What looks suspicious for me, just as for You is that while editing the group post does not seems to be a group post (no 'gid' given after 'group context: ').
Some parts of the test table if those could help you identifí the problem or suggest me where to look:
Access denied for group_admin while trying to edit (a group node):
| 2009-04-20 11:12:41 du | 13 | username | 27 | og_user_roles_all_roles | 2 | group context: | | /node/27/edit (http://example.domain/k%C3%B6z%C3%B6ss%C3%A9gi_feladatok/a_honlap_elk%C3...) | node | 27 | edit | | Roles Returned: (authenticated user,írási_jogosultságok,csoport_tag,csoport_admin) |Site admin while editing the same with succes:
| 2009-04-20 11:14:23 du | 3 | username | 27 | og_user_roles_all_roles | 0 | group context: 27 | | /node/27/edit () | node | 27 | edit | | Roles Returned: (authenticated user,admin,szerkeszt�,írási_jogosultságok,csoport_tag,csoport_admin,csoport_alapító) |Group admin posting a new group post (with success):
| 2009-04-21 12:14:32 de | 13 | username | 27 | og_user_roles_all_roles | 0 | group context: 27 | | /node/ognodeadd?type=group_date&gids[]=27 (http://example.domain/k%C3%B6z%C3%B6ss%C3%A9gi_feladatok/a_honlap_elk%C3...) | node | ognodeadd | | | Roles Returned: (authenticated user,írási_jogosultságok,csoport_tag,csoport_admin) |The strange referrel is because of pathauto I think, as it generates the URLs from Hungarian words containing special characters. I do not think this could be the problem, as before it worked, but if you think I should look after this, then of course I will.
I have no idea why the group does not seem to be a group (group context) in the rows above now, as I checked now, before upgrading it looked like: 'group context: 27'.
| 2009-04-21 12:28:21 de | 13 | username | 27 | og_user_roles_all_roles | 0 | group context: 27 | | /node/27/edit (http://example.domain/node/27/edit) | node | 27 | edit |PS.: also checked clicking the edit button from the group node (with strange referral), and it worked also. So the strange encoding could not be the problem.
#11
You keep changing the title of this issue and adding stuff in a way that I find impossible to follow. I don't even know what your problem is at this point. The only thing I am able to gather from all of this is that ogur is working as expected. You have not demonstrated a case to me where it is not working where it should.
#12
Sorry for this, but I was always trying to write down the sypthoms I see, that is why it looks confused.
To sumarize the case: my last comment is what shows the reality.
I disabled the TAC Integration, diasabled also TAC, Content Access and ACL modules.
Whith a "bare" OG User Roles modul I tried to acces the pages mentioned above, but while being a group administrator, without success.
I can see the tabs on the nodes (like: edit, revisions), but cannot access them. With site admin user, everything works fine. The og_roles_tests outputs with comment is in my last comment.
What is strange is that the "group context: " text is without a group id while trying to acces the page as group administrator - but the node is a group node.
Posting new group posts work fine. So the problem is with group-node editing and revisioning.
I hope this makes things clearer, sorry for any inconvience caused with changing the titles so many times.
#13
With the rise of the rewritten OGUR 4.x for Drupal 6, in which many unrelated features of OGUR were removed, and nearing a release of Drupal 7, I'm closing down old issues.