[xwiki-devs] [Proposal] API breakage or changing a behaviour ? (Inclusion of groups in groups)
27 Jun
2013
27 Jun
'13
10:23 a.m.
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
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.
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(),
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/
or
3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff there.
Thanks for your help!
Louis-Marie
27 Jun
27 Jun
12:06 p.m.
Hi Louis-Marie,
I would rather go for 1) as I believe this is what these methods should
really do, and I don't see any real use case where I would want to have the
former behavior.
Cheers,
Thomas
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
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.
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(),
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/
or
3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff there.
Thanks for your help!
Louis-Marie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:09 p.m.
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 ?
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() ?
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
12:21 p.m.
Hi Denis, thanks for your answer.
2013/6/27 Denis Gervalle <dgl(a)softec.lu>
Sorry, I don't understand your question.
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
On Thu, Jun 27, 2013 at 10:23 AM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
You are right. The problem seems more complex having the fact groups and
members can be in different databases...
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 ?
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() ?
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.
12:54 p.m.
On Thu, Jun 27, 2013 at 12:21 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
this
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi Denis, thanks for your answer.
2013/6/27 Denis Gervalle <dgl(a)softec.lu>
returns
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."
On Thu, Jun 27, 2013 at 10:23 AM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
You are right. The problem seems more complex having the fact groups and
members can be in different databases...
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 ?
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 the
groups of a member.
Not sure I follow you here, isn't this method being XwikiGroupService#
getAllGroupsNamesForMember() ?
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, 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.
Same remark as 2), and we could do it with 2) ... or not. I am not sure
of
or
3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff
there.
my position on this right now.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
1:57 p.m.
2013/6/27 Denis Gervalle <dgl(a)softec.lu>
result.
list
--
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.
Regards,
Louis-Marie.
On Thu, Jun 27, 2013 at 12:21 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
is
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.
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,
> 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
returns
declared members of that group.
But we can modify this method to also returns the members of the
subgroups,
> by changing XwikiGroupService#getAllGroupsNamesForMember(), which the
groups of a member.
Not sure I follow you here, isn't this method being XwikiGroupService#
getAllGroupsNamesForMember() ?
>
>
> > 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.
this
> one could be really doing a lot of computing for a simple boolean 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, > 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 > 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.
Same remark as 2), and we could do it with 2) ... or not. I am not sure
of
or
3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff
there.
my position on this right now.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
4:22 p.m.
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>
XwikiGroupService#
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
result.
information
IMO.
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 ?
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 getAllGroupsNamesForMember() ?
Sorry, I don't understand your question.
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 > 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 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 > >
> >
> > > 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
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
Regards,
Louis-Marie.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
4:33 p.m.
On Thu, Jun 27, 2013 at 4:22 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
--
Thomas Mortagne
On Thu, Jun 27, 2013 at 1:57 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Yes I doubt adding a method in this interface would be a real breakage
in practice.
2013/6/27 Denis Gervalle <dgl(a)softec.lu>
XwikiGroupService#
of
information
IMO.
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 ? 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 >
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 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 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 > >
> >
> > > 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
Regards,
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
12:20 p.m.
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
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.
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(),
XWikiGroupService#getAllMembersNamesForGroup(),
XWikiGroupService#getAllMatchedMembersNamesForGroup(),
XWikiGroupService#countAllGroupsNamesForMember() and
XWikiGroupService#countAllMembersNamesForGroup()
-1 this is a very big change and a very old API (1.1.2) and I'm sure
there is code counting on this behavior.
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/
or
3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff there.
Thanks for your help!
Louis-Marie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4/ Continue the work on http://jira.xwiki.org/browse/XWIKI-6068
(feature-users branch)
--
Thomas Mortagne
10:55 p.m.
Hi Guillaume,
I also needed this behaviour, and what I did was to write it in an
overloaded version of getAllGroupsNamesforMember, with 2 extra
parameters (that allowed to control whether it should look it up
recursive and whether to stop on local wiki or go global), and which was
copying the behaviour of the old rights service, it was even using the
same groups cache that the rights service was using.
I planned to contribute this function as part of the API, but I didn't
get the time and I would say now it's obsolete as the authorization
module has changed.
I think a function that gives the list is more interesting than a
function that only says if the user is a member or not, you can easily
compute the latter from the former but not the other way around.
So I would be for 2/ but with a different function,
getAllGroupsNamesForMember() with 3 parameters.
Have fun,
Anca
On 06/27/2013 08:23 AM, Guillaume "Louis-Marie" Delhumeau 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
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.
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(),
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/
or
3/ Only change XWikiUser#isUserInGroup() and do the recursive stuff there.
Thanks for your help!
Louis-Marie
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4135
days inactive
4135
days old
9 comments
5 participants
participants (5)
-
Anca Luca -
Denis Gervalle -
Guillaume "Louis-Marie" Delhumeau -
Thomas Delafosse -
Thomas Mortagne