[xwiki-devs] Ownership of the metadata about the subwiki

Hello devs, = Short story = Since the metadata about a subwiki (pretty name, description, users scope) are in the middle between main wiki and the subwiki (are used on both), who should have the last word about this data? Global admin of the farm of local admin of the subwiki? = Long story = while looking at http://jira.xwiki.org/browse/XWIKI-11416 , we came across a couple of questions about what is a subwiki and who "owns" (controls) the metadata about it. It all started with the fact that XWIKI-11416 would imply allowing the local admins of the subwiki (potentially local users) to edit information which is stored on the main wiki. There are 2 important things to discuss about this requirement: A. 1/ it is important that the metadata about a subwiki can be controlled by the local admin group, or another _group_ of people. The owner of the wiki is not enough, as owner is not a role and can only be fulfilled by one person, which is limiting in terms of collaboration. 2/ the wiki description and pretty name are stored on the main wiki today, in the wiki descriptor, while information about the user scope and membership are stored on the subwiki. This was changed recently, when the wiki concept was revamped and integrated with workspaces, in 5.3 (before that, everything was on the main wiki). A 2/ takes us to the main question of this mail: who is responsible / should should be responsible for the information about a subwiki? One direct consequence of this answer is the storage of this data, but the implications are larger than that because they can define the usecases that we support for the new wikis (as they are defined by the new implementation from 5.3). This question arises because this metadata is quite tricky as it represents the relation between the main wiki and the subwikis, so it could be considered that both main wiki and subwikis have priority on it. Please express your opinion about the following approaches, both as a general guideline, and in particular in the context of the 5 items from the descriptor that we're discussing: pretty name, wiki description, membership type, user scope, owner. B 1/ the global admin must be able to control the data about the subwikis, regardless of the opinion of the local admins 2/ the local admins should be free to configure the data about the subwikis, without the global admin controlling these settings. Note that this is already the case for wiki rights, by construction of the wiki, and recently this was chosen for user scope and membership type by storing them on to the subwiki in 5.3 3/ both approaches should be possible, depending on the type of farm we make (farm of wikis with subwikis with local users which don't know one about the existence of the other wikis, a la myxwiki.org or farm of wikis where users can create wikis of their own, workspaces style) 4/ both approaches should be possible, depending on the type of wiki, which should be decided by the global admin (on the same farm we could have some wikis on which global admin decides this metadata and some wikis on which local admins decide it) Note that B 3 and 4, in my opinion, have consequences on the type of wikis that we want to make _by default_ (with customization everything will be possible): UC 1 : farm where the wikis are handles as dedicated spaces for collaboration inside the same community, the users all know about the existance of all wikis (workspaces style) UC 2 : farm where the users don't know about the existance of the other wikis, where every subwiki is independent, like an XWiki instance without subwikis, they are just managed by the same farm, for various reasons ( myxwiki.org style, cloud mode, real "farm" mode, the pre-workspaces way of making subwikis). Please comment on these items, from a conceptual point of view. Thanks, Anca P.S. we also discussed a couple of implementation details today, with Denis, Eduard and Guillaume D: * allowing local admins to change data that is stored in a document on the main wiki is problematic because it would mean to code a modification a document which would bypass the rights system, which is not generally a good idea, we should model this by using the regular rights system (the users that must be able to edit the descriptor should be able to have edit rights on it) * normally storing data on the subwiki is problematic because of the performance issues that arise when using this information on the main wiki (it's not possible to fetch it with a hql query). BUT the wiki manager implementation has a cache where this data can be stored so that it's not always looked up on the subwiki when needed on the main wiki. This cache, while quite limited today, can be improved to answer whatever filtering needs.