Well, that said, it could be interesting to keep this up for 6.x. Currently, the way XWikiAllGroup has been optimized is far from optimum, and we may when to keep the current thread when we look back at it. Le lundi 27 janvier 2014, Guillaume "Louis-Marie" Delhumeau < [email protected]> a écrit :
Hi.
We have eventually noticed that the bug we tried to fix was invalid (see: http://jira.xwiki.org/browse/XWIKI-9886 ).
I have not even tried to reproduce it, I just relied on the description.
I won't do it again, I will always try to reproduce the bug before doing anything else.
I am sorry for having disturbed you with this thread and I feel ashamed.
Louis-Marie
2014-01-25 Sergiu Dumitriu <[email protected] <javascript:;>>
Why not actually fix the problem instead of adding unexpected implicit behavior?
Proposal:
pseudocode for "is a user in a group": if the group name is XWikiAllGroup and XAG is configured as virtual and the user is local, then return true otherwise, check the standard way, with the object attached to document verification
The fact that XWikiAllGroup is configured as virtual doesn't mean that it suddenly becomes an intangible document.
On 01/21/2014 01:52 PM, Denis Gervalle wrote:
Hi Guillaume,
I am definitely -1 to systematically replace XWikiAllGroup by XWikiMemberGroup in any subwiki:
1) because I do not see the meaning of XWikiMemberGroup in the myxwiki.orguse case. 2) because XWikiAllGroup is an habits for many existing user 3) because existing application/extension/scripts may attribute rights to XWikiAllGroup 4) because this could cause confusion if some right are attributed to XWikiAllGroup and others to XWikiMemberGroup, by a mixup of old and new habits.
Since we definitely want to use implicit XWikiAllGroup, I do understand that you need a solution for workspace that may be joined by global users. The below proposal should allow you to do so without migrating existing installation. It apply only to subwikis.
After thinking about the different possibilities, my best bet to a smooth migration is to keep XWikiAllGroup for its previous meaning: "All authenticated users having access to this wiki" (unless implicit, which restrict it currently to "All Local Users"). Keeping the meaning and potential usage of the group is the key IMO.
To support selected global users to enter the implicit XWikiAllGroup, I simply suggest to add implicitly a group as a member of XWikiAllGroup. It could be called XWikiGlobalMemberGroup to be more explicit, and always be a member of the implicit XWikiAllGroup when xwiki.authentication.group.allgroupimplicit=2. Then:
A) when xwiki.authentication.group.allgroupimplicit=0, and XWikiAllGroup (not implicit) does not have a member XWikiGlobalMemberGroup. Do not do any migration, and keep the current join behavior, using exclusively XWikiAllGroup for both local and global users.
B) when xwiki.authentication.group.allgroupimplicit=1, keep the existing behavior, obviously prevent any global user to join, do not provide global user scope in wiki creation, and warn on the wiki setting if the user scope is incompatible with the current implicit setting.
C) when xwiki.authentication.group.allgroupimplicit=2, check at startup that a XWikiGlobalMemberGroup exists, else create it and migrate any global users in XWikiAllGroup to XWikiGlobalMemberGroup.
D) when xwiki.authentication.group.allgroupimplicit=2, or when xwiki.authentication.group.allgroupimplicit=0 and XWikiAllGroup contains XWikiGlobalMemberGroup, use the new behavior, allowing creation of all user scopes, removing any warnings, joining global users to the XWikiGlobalMemberGroup (and local users to the XWikiAllGroups if not implicit).
The net benefit of the above proposal is to keep actual habits and existing use cases untouched. Moreover, the security is ensured to be kept as it is with no risk of side effect, which is priority.
WDTH ?
Obviously, my +1 for the above proposal. Thanks,
On Tue, Jan 21, 2014 at 6:50 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
2014/1/21 Guillaume "Louis-Marie" Delhumeau <[email protected]>
Just to add some precisions:
-- Denis Gervalle SOFTEC sa - CEO