"Configure Roles" tab only visible on "Add Members" page
| Project: | OG User Roles |
| Version: | 6.x-4.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
There is what I consider a small bug that's bad for the usability:
When a group admin opens his og/users list, the tab "Configure Roles" isn't instantly visible, only when the admin opens "Add Members" - then the tab appears.
My programmer came up with the following bugfix that works well in our tests. Add the bold line as line 162 in this context:
elseif ((!empty($item['map'][0]) && $item['map'][0] == 'og' && !empty($item['map'][2])) || $path == 'comment/reply/%') {
$node = og_user_roles_menu_get_object('node', 2);
$node = $node ? $node : node_load($item['map'][2]);
}
Hope that's all that's needed.
I did quite some testing yesterday and will probably implement the module in my live project soon, as it solves several prio 1 user demands for me. Thank you!
#1
A related problem showed up when og_user_roles didn't "know" that certain views were in the group context (in my case, I had extended the group tabs with views, e.g. "pages" of the group). So a content type permission that was connected to a user role in group was missing and the user could not create that content type at that point.
The solution my programmer found was to extend line 160 with a more complex check for the group context.
(This doesn't solve the problem yet that on a similar tab for Forums (which comes with og_forum), the user role context and all group tabs are lost again, possibly because the forums paths coming with og_forum start with forums/... No fix for this one yet, as it's a lower priority.)
#2
Please provide a proper patch.
#3
I'm observing this same bug
#4
with the latest dev code
#5
It looks like the problem is that the og/users/% path is created by Views module and hence there is no associated node_load load function
#6
Here's a patch which takes a slightly different approach, but essentially the same fix as suggested in the initial post.
#7
Is that "menu system maintainer" approved? :)
#8
It's a bit of a hack either way - less overhead I think to check if it's numeric then running through all the rest of the logic.
#9
Thanks for reporting, reviewing, and testing! Committed to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.