Support Thousands of Users
Steps
Every account XWiki creates is added to XWiki.XWikiAllGroup as an object stored on that single page, so a wiki with thousands of users ends up with a document carrying thousands of objects, which every registration loads and rewrites: see Performance. XWiki can instead treat every user as a member of that group without storing anything, which is what the setting below turns on.
After this change the group still grants its rights, but it no longer lists its members.
- Open xwiki/WEB-INF/xwiki.cfg in the wiki's web application and turn on the implicit all group. The line is shipped commented out at its default of 0.
#-# Should all users be considered members of XWiki.XWikiAllGroup, even if they don't have an #-# associated object in the group's document? xwiki.authentication.group.allgroupimplicit=1 - Check xwiki.users.initialGroups in the same file, a few lines above. It must not name XWiki.XWikiAllGroup: a new account that is added to the group explicitly writes back the very object this page is removing, one registration at a time. Leaving the line commented out is the right answer, because XWiki then derives the default from the setting above and adds a new account to no group page at all.
#-# The default list depends on the value of xwiki.authentication.group.allgroupimplicit: #-# 0: created users are added to XWiki.XWikiAllGroup group page #-# 1: created users are not added to any group page (but they will virtually be part of #-# XWiki.XWikiAllGroup group) # xwiki.users.initialGroups=XWiki.XWikiAllGroup - Restart the servlet container. xwiki.cfg is read once at startup, so nothing changes until the wiki comes back up.
systemctl restart tomcat10 - Remove the member objects from XWiki.XWikiAllGroup. A handful can be removed from the group's administration screen, where each member row carries a Remove action; thousands cannot, so run the script below as a user with programming rights, on a page you then delete. It reports how many objects it removed.
{{groovy}} def group = xwiki.getDocument('XWiki.XWikiAllGroup') def count = group.getObjects('XWiki.XWikiGroups').size() group.removeObjects('XWiki.XWikiGroups') group.save('Removed the member objects: the all group is now implicit') println "Removed ${count} member objects" {{/groovy}} - Open the group and check that it has no members left while the rights it grants still apply. The member list is empty, and a user who is in no other group can still do whatever XWikiAllGroup is allowed to do.

FAQ
Do rights granted to XWikiAllGroup still work?
Yes, and that is the point of the setting. When XWiki resolves the groups a user belongs to, it adds XWiki.XWikiAllGroup to the answer without looking for an object, and the rights machinery reads that same answer, so every permission granted to the group keeps applying to every user.
Does it cover unauthenticated visitors?
No. XWikiGuest is excluded from the implicit membership, exactly as it has no member object in the explicit case. A right that should reach readers who are not logged in has to be granted to XWikiGuest, or to the wiki as a whole.
Does it cover users from another wiki in a farm?
No. The implicit membership only applies to users of the wiki being read, so on a subwiki the global accounts defined in the main wiki are not implicit members of that subwiki's XWikiAllGroup. A farm that grants rights to a subwiki's all group has to keep adding those users explicitly, which also means this setting saves nothing there.
Why does the group show no members now?
Because the member list is built from the objects on the group page, and the implicit membership is not one of them. Nothing in the interface knows the group is implicit, so the group's administration screen, the member count in the groups list and the group picker all read zero. That is the trade: the cost of storing thousands of objects, against being able to see and edit who is in the group.
Can the setting be turned back off?
Setting it back to 0 and restarting restores the ordinary behaviour, but it does not bring the deleted objects back, and a group with no members grants nothing to anybody. Going back means re-creating a member object per user, which is why the export in step 4 is worth taking.