I’m opening this thread because I started to discuss a bit on the chat with the other developers about the membership feature of sub-wikis: the fact that you can configure a sub-wiki to allow users to join, or to request admin authorization for them to join etc. This feature is documented on https://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki%20Application#HHowtojoinawiki.
We would be interested to know how this feature is actually used in real life: so it would be great if you could share your usages of that feature.
For a bit of context, we started to discuss it after discovering a bug around it: Loading....
I came across the following use case in a project:
All users are global and can be invited to join a subwiki by a subwiki admin or by a global admin.
User profile pages are viewable only by users who belong to at least one common subwiki, and can be edited by the admins of the subwiki(s) they are member of.
Each subwiki descriptor can be seen only from the subwiki members.
On the main wiki, users can see the latest changes that occurred on the subwikis they’re member of.
The way I implemented the second item consisted in creating automatically two global groups on each subwiki creation: one MySubwikiAllGroup and one MySubwikiAdminGroup, and in adding those two as subgroups of the local XWikiAllGroup and XWikiAdminGroup (because rights on the main wiki can refer only to global groups or users). Currently checking if I can share as a snippet the code of the ServiceComponent implementing this use case in case it can be useful.
The “membership” of a subwiki is something that will make sense in many cases: very often a subwiki is created / associated to a unit in a company / team (sales has a subwiki, infra has a subwiki, tech has a subwki), so, very often, there will be a group of actors (users) that would be associated to that unit. This is where the membership concept as a logical unit makes sense: are you sales, are you tech, are you both? So this is where I use it / advise to use it. Whenever these teams need to be named collectively in the wiki config / implementation, the local XWikiAllGroup comes in handy as it already exists and can be used. If these teams never need to be named collectively (for example for subwikis that are structured differently and don’t have this concept), this feature is confusing.
Then, as @slauriere said, in many cases it doesn’t make sense that this logical unit is defined at the level of the subwiki and not visible for the other wikis, as these logical units usually make sense to be known everywhere, so this reduces a little the number of cases where the impl. of the membership as a local group is useful.
Now, the other question you’re asking is whether the wiki membership management makes any sense (join, invite, etc.). This could be extracted as an extension and made more generic, since it’s about managing the membership of a group. This feature is the only one that allows to manage the membership of a group on the initiative of a user and communicate with the admins about this on the wiki (request, join, invite) - even if this is badly done today as it doesn’t send proper notifications to admins/users, as far as I know. This could be expanded to all groups of XWiki, enabling invitation / request for any group in the wiki, and activating it for the local all group of the subwiki would be just a particular case for it.
Ok I do understand conceptually the idea: you have subwikis defining business units and people belongs to each unit so it makes sense. Now, I’m failing to understand how right now it’s usable. I mean, as you said yourself: right now there’s no global view for being able to properly see this. Also the rights are not working properly for that usage if I’m correct.
I’ve the feeling that even for that UC I’d use groups defined at main wiki level so that I can organize the groups globally at a single place and then define in each subwiki the rights based on those groups.
There are no correct rights for that usage, the rights are what you want to make them. The local all group & join feature will only help you identify & fill in the group, but not impose the rights.
I don’t even remember what are the default rights of a subwiki if you don’t change anything, at some point I think it was only the members that had edit, while everyone had view, but I am really not sure.
That works also, for some cases (but not for all). Notably, if you do so, the local subwiki admin doesn’t have rights to edit their own wiki’s members group, unless someone gives it explicitly, specifically on that group on the main wiki (oherwise it’s just the global admin). So this is the advantage that you have in having the members group local. @slauriere’s example is quite interesting as it allows both: getting the groups from a global group that is a subgroup and adding users locally, but it makes the whole “unit” of people a little harder to identify. If groups are synchronized with some roles from an external identity server then yes, you probably need them on the main wiki and you don’t care that local admin cannot edit it.
Another usecase I have is when you have wikis per project, not per team, and you need to compose the groups of people involved in a project from 2-3 teams projects, for example. In that case, a group that is ‘dedicated’ to a subwiki (that wiki’s people) comes in handy, as a role.
As I said, all these usecases can be manually implemented without the XWikiAllGroup being predefined at the local level or global (one could define their own group for this role, and only if they need it).
Well, when using an external user provider like LDAP or OIDC I just map the user groups in there to XWiki groups. And give that xwiki groups specific rights on specific sub-wikis. So the concepts of mapping business units are completely solved via external authentication providers, too.
Voila. No need for subwiki admins to play around with local groups (most times). So it ends up again with: Whats the UC of wiki membership compared to just give access rights via groups? Even there is a membership into a wiki admins must give specific rights. Just with a membership you see nothing in subwiki or can edit/create content.
Ok, but following to this discussion(s): I can completely ignore this feature in our environment.
I think I forgot to mention one important usage here: the fact that this group of members is always called XWikiAllGroup, on all subwikis, regardless of what it contains, makes it easy (and possible at all) to ship configurations (rights or features) as xar packages that give access to those things to this role (same for admin). Otherwise, if we’d have a global group dedicated to each subwiki, everytime with a different name depending on the subwiki, it would be impossible to build a subwiki flavor, for example, with default rights for all “members”, since the name of the group of members would be different each time.
Now, I totally agree that this doesn’t need to be a feature of the platform, it can be implemented on top, as a feature of the flavor in question that needs to ship such feature.
Hi, just gave a quick read about this as I still haven’t started to differentiate our subwikis - we have a single instance where every content is collected.
But we may easily fall in this one.
I say we may because we’ll probably have tech team and non-tech team (aka everyone else): the former will have access to tech-reserved pages that others will be forbidden to even know about their existence.
I don’t know if the best practice would be to have a tech-subwiki and non-tech-subwiki, while keeping the main wiki for administration purposes only, or maybe dedicate the main wiki to the non-tech team and the subwiki for the tech team - if this is already covered in a guide, that’s fine.
Just wanted to highlight the case of an external provider: neither in our wiki people register or similar, everybody comes from our LDAP and is assigned to custom groups depending on LDAP-props.
Moreover, we will probably have application-based teams, such as people working on our planner application (let them be sales, administration, user support, etc.) may need to edit pages, other people will just be able to read them - but this is handled by manually adding people to a custom group (e.g. PlannerUsers) - so it’s probably off topic here.
There is not really a good practice here, it all depends on your need and on your content. The options that you have are to either keep the content for tech in a subtree of the main wiki and set rights on that subtree or isolate everything in 2 separate wikis. In both cases you can set rights and make look and feel configuration to isolate that tree from the rest of the content, although it’s much much more frequent to use a different look and feel for a subwiki than for a tree of pages. Having 2 separate wikis (2 subwikis or main wiki and subwikis) also allows you to install and configure different applications for the 2 subwikis, and there will be some impact in the default search (which will be scoped to the subwiki, at least when searching from a wiki - you can configure it otherwise but this would be the default). Also, other parameters of XWiki - the things you find in the wiki administration - would only be available for a subwikis configuration and some are not inherited and you may need to redefine for the subwikis (e.g applications, page templates).
This is exactly the type of case where the concept of subwiki member applies easily.
If you have a subwiki dedicated to the planner application related content (along with the tools installed & configurations made to make it easy for people that work on this documentation) then you implicitly have the concept of “members of the planner project”. On the planner subwiki, you’d give read access to everyone with an account and reserve the edit right for the “members of the work group of this app”. Then, you fill in this members group with whatever you want (manually, or with a subgroup from the main wiki that you then sync with LDAP). This schema would apply exactly the same for all applications for which you’d need to work on documentation, each with its dedicated space of content.
Note that this above is not the only correct way to do it, it is one possibility of organizing, there are many other that will work, as I said above, it all depends on your content and your needs and unfortunately, in some cases, you can’t even know from the start what’s the best, the needs will change half way in.