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
