I’m about to write an extension to the SelfService interface (4.4.1), so that unprivileged users which are in a specific group can see tickets based on their customer ID in a custom field. At the moment the SelfService interface is limited to tickets for which the user is a watcher.
The problem I’m facing is that the standard RT::User->OwnGroups function doesn’t return any group names of the groups an unprivileged user is member of. On the other hand if I access the SelfService interface with a privileged user, I get his groups. I tried to find out, whether there’s a condition in RT::Groups, so that groups are not returned for unprivileged users, but I couldn’t spot such a condition.
This is what I included in an overlay just for a test:
# local/html/SelfService/Elements/MyRequests
my $Groups = $session{‘CurrentUser’}->OwnGroups;
print "Groups found: " .$Groups->Count . “ ”; # Always prints the number of the groups the user is member of
while ( my $group = $Groups->Next ) {
print ‘Group: ‘.$group->Name.’ ’; # Prints nothing for unpriv. user, and actual groups for priv. user
}
I took all necessary actions when testing, like re-login after group changes, reloading the cache and apache after template changes, etc.
PS: I’m aware of RT::Extension::CustomerGroups, but this is not exactly what we need, because we still need the original Requestor/Cc to be in the ticket, not getting replaced by a group.
Take a look at share/html/Admin/Elements/MembershipsPage as this seems
to do
a lookup of what groups a user is a member of it includes unprivileged
users too.
yes, that user is in a user defined group (verified by members of the group, as well as user group memberships). I added him to another group, just to make sure it’s not a special condition that only happens when the user is in only one group, still no success. The count of the groups found by my piece of code (print “Group found…”) matches the count of the user definied groups the user is in. So it actually finds groups, but it seems as if the Groups (hash) is sanitized for unprivileged users.
I know this is rather late on this old thread, but I’ve just hit something similar. I ended up diving into the code (hoorah for open source!) and I think the issue may that the your unprivileged users (and in my case privileged users due to our ACL set up) don’t have the “SeeGroup” right. In the RT::Groups module the AddRecord() method specifically checks this ACL, or an internal flag called “with_current_user”. Elsewhere in the module there’s another (undocumented?) method called WithCurrentUser() that sets this flag.
If this is still an issue (or others have similar problems), try something like this:
use RT::Groups;
my $groups = RT::Groups->new($session{'CurrentUser'});
$groups->WithCurrentUser();
$groups->LimitToUserDefinedGroups();
while (my $group = $groups->Next()) {
warn "Group: " . $group->Name . "\n";
# Do exciting application specific group membership stuff in here!
}
In my code I was only concerned with membership of some user defined groups which is why the LimitToUserDefinedGroups() call is in there. Remove that and you get all the Owner, Requestor, etc group memberships too.
So question for the Best Practical RT developers: is WithCurrentUser() a naughty internal method I shouldn’t be using, or is it just overlooked in the documentation for RT::Groups? Seems quite handy to have in situations like this (I’m using it for making some custom self-service canned request forms). If its up for grabs, I’d vote for “document it” please!
Hey GreenJimll,
in some cases it can’t be too late. In this case this seems to be the solution. I will have to check if there’s any other implication on what the users can see with the SeeGroup right (i.e. other groups they are not member of), but this seems to be the solution to my question.