Closed (fixed)
Project:
OG User Roles
Version:
5.x-3.3
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
18 Sep 2007 at 16:41 UTC
Updated:
5 Dec 2008 at 04:31 UTC
Jump to comment: Most recent file
I'm not sure if this is an OG problem or some other module, but I don't know what could be causing it. OG? Drupal? Pathauto?
When I'm the siteadmin and I click on the user name of the node author, it takes me to http://www.mysite.com/username (which in this case is an alias for http://www.mysite.com/user/200), a page where I can view her bio, with tabs to edit the account, edit the bio, contact the author by email, track page visits, etc. Perfect.
When I'm a user with read-access only and I click on this same link, it redirects from http://www.mysite.com/username to http://www.mysite.com/ogusermanage/$organic-group-node-id which happens to be a page not found. What I want is for it to go to http://www.mysite.com/username/bio, which I can view if I type it in, and I see the contact tab there (also what I need).
Is this a config option somewhere? Have I configured something incorrectly? Is there a way to hack it? I suppose I could go in and manually add a URL Alias from username to username/bio, but I'd have to do that for each user which isn't ideal.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | ogur-176662.patch | 10.16 KB | somebodysysop |
| #4 | og_user_roles.module.5.x-2.5_0.patch | 3.88 KB | somebodysysop |
Comments
Comment #1
cindyr commentedI know just enough to be dangerous! Is this possible? I don't understand how it could be, but after lots of testing it's definitely how it functions:
If I click on a username from any page that isn't a group page, such as just a random page on the site not associated with a group except that it uses the OG audience system, and then I click on or type a username address into the URL (such as http://www.mysite.com/webmaster) it works fine. It takes me to that user's bio page with the Contact tab.
If I click on the name or type it in from the group home page, that's when it redirects to /ogusermanage/group-nid.
Comment #2
cindyr commentedLooks like this is an og user roles issue...
Comment #3
cindyr commentedIt's hacked. Lines 876-888, I commented out the goto lines. It works fine now.
// If user clicks "Users" link while on group home page:
// Using referrer node ID (assuming it's a group)
if ($ref_arg[1] == 'node' && is_numeric($ref_arg[2])) {
$path = "ogusermanage/" . $ref_arg[2];
//drupal_goto($path); // so users can see bio when they click on the author's name in the SUBMITTED BY line
}
// If user clicks "Users" link while on group home page:
// Using og_last
if ($_SESSION['og_last']) {
$gid = $_SESSION['og_last']->nid;
$path = "ogusermanage/" . $gid;
//drupal_goto($path); // so users can see bio when they click on the author's name in the SUBMITTED BY line
}
Comment #4
somebodysysop commentedIt appears I got a little overambitious. What I was doing was creating a situation where, optionally, you could allow group admins to approve new signups. From one point of view, this may seem crazy. But, from the point of view of a large multi-group community, you either have to let any user signup to your site without approval, or have one site admin be responsible for approving all signups to all groups. If you have dozens of groups, and dozens and dozens of signups, this could prove a bit daunting. This is an effort to address this issue. The modification was to allow group admins to approve signups if the user is also subscribing to their groups.
I believe this just got released in version 2.4.
From the OG User Roles: Settings documentation http://drupal.org/node/163567 :
First off, there is a bug. Your URL should not be re-directed to ogusermanage unless you have the "Allow Group Admins to Approve new Signups" setting clicked on. This I have fixed.
Secondly, we have found, as the above blurb points out, that neither oguseredit or ogusermanage are accessible unless you have the "Clear the cache" setting clicked on. Both of these are defined in my module's hook_settings under
... if ($may_cache) { ...If someone knows why they won't work without this cache flush turned on, I'd like to know.
Sorry for the confusion. I just recently documented the problem with oguseredit, but failed to include ogusermange. If I had done so, your search would have turned up this blurb rather quickly.
While you have resolved this problem for yourself, here is a patch which settles it so you don't have to keep patching new releases. It is to be patched against the 5.x-2.4 release of OG User Roles.
Comment #5
cindyr commentedThanks so much! Drupal is really targeted for the large multi-group community like you mentioned, and I've found this presumption a problem in other features as well. I'm using it for a small, closed community, where I'm the only one with ultimate power (ha ha ha) and I know every other person logging in and can set their roles for them. That's ok, I don't mind working around it, as it's been an enormous boon to our school (and maybe my web business in the future!)
Thanks for all your help.
~cindyr
Comment #6
somebodysysop commentedComment #7
somebodysysop commentedPatch included in 2.5 release.
Comment #8
g76 commentedRunning og_user_roles 5.x.2.5, acl, content access, og content type admin, og subgroups. I have og_user roles set for group admins to approve signups and I have the clear cache checked and followed all the instructions on that issue. I am getting redirected to ogusermanage when accessing user profiles or group members own user account. I get this message: "No users have been located for this group or you are not an admin user for this group!"
There are users, they are listed in subscribers, and there is a group admin. Could you assist in pointing me in the right direction to fix this?
Comment #9
somebodysysop commentedThis issue is closed. You need to start a new one for your particular problem. Please include how you are re-directed (what do you click on, and as what user?) Thanks.
Comment #10
a_c_m commentedI'm getting this in 3.3
The user is being redirected to http://.../ogusermanage/14when trying to view a users profile.
Turning off "Allow group admins to approve new signups." fixes it.
Comment #11
somebodysysop commentedThe solution is still the same. Turn off "Allow group admins to approve new signups."
Comment #12
a_c_m commentedAnd what do i do if i wanted to "Allow group admins to approve new signups" ?
Comment #13
somebodysysop commentedSee #9. This issue is closed.
I need to know the exact urls involved, and exactly what clicking on what directs or doesn't direct you to. Right now all of that is very unclear as this issue has been bouncing around.
On a personal note, I think this notion of allowing group admins to approve users was a bad idea, and I am thinking seriously of removing the option.
Comment #14
somebodysysop commentedOK, the attached patch should settle this issue once and for all.
First, it removes the ogusermanage re-direct. It's gone. Hasta la vista, Baby.
Next, it creates (if you have the "administer users" permission) a tab on the OG Members screen called "Manage users". Click on this tab to see the list of users whose accounts you can access.
Finally, it adds a new permission: "no oguseredit". You give this permission to users whose accounts you do NOT want edited by oguseredit (ogusermanage).
See notes on "Allow group admins to approve new signups" usage here: http://drupal.org/node/163572
This should solve everybody's problems with this function, even mines.
This is a cumulative patch. Apply to clean (un-patched) download of OGUR 5.x-3.3.