On Thu, Jun 27, 2013 at 1:57 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
2013/6/27 Denis Gervalle <dgl(a)softec.lu>
On Thu, Jun 27, 2013 at 12:21 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> Hi Denis, thanks for your answer.
>
> 2013/6/27 Denis Gervalle <dgl(a)softec.lu>
>
> > On Thu, Jun 27, 2013 at 10:23 AM, Guillaume "Louis-Marie" Delhumeau
<
> > gdelhumeau(a)xwiki.com> wrote:
> >
> > > Hi devs !
> > >
> > > In order to fix
http://jira.xwiki.org/browse/XWIKI-2900, I have
some
> > > proposals to you.
> > >
> > > The problem is : the Inclusion of groups in groups aren't taken
into
> > > account when querying user
memberships.
> > >
> > > Let suppose we have the following use case:
> > > User 1 inside the Goup A
> > > Group A inside the Group B
> > >
> >
> > Aren't you missing the use case of a user/group of the main wiki
being
a
> > member in a local group of a subwiki ?
> >
>
> You are right. The problem seems more complex having the fact groups
and
> members can be in different databases...
>
>
> >
> >
> > >
> > > The actual behaviour of XwikiGroupService#
> > > getAllGroupsNamesForMember() when calling it with "User 1" as
input,
is
> > to
> > > return "Group A" only. Because, only "Group A" has
actually a
member
>
called
> > "User 1".
> >
> > We might want to keep this behaviour, because we may need to have
only
> > the
> > > declared members of that group.
> > >
> > > But we can modify this method to also returns the members of the
> > subgroups,
> > > by changing XwikiGroupService#getAllGroupsNamesForMember(), which
> returns
> > > the groups of a member.
> > >
> >
> > Not sure I follow you here, isn't this method being
XwikiGroupService#
getAllGroupsNamesForMember() ?
Sorry, I don't understand your question.
I rephrase it as I read it (and don't understand it):
"But we can modify XwikiGroupService#getAllGroupsNamesForMember() [was
this method] to also returns the members of the subgroups, by changing
XwikiGroupService#getAllGroupsNamesForMember(), which returns the groups
of
a member."
Sorry, it was not clear. What I was trying to describe is the proposal 1/
that I wrote after.
>
>
> > Other solution, adding a new method:
> > boolean isMemberInGroup(DocumentReference memberReference,
> > DocumentReference groupReference)
> >
> > which only check if the user (or the group) given on the input is a
> member
> > of the group or not.
> >
> > But it's an API breakage.
> >
> > So my proposal is:
> > 1/ Changing the behaviour of
> > XWikiGroupService#getAllGroupsNamesForMember(),
> > XWikiGroupService#getAllGroupsReferencesForMember(),
> >
>
> This one is used by the userBridge of the security authorization
module.
> The module do its own recursion to get
transitive groups (both local
and
global).
We may imagine others do that also, so breaking this is not
acceptable IMO.
> XWikiGroupService#getAllMembersNamesForGroup(),
> XWikiGroupService#getAllMatchedMembersNamesForGroup(),
> XWikiGroupService#countAllGroupsNamesForMember() and
> XWikiGroupService#countAllMembersNamesForGroup()
>
> or
>
> 2/ Adding isMemberInGroup(DocumentReference memberReference,
> DocumentReference groupReference, XWikiContext context) in
> XWikiGroupService, which is an API breakage, and my Pull Request :
>
https://github.com/xwiki/xwiki-platform/pull/117/
>
For user/group belonging to large amount of groups and deeply nested,
this
> one could be really doing a lot of computing for a simple boolean
result.
> It would be nice to cache the membership of
user to efficiently reply
to
> > such request, else using this fonction in a loop would be really
> > inefficient. Note that the SecurityCache already cache such
information
but
> do not release it. It could be a possible way to easily fix that
> performance issue.
>
> So, having just that one is not nice, and being able to retrieve the
list
> of all group a user belong too, choosing if
we want recursion or not,
and
> > if we want a mix of local and global group or not, is a must have
IMO.
> >
> >
> > > or
> > >
> > > 3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff
> > there.
> > >
> >
> > Same remark as 2), and we could do it with 2) ... or not. I am not
sure
of
my position on this right now.
>
> Thanks for your help!
>
> Louis-Marie
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/devs
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Actually, the best option we have seems to be what Thomas M. has suggested:
implement
http://jira.xwiki.org/browse/XWIKI-6068.
For sure, but that is not an easy one. In the mean time, we may consider
adding some methods to the group service API. The argument of Vincent about
breaking is right, but I doubt many have ever implement that interface.
Vincent, have you some examples ?
Regards,
Louis-Marie.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs