This is a very interesting usecase, Guillaume, because it goes a bit "against" the idea that the wiki admins should have the rights to change the settings of the subwikis. So this shows that we need to describe properly the usecases, and potentially choose between "old wikis" usecases and "workspaces" usecases.
Let's keep the discussion going, how do you guys feel about this? Who does this data belong to? Thanks, Anca On Mon, Dec 22, 2014 at 9:35 AM, Guillaume Lerouge <[email protected]> wrote: > Hi, > > I've recently met this issue on a 6.3 instance. I wanted to set it up so > that each sub-wiki would be independent from the others (local-users only). > Users and admins that are local to a wiki should NOT know that there are > other wikis on the farm. > > As expected, when creating a wiki and selecting local-only users, the 3 > possible wiki types were greyed out since they don't make sense in that > configuration. However, I discovered that local users that have the admin > right on a sub-wiki still get access to the "Users" section of the > administration, where they can... change the wiki type. > > Since they're only local users, that does not cause a security issue - they > still cannot see any other wiki on the farm. However, it doesn't make sense > letting the local admin change that setting: the only thing they can do is > mess things up. > > One solution in my case could be to switch to the old wiki-only wiki > manager, without workspaces, but I'm not 100% sure that's what we want to > do? In that case, why should we permit workspaces with local-users only in > the first place? > > Thanks, > > Guillaume > > On Tue, Dec 16, 2014 at 8:21 PM, Anca Luca <[email protected]> wrote: > > > > 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. > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
