4 Jun
2010
4 Jun
'10
11:12 a.m.
Hi Denis,
2010-06-04 09:55, Denis Gervalle skrev:
I will wait with implementing the "compliancy mode" for this space
parent relation, as it is a bit more complex than seems worthwhile.
/Andreas
Hi Andreas,
On Thu, Jun 3, 2010 at 23:59, Andreas Jonsson<aj(a)member.fsf.org> wrote:
To start with, I will aim at making it backwards compliant so it can
substitute the current implementation. But changing policies on how to
resolve the rights is straightforward. The basic design consist of four
components: API adaptor, cache, loader, and resolver.
The cache and the loader are very generic and should work even if
additional rights are added or the resolution policy is altered.
After I have completed the implementation I will make some proposals on
changing the default behavior. I have thought of two things up to now:
1. Continue upwards in the document hierarchy searching for a right
object until one that matches both the right and user or one of the
groups is found, instead of stopping at a level where a right object
that matches only the right, and then defaulting to deny if the user or
groups was not mentioned by the rights object. This is the same issue
as you mentioned.
2. Make the delete right default "allow for creator" and deny for others
so that it is overridable by an explicit deny. The current behaviour is
allow for creator up-front, which makes it impossible to override.
Hi,
I have almost finished writing a new right service implementation and
have some questions about nested spaces.
This sounds really good. Is it going to be a change compare to the past?
What will be the proposed compatibility mode ?
Are you removing the current behavior that deny rights to other user/group
when an allowance has been found locally for a given user/group ? Is there
some improvement to allow additional rights ?
I am using the
EntityReference classes for representing the document
hierarchy, with the addition for using the main wiki as the parent of a
virtual wiki.
+1
XWikiRightServiceImpl is using the parent field
in the space's
preferences to form a space hierarchy. The EntityReference classes
support a list of spaces, but this does not seem to be implemented
yet.
Can a right service implementation assume that
the nested space
hierarchy was resolved externally and was inserted into the
DocumentReference as a list of spaces?
Will the list of spaces in an EntityReference correspond to following
parent fields in the space preferences or does a right service
implementation need to resolve these parent fields for backwards
compliancy?
The hierarchy of space has never been documented and is disabled by
default.
IMO providing the old behaviour is useless, but could be nice to have since
it should be easy to do and the xwiki.cfg parameter is already available to
trigger it or not (default is disabled already). Assuming the reference will
contains the whole hierarchy is correct (if compliance mode is disabled),
the implementation of the space hierarchy will have to ensure that document
with different space hierarchy are different documents anyway.