Description
Hi Loris,
That is a bug. When browsing / searching in 'My memberships' the code calls
member.getGroups() and checks whether the 'result' is in the result set.
Unfortunately, if the logged in user does not have READ access to the group, the API filters the result set so no match is possible. I've had a quick go at fixing it but without any luck.
Chris: In MyMembershipsRepositoryBrowser (HEAD) I've changed the method
below:
protected Map getValidStems() throws Exception
{ Map validStems = savedValidStems; if(validStems !=null) return validStems; Set groups = null; GrouperSession s = GrouperSession.startRootSession(true); Subject curSubj = getGrouperSession().getSubject(); Member member = MemberFinder.findBySubject(s,curSubj); groups = member.getGroups(); s.stop(); return getStems(groups); }so that I start a root session, however, member.getGroups() doesn't use that session - it still uses the session of the logged in user. Any ideas?
Gary
--On 12 March 2009 10:43 +0000 "Dr. Loris Bennett"
> Hi,
>
> I have a user who is a member of two groups: "read_only" and
> "view_only". In the first, the user has read permission only, in the
> second, view permission only.
>
> If the users explores to the folder containing the two groups, both
> are displayed, but only "read_only" has a link "manage members". This
> is OK, although it would be nicer if the link were labelled "view
> members" in this case.
>
> However, when the users clicks on "My Memberships, only "read_only" is
> displayed. Surely both groups should be displayed here, too?
>
> Cheers
>
> Loris
>
> –
> Dr. Loris Bennett (Mr.)
> Freie Universität Berlin
> ZEDAT - Zentraleinrichtung für Datenverarbeitung / Computer Center
> Compute & Media Service Fabeckstr. 32, Room 221
> D-14195 Berlin
>
----------------------
GW Brown, Information Systems and Computing