5 Jan
2015
5 Jan
'15
9:38 a.m.
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 <guillaume(a)xwiki.com>
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 <lucaa(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs