Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

[Denis Gervalle]

Hi Sergiu,

On Tue, Apr 12, 2016 at 3:19 PM, Sergiu Dumitriu  wrote:

> Perhaps [1] is what you're looking for.
>
> XWiki's security mechanism [2] is tightly bound to internally stored
> rights, and changing its code allows only minor cosmetic alterations to
> the decision process.
>

This is a bit harsh. You seems to have missed an important goal of the
rewrite of the right system I did.

Available since version 4.x and integrated in XWiki 5.0 and later, our
complete rewrite of the security authorization module allows custom
definition of new rights, full customization of the authorization decision
process, and is almost entirely disconnected from the XWiki platform (the
only reason it is not in commons, is just the EntityReference related
stuffs). The new module not only provide several entry points for
customization, it also provide a very efficient security cache.

The new module is articulated around the AuthorizationManager which provide
a very generic authorization checking interface, SecurityRules that provide
a generic definition of security access rules, and an AuthorizationSettler
which is pluggable and responsible for all final decision. Injecting rules
into the system could be done by reimplementing a different
SecurityEntryReader, but if you want, you may as well benefit of all the
infrastructure provide by the wiki while managing rights in a very
different manner simply by providing a different authorization settler.

PhenoTips' "authorization" mechanism [3] makes things extremely modular:
> you're free to implement as many modules you want, and each module is
> free to decide in whatever way how rights are given. All you have to do
> is write a component that implements AuthorizationModule [4]. All
> available modules are active, and they're chained based on their
> priority [5]. The authorization manager service [6] calls each module in
> the descending order of their priority, asking them [7] if a specific
> action is allowed or not. When asked, each module can either allow
> (return True), deny (return False), or take no decision and defer to the
> following modules (return null).
>

This seems to be about allowing to have several authorization managers. It
would be interresting to see why you felt you needed that.
It would have been nice to bring the subject on the mailing list before
doing it on your side since it seems to be simple enough to be integrated
in standard if really needed.


> The two already implemented modules defer to XWiki's classic security
> module [8], and take a default (configurable) decision to either allow
> or deny all so far undecided calls [9]. However, if [8] is active in the
> system, [9] will never actually be reached, but it is still useful if
> you decide to remove XWiki's rights altogether.
>
> The "bridge" [10] registers this modular authorization mechanism with
> XWiki, so that it is called instead of the current XWiki security
> mechanism. All you have to do is set [11] as the rights class in xwiki.cfg:
>
>
> xwiki.authentication.rightsclass=org.phenotips.security.authorization.ModularRightServiceImpl
>

Hopelessly, this is wrong. This configuration option is deprecated since
XWiki 5.x, and should no more be used to hook the XWiki authorization
system. Here is the excerpt from the configuration file:

#-# (Deprecated) The authorization management class.
#-# [Since 5.0M2] The default right service is now
org.xwiki.security.authorization.internal.XWikiCachingRightService
#-# which is a bridge to the new security authorization component. It
provides increased security and performance, but
#-# its right policies differ sightly from the old Right Service
implementation. In rare situation, you may want to
#-# switch back to the old unmaintained implementation by uncommenting the
following line. However, only old
#-# implementation, still using a bridged RightService will be impacted by
this parameter. Customization of the new
#-# security authorization component should be done in the new
xwiki.properties configuration (security.*).

While in XWiki 5.x, most of the xwiki services were still using the old
RightService, and so you were capturing more than 90% of the security
checks, as more time and version passes, you are capturing less and less of
these call, and in a future I do not expect too far, none of them. The new
component use for security authorization checks is now the
ContextualAuthorizationManager, which is a context based version of the
AuthorizationManager, and more and more XWiki components are now targeting
those two components directly, fully bypassing the legacy XWikiRightService
interface.

Therefore, by no means, you can really capture the authorization service
using the above configuration change.


>
> Based on this mechanism, we have several modules that deal with specific
> rights restrictions:
>
> [12] allows to lock a document, preventing all edits, even from
> administrators, until the document is unlocked 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Vincent Massol]

> On 12 Apr 2016, at 16:18, Marius Dumitru Florea 
>  wrote:
> 
> On Tue, Apr 12, 2016 at 5:12 PM, Thomas Mortagne 
> wrote:
> 
>> On Tue, Apr 12, 2016 at 4:09 PM, Vincent Massol 
>> wrote:
>>> 
 On 12 Apr 2016, at 15:43, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
 
 On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol 
>> wrote:
 
> Hi Marius,
> 
>> On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>> 
>> Hi devs,
>> 
>> We need to decide what is the expected link reference serialization
>> produced by the WYSIWYG editor when you create a link to a wiki page.
>> I
>> think we have to choose between 3 options:
>> 
>> (1) Output untyped (ambiguous) link references whenever possible
>> (2) Always output unambiguous (typed) link references (both 'doc:' and
>> 'space:')
>> (3) Always output 'doc:' link references (no 'space:' references)
>> 
>> Let's see the details:
>> 
>> = OPTION 1: Output untyped link references whenever possible =
>> 
>> == <7.2 ==
>> 
>> Link from A.B
>> * to A.WebHome (space home page) => [[WebHome]]
>> * to A.C (same space) => [[C]]
> 
> I don’t understand why you’re using relative links in your 2 examples
> above. Option (1) says untyped, it doesn’t say convert links into
>> relative
> links.
> 
> So for me that would be:
> 
> * to A.WebHome (space home page) => [[A.WebHome]]
> * to A.C (same space) => [[A.C]]
> 
>> * to X.Y (different space) => [[X.Y]]
>> * to X.WebHome => [[X.WebHome]]
>> 
>> == 7.2+ ==
>> 
>> Link from A.B.WebHome
>> * to A.WebHome (its parent) => [[space:A]]
> 
> Note 1: We could also imagine introducing a syntax for absolute links
>> such
> as [[:A]]
> Note 2: We could also imagine introducing a syntax for parent links
>> such
> as [[..A]]
> 
>> * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling)
>> =>
>> [[C]] (very ambiguous)
> 
> This is using a relative notation. But (1) is not about transforming
>> links
> into relative links.
> 
> so for me this is:
> * => [[A.B.C]]
> * => [[A.C]]
> 
> I’m stopping reading here since first we need to clarify if (1) is
>> about
> a) untyped or b) using relative references.
> 
> IMO it should be about a) and doesn’t have to do b).
> 
> 
 
> Maybe I misunderstood something?
> 
 
 Generating relative references is a must for me (whenever possible), no
 matter what output format we choose. I'm surprised there's any doubt
>> about
 this. The current WYSIWYG editor is generating relative references and
>> the
 CKEditor should continue to do this. Relative references have many
 advantages (eases the refactoring, allows you to export a hierarchy and
 import it somewhere else, etc.).
>>> 
>>> Didn’t realize the WYSIWYG was already doing this!
>>> 
>>> Indeed there are pros. The cons is that it can make the linking more
>> ambiguous., but overall it’s probably a good thing.
>>> 
>> 
>>> Also note that ideally we’d need to not convert existing links when
>> going through the WYSIWYG editor. That’s true independently of this
>> discussion though.
>> 
>> 
> 
>> This is handled by XML comments containing the source reference so the
>> only thing the WYSIWYG need to do is to not touch those comments
>> (unless the user explicitly modify the target of course).
>> 
> 
> It's already the case. The link reference is preserved as is unless you
> edit the link and apply the changes (i.e. you close the link dialog with
> the OK button).

Note that the majority of users will edit a link and click ok even if they 
don’t change anything. An improvement would be to check for a difference in the 
generated link.

What I was commenting on though was that if the user has chosen an absolute 
format or a relative format and he changes some link-related data (label, 
target location, etc), ideally the WYSIWYG would output a reference using the 
same format (absolute or relative).

Thanks
-Vincent

> Thanks for the reply, I understand now.
>>> 
 So option (1) is about untyped relative links, option (2) is about typed
 relative links and option (3) is about doc: relative links. In other
>> words:
 (1) don't generate "doc:" and "space:"
 (2) generate both "doc:" and "space:"
 (3) generate only "doc:" (don't hide WebHome)
>>> 
>>> I’ve now read again the first mail and I’m in favor of (2).
>>> 
>>> The main reason for me is that we want to hide WebHome and with Nested
>> Pages, all links would have WebHome in them with option (3).
>>> 
>>> Option (3) is really the worst for users: they get to see both “doc:”
>> and “WebHome” :)
>>> 
>>> Also note that even 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Thomas Mortagne]

On Tue, Apr 12, 2016 at 4:18 PM, Marius Dumitru Florea
 wrote:
> On Tue, Apr 12, 2016 at 5:12 PM, Thomas Mortagne 
> wrote:
>
>> On Tue, Apr 12, 2016 at 4:09 PM, Vincent Massol 
>> wrote:
>> >
>> >> On 12 Apr 2016, at 15:43, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
>> >>
>> >> On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol 
>> wrote:
>> >>
>> >>> Hi Marius,
>> >>>
>>  On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
>> >>> mariusdumitru.flo...@xwiki.com> wrote:
>> 
>>  Hi devs,
>> 
>>  We need to decide what is the expected link reference serialization
>>  produced by the WYSIWYG editor when you create a link to a wiki page.
>> I
>>  think we have to choose between 3 options:
>> 
>>  (1) Output untyped (ambiguous) link references whenever possible
>>  (2) Always output unambiguous (typed) link references (both 'doc:' and
>>  'space:')
>>  (3) Always output 'doc:' link references (no 'space:' references)
>> 
>>  Let's see the details:
>> 
>>  = OPTION 1: Output untyped link references whenever possible =
>> 
>>  == <7.2 ==
>> 
>>  Link from A.B
>>  * to A.WebHome (space home page) => [[WebHome]]
>>  * to A.C (same space) => [[C]]
>> >>>
>> >>> I don’t understand why you’re using relative links in your 2 examples
>> >>> above. Option (1) says untyped, it doesn’t say convert links into
>> relative
>> >>> links.
>> >>>
>> >>> So for me that would be:
>> >>>
>> >>> * to A.WebHome (space home page) => [[A.WebHome]]
>> >>> * to A.C (same space) => [[A.C]]
>> >>>
>>  * to X.Y (different space) => [[X.Y]]
>>  * to X.WebHome => [[X.WebHome]]
>> 
>>  == 7.2+ ==
>> 
>>  Link from A.B.WebHome
>>  * to A.WebHome (its parent) => [[space:A]]
>> >>>
>> >>> Note 1: We could also imagine introducing a syntax for absolute links
>> such
>> >>> as [[:A]]
>> >>> Note 2: We could also imagine introducing a syntax for parent links
>> such
>> >>> as [[..A]]
>> >>>
>>  * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling)
>> =>
>>  [[C]] (very ambiguous)
>> >>>
>> >>> This is using a relative notation. But (1) is not about transforming
>> links
>> >>> into relative links.
>> >>>
>> >>> so for me this is:
>> >>> * => [[A.B.C]]
>> >>> * => [[A.C]]
>> >>>
>> >>> I’m stopping reading here since first we need to clarify if (1) is
>> about
>> >>> a) untyped or b) using relative references.
>> >>>
>> >>> IMO it should be about a) and doesn’t have to do b).
>> >>>
>> >>>
>> >>
>> >>> Maybe I misunderstood something?
>> >>>
>> >>
>> >> Generating relative references is a must for me (whenever possible), no
>> >> matter what output format we choose. I'm surprised there's any doubt
>> about
>> >> this. The current WYSIWYG editor is generating relative references and
>> the
>> >> CKEditor should continue to do this. Relative references have many
>> >> advantages (eases the refactoring, allows you to export a hierarchy and
>> >> import it somewhere else, etc.).
>> >
>> > Didn’t realize the WYSIWYG was already doing this!
>> >
>> > Indeed there are pros. The cons is that it can make the linking more
>> ambiguous., but overall it’s probably a good thing.
>> >
>>
>> > Also note that ideally we’d need to not convert existing links when
>> going through the WYSIWYG editor. That’s true independently of this
>> discussion though.
>>
>>
>
>> This is handled by XML comments containing the source reference so the
>> only thing the WYSIWYG need to do is to not touch those comments
>> (unless the user explicitly modify the target of course).
>>
>
> It's already the case. The link reference is preserved as is unless you
> edit the link and apply the changes (i.e. you close the link dialog with
> the OK button).

I know this is already the case, that was my point that it was not
requiring the WYSIWYG to do much about it :)

>
>
>>
>> >
>> > Thanks for the reply, I understand now.
>> >
>> >> So option (1) is about untyped relative links, option (2) is about typed
>> >> relative links and option (3) is about doc: relative links. In other
>> words:
>> >> (1) don't generate "doc:" and "space:"
>> >> (2) generate both "doc:" and "space:"
>> >> (3) generate only "doc:" (don't hide WebHome)
>> >
>> > I’ve now read again the first mail and I’m in favor of (2).
>> >
>> > The main reason for me is that we want to hide WebHome and with Nested
>> Pages, all links would have WebHome in them with option (3).
>> >
>> > Option (3) is really the worst for users: they get to see both “doc:”
>> and “WebHome” :)
>> >
>> > Also note that even option (2) is not perfect because of the “doc:” and
>> “space:” prefixes which are also hard to understand for users.
>> >
>> > I also know users who use both WYSIWYG and wiki editors (and who think
>> that WebHome is confusing - We’re used to it, but it’s really confusing if
>> 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Thomas Mortagne]

On Tue, Apr 12, 2016 at 4:11 PM, Vincent Massol  wrote:
>
>> On 12 Apr 2016, at 16:09, Thomas Mortagne  wrote:
>>
>> -1 for (1)
>> +1 for (3)
>
> Could you explain why you prefer (3) to (2)?

(3) is simpler to implement and (2) does not really give you much
simpler references (there is no concept of space anywhere in the UI
and you end up with "space:" references), at least in (3) there is
only one kind of reference.

I don't find any of the proposal perfect but I did not voted -1 for
(2), if everyone prefer (2) then so be it but on my side I find (3)
better right now.

>
> Thanks
> -Vincent
>
>>
>> On Tue, Apr 12, 2016 at 3:43 PM, Marius Dumitru Florea
>>  wrote:
>>> On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol  wrote:
>>>
 Hi Marius,

> On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
 mariusdumitru.flo...@xwiki.com> wrote:
>
> Hi devs,
>
> We need to decide what is the expected link reference serialization
> produced by the WYSIWYG editor when you create a link to a wiki page. I
> think we have to choose between 3 options:
>
> (1) Output untyped (ambiguous) link references whenever possible
> (2) Always output unambiguous (typed) link references (both 'doc:' and
> 'space:')
> (3) Always output 'doc:' link references (no 'space:' references)
>
> Let's see the details:
>
> = OPTION 1: Output untyped link references whenever possible =
>
> == <7.2 ==
>
> Link from A.B
> * to A.WebHome (space home page) => [[WebHome]]
> * to A.C (same space) => [[C]]

 I don’t understand why you’re using relative links in your 2 examples
 above. Option (1) says untyped, it doesn’t say convert links into relative
 links.

 So for me that would be:

 * to A.WebHome (space home page) => [[A.WebHome]]
 * to A.C (same space) => [[A.C]]

> * to X.Y (different space) => [[X.Y]]
> * to X.WebHome => [[X.WebHome]]
>
> == 7.2+ ==
>
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[space:A]]

 Note 1: We could also imagine introducing a syntax for absolute links such
 as [[:A]]
 Note 2: We could also imagine introducing a syntax for parent links such
 as [[..A]]

> * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
> [[C]] (very ambiguous)

 This is using a relative notation. But (1) is not about transforming links
 into relative links.

 so for me this is:
 * => [[A.B.C]]
 * => [[A.C]]

 I’m stopping reading here since first we need to clarify if (1) is about
 a) untyped or b) using relative references.

 IMO it should be about a) and doesn’t have to do b).


>>>
 Maybe I misunderstood something?

>>>
>>> Generating relative references is a must for me (whenever possible), no
>>> matter what output format we choose. I'm surprised there's any doubt about
>>> this. The current WYSIWYG editor is generating relative references and the
>>> CKEditor should continue to do this. Relative references have many
>>> advantages (eases the refactoring, allows you to export a hierarchy and
>>> import it somewhere else, etc.).
>>>
>>> So option (1) is about untyped relative links, option (2) is about typed
>>> relative links and option (3) is about doc: relative links. In other words:
>>> (1) don't generate "doc:" and "space:"
>>> (2) generate both "doc:" and "space:"
>>> (3) generate only "doc:" (don't hide WebHome)
>>>
>>> Thanks,
>>> Marius
>>>
>>>

 Thanks
 -Vincent

> * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
> [[.C.D]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)
>
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[space:A]]
> * to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous)
>
> Link from A.B.C (terminal) or A.B.C.WebHome
> * to A.B.WebHome (its parent) => [[A.B]] (ambiguous)
>
> PROS:
> * shorter link references
> * hides WebHome from source syntax on 7.2+
>
> CONS:
> * ambiguous link references
> * complex code
> * different output for <7.2 and 7.2+ in case of top level space
 [[WebHome]]
> or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested
> spaces is available)
>
>
> = OPTION 2: Always output unambiguous link references =
>
> == <7.2 ==
>
> Link from A.B
> * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> * to A.C (same space) => [[doc:C]] (relative)
> * to X.Y 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Marius Dumitru Florea]

On Tue, Apr 12, 2016 at 5:12 PM, Thomas Mortagne 
wrote:

> On Tue, Apr 12, 2016 at 4:09 PM, Vincent Massol 
> wrote:
> >
> >> On 12 Apr 2016, at 15:43, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >>
> >> On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol 
> wrote:
> >>
> >>> Hi Marius,
> >>>
>  On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
> >>> mariusdumitru.flo...@xwiki.com> wrote:
> 
>  Hi devs,
> 
>  We need to decide what is the expected link reference serialization
>  produced by the WYSIWYG editor when you create a link to a wiki page.
> I
>  think we have to choose between 3 options:
> 
>  (1) Output untyped (ambiguous) link references whenever possible
>  (2) Always output unambiguous (typed) link references (both 'doc:' and
>  'space:')
>  (3) Always output 'doc:' link references (no 'space:' references)
> 
>  Let's see the details:
> 
>  = OPTION 1: Output untyped link references whenever possible =
> 
>  == <7.2 ==
> 
>  Link from A.B
>  * to A.WebHome (space home page) => [[WebHome]]
>  * to A.C (same space) => [[C]]
> >>>
> >>> I don’t understand why you’re using relative links in your 2 examples
> >>> above. Option (1) says untyped, it doesn’t say convert links into
> relative
> >>> links.
> >>>
> >>> So for me that would be:
> >>>
> >>> * to A.WebHome (space home page) => [[A.WebHome]]
> >>> * to A.C (same space) => [[A.C]]
> >>>
>  * to X.Y (different space) => [[X.Y]]
>  * to X.WebHome => [[X.WebHome]]
> 
>  == 7.2+ ==
> 
>  Link from A.B.WebHome
>  * to A.WebHome (its parent) => [[space:A]]
> >>>
> >>> Note 1: We could also imagine introducing a syntax for absolute links
> such
> >>> as [[:A]]
> >>> Note 2: We could also imagine introducing a syntax for parent links
> such
> >>> as [[..A]]
> >>>
>  * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling)
> =>
>  [[C]] (very ambiguous)
> >>>
> >>> This is using a relative notation. But (1) is not about transforming
> links
> >>> into relative links.
> >>>
> >>> so for me this is:
> >>> * => [[A.B.C]]
> >>> * => [[A.C]]
> >>>
> >>> I’m stopping reading here since first we need to clarify if (1) is
> about
> >>> a) untyped or b) using relative references.
> >>>
> >>> IMO it should be about a) and doesn’t have to do b).
> >>>
> >>>
> >>
> >>> Maybe I misunderstood something?
> >>>
> >>
> >> Generating relative references is a must for me (whenever possible), no
> >> matter what output format we choose. I'm surprised there's any doubt
> about
> >> this. The current WYSIWYG editor is generating relative references and
> the
> >> CKEditor should continue to do this. Relative references have many
> >> advantages (eases the refactoring, allows you to export a hierarchy and
> >> import it somewhere else, etc.).
> >
> > Didn’t realize the WYSIWYG was already doing this!
> >
> > Indeed there are pros. The cons is that it can make the linking more
> ambiguous., but overall it’s probably a good thing.
> >
>
> > Also note that ideally we’d need to not convert existing links when
> going through the WYSIWYG editor. That’s true independently of this
> discussion though.
>
>

> This is handled by XML comments containing the source reference so the
> only thing the WYSIWYG need to do is to not touch those comments
> (unless the user explicitly modify the target of course).
>

It's already the case. The link reference is preserved as is unless you
edit the link and apply the changes (i.e. you close the link dialog with
the OK button).


>
> >
> > Thanks for the reply, I understand now.
> >
> >> So option (1) is about untyped relative links, option (2) is about typed
> >> relative links and option (3) is about doc: relative links. In other
> words:
> >> (1) don't generate "doc:" and "space:"
> >> (2) generate both "doc:" and "space:"
> >> (3) generate only "doc:" (don't hide WebHome)
> >
> > I’ve now read again the first mail and I’m in favor of (2).
> >
> > The main reason for me is that we want to hide WebHome and with Nested
> Pages, all links would have WebHome in them with option (3).
> >
> > Option (3) is really the worst for users: they get to see both “doc:”
> and “WebHome” :)
> >
> > Also note that even option (2) is not perfect because of the “doc:” and
> “space:” prefixes which are also hard to understand for users.
> >
> > I also know users who use both WYSIWYG and wiki editors (and who think
> that WebHome is confusing - We’re used to it, but it’s really confusing if
> you’re just starting to use XWiki - you don’t even understand what it means
> at all).
> >
> > To summarize: +1 for (2).
> >
> > Note: My choice for (2) is based purely on a usability POV. It could be
> that implementing option (2) is so much complex that it’s not worth it and
> that we’d want to wait till we change the underlying model before changing
> 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Thomas Mortagne]

On Tue, Apr 12, 2016 at 4:09 PM, Vincent Massol  wrote:
>
>> On 12 Apr 2016, at 15:43, Marius Dumitru Florea 
>>  wrote:
>>
>> On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol  wrote:
>>
>>> Hi Marius,
>>>
 On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
>>> mariusdumitru.flo...@xwiki.com> wrote:

 Hi devs,

 We need to decide what is the expected link reference serialization
 produced by the WYSIWYG editor when you create a link to a wiki page. I
 think we have to choose between 3 options:

 (1) Output untyped (ambiguous) link references whenever possible
 (2) Always output unambiguous (typed) link references (both 'doc:' and
 'space:')
 (3) Always output 'doc:' link references (no 'space:' references)

 Let's see the details:

 = OPTION 1: Output untyped link references whenever possible =

 == <7.2 ==

 Link from A.B
 * to A.WebHome (space home page) => [[WebHome]]
 * to A.C (same space) => [[C]]
>>>
>>> I don’t understand why you’re using relative links in your 2 examples
>>> above. Option (1) says untyped, it doesn’t say convert links into relative
>>> links.
>>>
>>> So for me that would be:
>>>
>>> * to A.WebHome (space home page) => [[A.WebHome]]
>>> * to A.C (same space) => [[A.C]]
>>>
 * to X.Y (different space) => [[X.Y]]
 * to X.WebHome => [[X.WebHome]]

 == 7.2+ ==

 Link from A.B.WebHome
 * to A.WebHome (its parent) => [[space:A]]
>>>
>>> Note 1: We could also imagine introducing a syntax for absolute links such
>>> as [[:A]]
>>> Note 2: We could also imagine introducing a syntax for parent links such
>>> as [[..A]]
>>>
 * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
 [[C]] (very ambiguous)
>>>
>>> This is using a relative notation. But (1) is not about transforming links
>>> into relative links.
>>>
>>> so for me this is:
>>> * => [[A.B.C]]
>>> * => [[A.C]]
>>>
>>> I’m stopping reading here since first we need to clarify if (1) is about
>>> a) untyped or b) using relative references.
>>>
>>> IMO it should be about a) and doesn’t have to do b).
>>>
>>>
>>
>>> Maybe I misunderstood something?
>>>
>>
>> Generating relative references is a must for me (whenever possible), no
>> matter what output format we choose. I'm surprised there's any doubt about
>> this. The current WYSIWYG editor is generating relative references and the
>> CKEditor should continue to do this. Relative references have many
>> advantages (eases the refactoring, allows you to export a hierarchy and
>> import it somewhere else, etc.).
>
> Didn’t realize the WYSIWYG was already doing this!
>
> Indeed there are pros. The cons is that it can make the linking more 
> ambiguous., but overall it’s probably a good thing.
>

> Also note that ideally we’d need to not convert existing links when going 
> through the WYSIWYG editor. That’s true independently of this discussion 
> though.

This is handled by XML comments containing the source reference so the
only thing the WYSIWYG need to do is to not touch those comments
(unless the user explicitly modify the target of course).

>
> Thanks for the reply, I understand now.
>
>> So option (1) is about untyped relative links, option (2) is about typed
>> relative links and option (3) is about doc: relative links. In other words:
>> (1) don't generate "doc:" and "space:"
>> (2) generate both "doc:" and "space:"
>> (3) generate only "doc:" (don't hide WebHome)
>
> I’ve now read again the first mail and I’m in favor of (2).
>
> The main reason for me is that we want to hide WebHome and with Nested Pages, 
> all links would have WebHome in them with option (3).
>
> Option (3) is really the worst for users: they get to see both “doc:” and 
> “WebHome” :)
>
> Also note that even option (2) is not perfect because of the “doc:” and 
> “space:” prefixes which are also hard to understand for users.
>
> I also know users who use both WYSIWYG and wiki editors (and who think that 
> WebHome is confusing - We’re used to it, but it’s really confusing if you’re 
> just starting to use XWiki - you don’t even understand what it means at all).
>
> To summarize: +1 for (2).
>
> Note: My choice for (2) is based purely on a usability POV. It could be that 
> implementing option (2) is so much complex that it’s not worth it and that 
> we’d want to wait till we change the underlying model before changing the 
> linking syntax.
>
> Last note: Maybe we need to invent some completely new syntax for linking 
> since currently it has become very complex. I remember of any mail where I 
> proposed some new syntax for links using a different syntax such as [[[…]]]. 
> It could be interesting to spec a new simpler syntax such as:
> * Use “/“ instead of “.” (we already know that users would prefer “/“ since 
> they’re more used to that symbol)
> * Leading “/“ means absolute. Example: [[[/A/B]]]
> * 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Vincent Massol]

> On 12 Apr 2016, at 16:09, Thomas Mortagne  wrote:
> 
> -1 for (1)
> +1 for (3)

Could you explain why you prefer (3) to (2)?

Thanks
-Vincent

> 
> On Tue, Apr 12, 2016 at 3:43 PM, Marius Dumitru Florea
>  wrote:
>> On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol  wrote:
>> 
>>> Hi Marius,
>>> 
 On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
>>> mariusdumitru.flo...@xwiki.com> wrote:
 
 Hi devs,
 
 We need to decide what is the expected link reference serialization
 produced by the WYSIWYG editor when you create a link to a wiki page. I
 think we have to choose between 3 options:
 
 (1) Output untyped (ambiguous) link references whenever possible
 (2) Always output unambiguous (typed) link references (both 'doc:' and
 'space:')
 (3) Always output 'doc:' link references (no 'space:' references)
 
 Let's see the details:
 
 = OPTION 1: Output untyped link references whenever possible =
 
 == <7.2 ==
 
 Link from A.B
 * to A.WebHome (space home page) => [[WebHome]]
 * to A.C (same space) => [[C]]
>>> 
>>> I don’t understand why you’re using relative links in your 2 examples
>>> above. Option (1) says untyped, it doesn’t say convert links into relative
>>> links.
>>> 
>>> So for me that would be:
>>> 
>>> * to A.WebHome (space home page) => [[A.WebHome]]
>>> * to A.C (same space) => [[A.C]]
>>> 
 * to X.Y (different space) => [[X.Y]]
 * to X.WebHome => [[X.WebHome]]
 
 == 7.2+ ==
 
 Link from A.B.WebHome
 * to A.WebHome (its parent) => [[space:A]]
>>> 
>>> Note 1: We could also imagine introducing a syntax for absolute links such
>>> as [[:A]]
>>> Note 2: We could also imagine introducing a syntax for parent links such
>>> as [[..A]]
>>> 
 * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
 [[C]] (very ambiguous)
>>> 
>>> This is using a relative notation. But (1) is not about transforming links
>>> into relative links.
>>> 
>>> so for me this is:
>>> * => [[A.B.C]]
>>> * => [[A.C]]
>>> 
>>> I’m stopping reading here since first we need to clarify if (1) is about
>>> a) untyped or b) using relative references.
>>> 
>>> IMO it should be about a) and doesn’t have to do b).
>>> 
>>> 
>> 
>>> Maybe I misunderstood something?
>>> 
>> 
>> Generating relative references is a must for me (whenever possible), no
>> matter what output format we choose. I'm surprised there's any doubt about
>> this. The current WYSIWYG editor is generating relative references and the
>> CKEditor should continue to do this. Relative references have many
>> advantages (eases the refactoring, allows you to export a hierarchy and
>> import it somewhere else, etc.).
>> 
>> So option (1) is about untyped relative links, option (2) is about typed
>> relative links and option (3) is about doc: relative links. In other words:
>> (1) don't generate "doc:" and "space:"
>> (2) generate both "doc:" and "space:"
>> (3) generate only "doc:" (don't hide WebHome)
>> 
>> Thanks,
>> Marius
>> 
>> 
>>> 
>>> Thanks
>>> -Vincent
>>> 
 * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
 [[.C.D]] (ambiguous)
 * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
 (ambiguous)
 * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)
 
 Link from A.B (terminal)
 * to A.WebHome (its parent) => [[space:A]]
 * to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous)
 * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
 (ambiguous)
 * to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous)
 
 Link from A.B.C (terminal) or A.B.C.WebHome
 * to A.B.WebHome (its parent) => [[A.B]] (ambiguous)
 
 PROS:
 * shorter link references
 * hides WebHome from source syntax on 7.2+
 
 CONS:
 * ambiguous link references
 * complex code
 * different output for <7.2 and 7.2+ in case of top level space
>>> [[WebHome]]
 or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested
 spaces is available)
 
 
 = OPTION 2: Always output unambiguous link references =
 
 == <7.2 ==
 
 Link from A.B
 * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
 * to A.C (same space) => [[doc:C]] (relative)
 * to X.Y (different space) => [[doc:X.Y]]
 * to X.WebHome => [[doc:X.WebHome]]
 
 == 7.2+ ==
 
 Link from A.B.WebHome
 * to A.WebHome (its parent) => [[space:A]]
 * to A.B.C (terminal child) => [[doc:C]] (relative)
 * to A.B.C.WebHome (non-terminal child) => [[space:A.B.C]] (absolute)
 * to A.C (terminal sibling) => [[doc:A.C]]
 * to A.C.WebHome (non-terminal sibling) => [[space:A.C]]
 * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
 * to A.B.C.D.WebHome (non-terminal descendant) => [[space:A.B.C.D]]
 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Vincent Massol]

> On 12 Apr 2016, at 14:56, Marius Dumitru Florea 
>  wrote:
> 
> Hi devs,
> 
> We need to decide what is the expected link reference serialization
> produced by the WYSIWYG editor when you create a link to a wiki page. I
> think we have to choose between 3 options:
> 
> (1) Output untyped (ambiguous) link references whenever possible
> (2) Always output unambiguous (typed) link references (both 'doc:' and
> 'space:')
> (3) Always output 'doc:' link references (no 'space:' references)
> 
> Let's see the details:
> 
> = OPTION 1: Output untyped link references whenever possible =
> 
> == <7.2 ==
> 
> Link from A.B
> * to A.WebHome (space home page) => [[WebHome]]
> * to A.C (same space) => [[C]]
> * to X.Y (different space) => [[X.Y]]
> * to X.WebHome => [[X.WebHome]]
> 
> == 7.2+ ==
> 
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[space:A]]
> * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
> [[C]] (very ambiguous)
> * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
> [[.C.D]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)
> 
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[space:A]]
> * to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous)
> 
> Link from A.B.C (terminal) or A.B.C.WebHome
> * to A.B.WebHome (its parent) => [[A.B]] (ambiguous)
> 
> PROS:
> * shorter link references
> * hides WebHome from source syntax on 7.2+
> 
> CONS:
> * ambiguous link references
> * complex code
> * different output for <7.2 and 7.2+ in case of top level space [[WebHome]]
> or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested
> spaces is available)
> 
> 
> = OPTION 2: Always output unambiguous link references =
> 
> == <7.2 ==
> 
> Link from A.B
> * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> * to A.C (same space) => [[doc:C]] (relative)
> * to X.Y (different space) => [[doc:X.Y]]
> * to X.WebHome => [[doc:X.WebHome]]
> 
> == 7.2+ ==
> 
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[space:A]]
> * to A.B.C (terminal child) => [[doc:C]] (relative)
> * to A.B.C.WebHome (non-terminal child) => [[space:A.B.C]] (absolute)
> * to A.C (terminal sibling) => [[doc:A.C]]
> * to A.C.WebHome (non-terminal sibling) => [[space:A.C]]
> * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
> * to A.B.C.D.WebHome (non-terminal descendant) => [[space:A.B.C.D]]
> (absolute)
> * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
> * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
> * to X.Y.Z => [[doc:X.Y.Z]]
> * to X.Y.Z.WebHome => [[space:X.Y.Z]]
> 
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[space:A]]
> * to A.C (terminal sibling) => [[doc:C]] (relative)
> * to A.C.WebHome (non-terminal sibling) => [[space:A.C]] (absolute)
> * to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative)
> * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
> * to X.Y => [[doc:X.Y]]
> * to X.Y.WebHome => [[space:X.Y]]
> 
> Link from A.B.C (terminal) or A.B.C.WebHome
> * to A.B.WebHome (its parent) => [[space:A.B]] (absolute)
> 
> PROS:
> * unambiguous link references ("what you link is what you get")
> * slightly less complex code (but still complex)
> * hides WebHome from source syntax on 7.2+
> 
> CONS:
> * longer link references (because of "doc:" and "space:" prefixes)
> * cannot specify relative 'space:' references
> * different output for <7.2 and 7.2+ in case of [[doc:WebHome]] vs.
> [[space:A]]
> 
> 
> = OPTION 3: Always output 'doc:' references =
> 
> == <7.2 ==
> 
> Link from A.B
> * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> * to A.C (same space) => [[doc:C]] (relative)
> * to X.Y (different space) => [[doc:X.Y]]
> * to X.WebHome => [[doc:X.WebHome]]
> 
> == 7.2+ ==
> 
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[doc:A.WebHome]]
> * to A.B.C (terminal child) => [[doc:C]] (relative)
> * to A.B.C.WebHome (non-terminal child) => [[doc:.C.WebHome]] (relative)
> * to A.C (terminal sibling) => [[doc:A.C]]
> * to A.C.WebHome (non-terminal sibling) => [[doc:A.C.WebHome]]
> * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
> * to A.B.C.D.WebHome (non-terminal descendant) => [[doc:.C.D.WebHome]]
> (relative)
> * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
> * to A.C.D.WebHome (non-terminal descendant of sibling) =>
> [[doc:A.C.D.WebHome]]
> * to X.Y.Z => [[doc:X.Y.Z]]
> * to X.Y.Z.WebHome => [[doc:X.Y.Z.WebHome]]
> 
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[doc:WebHome]] (relative)
> * to A.C (terminal sibling) => [[doc:C]] (relative)
> * to A.C.WebHome (non-terminal sibling) => [[doc:.C.WebHome]] 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Vincent Massol]

> On 12 Apr 2016, at 15:43, Marius Dumitru Florea 
>  wrote:
> 
> On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol  wrote:
> 
>> Hi Marius,
>> 
>>> On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
>>> 
>>> Hi devs,
>>> 
>>> We need to decide what is the expected link reference serialization
>>> produced by the WYSIWYG editor when you create a link to a wiki page. I
>>> think we have to choose between 3 options:
>>> 
>>> (1) Output untyped (ambiguous) link references whenever possible
>>> (2) Always output unambiguous (typed) link references (both 'doc:' and
>>> 'space:')
>>> (3) Always output 'doc:' link references (no 'space:' references)
>>> 
>>> Let's see the details:
>>> 
>>> = OPTION 1: Output untyped link references whenever possible =
>>> 
>>> == <7.2 ==
>>> 
>>> Link from A.B
>>> * to A.WebHome (space home page) => [[WebHome]]
>>> * to A.C (same space) => [[C]]
>> 
>> I don’t understand why you’re using relative links in your 2 examples
>> above. Option (1) says untyped, it doesn’t say convert links into relative
>> links.
>> 
>> So for me that would be:
>> 
>> * to A.WebHome (space home page) => [[A.WebHome]]
>> * to A.C (same space) => [[A.C]]
>> 
>>> * to X.Y (different space) => [[X.Y]]
>>> * to X.WebHome => [[X.WebHome]]
>>> 
>>> == 7.2+ ==
>>> 
>>> Link from A.B.WebHome
>>> * to A.WebHome (its parent) => [[space:A]]
>> 
>> Note 1: We could also imagine introducing a syntax for absolute links such
>> as [[:A]]
>> Note 2: We could also imagine introducing a syntax for parent links such
>> as [[..A]]
>> 
>>> * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
>>> [[C]] (very ambiguous)
>> 
>> This is using a relative notation. But (1) is not about transforming links
>> into relative links.
>> 
>> so for me this is:
>> * => [[A.B.C]]
>> * => [[A.C]]
>> 
>> I’m stopping reading here since first we need to clarify if (1) is about
>> a) untyped or b) using relative references.
>> 
>> IMO it should be about a) and doesn’t have to do b).
>> 
>> 
> 
>> Maybe I misunderstood something?
>> 
> 
> Generating relative references is a must for me (whenever possible), no
> matter what output format we choose. I'm surprised there's any doubt about
> this. The current WYSIWYG editor is generating relative references and the
> CKEditor should continue to do this. Relative references have many
> advantages (eases the refactoring, allows you to export a hierarchy and
> import it somewhere else, etc.).

Didn’t realize the WYSIWYG was already doing this!

Indeed there are pros. The cons is that it can make the linking more 
ambiguous., but overall it’s probably a good thing.

Also note that ideally we’d need to not convert existing links when going 
through the WYSIWYG editor. That’s true independently of this discussion though.

Thanks for the reply, I understand now. 

> So option (1) is about untyped relative links, option (2) is about typed
> relative links and option (3) is about doc: relative links. In other words:
> (1) don't generate "doc:" and "space:"
> (2) generate both "doc:" and "space:"
> (3) generate only "doc:" (don't hide WebHome)

I’ve now read again the first mail and I’m in favor of (2). 

The main reason for me is that we want to hide WebHome and with Nested Pages, 
all links would have WebHome in them with option (3).

Option (3) is really the worst for users: they get to see both “doc:” and 
“WebHome” :)

Also note that even option (2) is not perfect because of the “doc:” and 
“space:” prefixes which are also hard to understand for users.

I also know users who use both WYSIWYG and wiki editors (and who think that 
WebHome is confusing - We’re used to it, but it’s really confusing if you’re 
just starting to use XWiki - you don’t even understand what it means at all).

To summarize: +1 for (2).

Note: My choice for (2) is based purely on a usability POV. It could be that 
implementing option (2) is so much complex that it’s not worth it and that we’d 
want to wait till we change the underlying model before changing the linking 
syntax.

Last note: Maybe we need to invent some completely new syntax for linking since 
currently it has become very complex. I remember of any mail where I proposed 
some new syntax for links using a different syntax such as [[[…]]]. It could be 
interesting to spec a new simpler syntax such as:
* Use “/“ instead of “.” (we already know that users would prefer “/“ since 
they’re more used to that symbol)
* Leading “/“ means absolute. Example: [[[/A/B]]]
* Use “..” for parent. Example: [[[..A/B]]]

Thanks
-Vincent

> Thanks,
> Marius
> 
> 
>> 
>> Thanks
>> -Vincent
>> 
>>> * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
>>> [[.C.D]] (ambiguous)
>>> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
>>> (ambiguous)
>>> * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)
>>> 
>>> Link from A.B (terminal)
>>> * 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Marius Dumitru Florea]

On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol  wrote:

> Hi Marius,
>
> > On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > Hi devs,
> >
> > We need to decide what is the expected link reference serialization
> > produced by the WYSIWYG editor when you create a link to a wiki page. I
> > think we have to choose between 3 options:
> >
> > (1) Output untyped (ambiguous) link references whenever possible
> > (2) Always output unambiguous (typed) link references (both 'doc:' and
> > 'space:')
> > (3) Always output 'doc:' link references (no 'space:' references)
> >
> > Let's see the details:
> >
> > = OPTION 1: Output untyped link references whenever possible =
> >
> > == <7.2 ==
> >
> > Link from A.B
> > * to A.WebHome (space home page) => [[WebHome]]
> > * to A.C (same space) => [[C]]
>
> I don’t understand why you’re using relative links in your 2 examples
> above. Option (1) says untyped, it doesn’t say convert links into relative
> links.
>
> So for me that would be:
>
> * to A.WebHome (space home page) => [[A.WebHome]]
> * to A.C (same space) => [[A.C]]
>
> > * to X.Y (different space) => [[X.Y]]
> > * to X.WebHome => [[X.WebHome]]
> >
> > == 7.2+ ==
> >
> > Link from A.B.WebHome
> > * to A.WebHome (its parent) => [[space:A]]
>
> Note 1: We could also imagine introducing a syntax for absolute links such
> as [[:A]]
> Note 2: We could also imagine introducing a syntax for parent links such
> as [[..A]]
>
> > * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
> > [[C]] (very ambiguous)
>
> This is using a relative notation. But (1) is not about transforming links
> into relative links.
>
> so for me this is:
> * => [[A.B.C]]
> * => [[A.C]]
>
> I’m stopping reading here since first we need to clarify if (1) is about
> a) untyped or b) using relative references.
>
> IMO it should be about a) and doesn’t have to do b).
>
>

> Maybe I misunderstood something?
>

Generating relative references is a must for me (whenever possible), no
matter what output format we choose. I'm surprised there's any doubt about
this. The current WYSIWYG editor is generating relative references and the
CKEditor should continue to do this. Relative references have many
advantages (eases the refactoring, allows you to export a hierarchy and
import it somewhere else, etc.).

So option (1) is about untyped relative links, option (2) is about typed
relative links and option (3) is about doc: relative links. In other words:
(1) don't generate "doc:" and "space:"
(2) generate both "doc:" and "space:"
(3) generate only "doc:" (don't hide WebHome)

Thanks,
Marius


>
> Thanks
> -Vincent
>
> > * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
> > [[.C.D]] (ambiguous)
> > * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> > (ambiguous)
> > * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)
> >
> > Link from A.B (terminal)
> > * to A.WebHome (its parent) => [[space:A]]
> > * to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous)
> > * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> > (ambiguous)
> > * to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous)
> >
> > Link from A.B.C (terminal) or A.B.C.WebHome
> > * to A.B.WebHome (its parent) => [[A.B]] (ambiguous)
> >
> > PROS:
> > * shorter link references
> > * hides WebHome from source syntax on 7.2+
> >
> > CONS:
> > * ambiguous link references
> > * complex code
> > * different output for <7.2 and 7.2+ in case of top level space
> [[WebHome]]
> > or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested
> > spaces is available)
> >
> >
> > = OPTION 2: Always output unambiguous link references =
> >
> > == <7.2 ==
> >
> > Link from A.B
> > * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> > * to A.C (same space) => [[doc:C]] (relative)
> > * to X.Y (different space) => [[doc:X.Y]]
> > * to X.WebHome => [[doc:X.WebHome]]
> >
> > == 7.2+ ==
> >
> > Link from A.B.WebHome
> > * to A.WebHome (its parent) => [[space:A]]
> > * to A.B.C (terminal child) => [[doc:C]] (relative)
> > * to A.B.C.WebHome (non-terminal child) => [[space:A.B.C]] (absolute)
> > * to A.C (terminal sibling) => [[doc:A.C]]
> > * to A.C.WebHome (non-terminal sibling) => [[space:A.C]]
> > * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
> > * to A.B.C.D.WebHome (non-terminal descendant) => [[space:A.B.C.D]]
> > (absolute)
> > * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
> > * to A.C.D.WebHome (non-terminal descendant of sibling) =>
> [[space:A.C.D]]
> > * to X.Y.Z => [[doc:X.Y.Z]]
> > * to X.Y.Z.WebHome => [[space:X.Y.Z]]
> >
> > Link from A.B (terminal)
> > * to A.WebHome (its parent) => [[space:A]]
> > * to A.C (terminal sibling) => [[doc:C]] (relative)
> > * to A.C.WebHome (non-terminal sibling) => [[space:A.C]] (absolute)
> > * to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative)
> > * to A.C.D.WebHome 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Vincent Massol]

Hi Marius,

> On 12 Apr 2016, at 14:56, Marius Dumitru Florea 
>  wrote:
> 
> Hi devs,
> 
> We need to decide what is the expected link reference serialization
> produced by the WYSIWYG editor when you create a link to a wiki page. I
> think we have to choose between 3 options:
> 
> (1) Output untyped (ambiguous) link references whenever possible
> (2) Always output unambiguous (typed) link references (both 'doc:' and
> 'space:')
> (3) Always output 'doc:' link references (no 'space:' references)
> 
> Let's see the details:
> 
> = OPTION 1: Output untyped link references whenever possible =
> 
> == <7.2 ==
> 
> Link from A.B
> * to A.WebHome (space home page) => [[WebHome]]
> * to A.C (same space) => [[C]]

I don’t understand why you’re using relative links in your 2 examples above. 
Option (1) says untyped, it doesn’t say convert links into relative links.

So for me that would be:

* to A.WebHome (space home page) => [[A.WebHome]]
* to A.C (same space) => [[A.C]]

> * to X.Y (different space) => [[X.Y]]
> * to X.WebHome => [[X.WebHome]]
> 
> == 7.2+ ==
> 
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[space:A]]

Note 1: We could also imagine introducing a syntax for absolute links such as 
[[:A]]
Note 2: We could also imagine introducing a syntax for parent links such as 
[[..A]] 

> * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
> [[C]] (very ambiguous)

This is using a relative notation. But (1) is not about transforming links into 
relative links.

so for me this is:
* => [[A.B.C]]
* => [[A.C]]

I’m stopping reading here since first we need to clarify if (1) is about a) 
untyped or b) using relative references.

IMO it should be about a) and doesn’t have to do b).

Maybe I misunderstood something?

Thanks
-Vincent

> * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
> [[.C.D]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)
> 
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[space:A]]
> * to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous)
> 
> Link from A.B.C (terminal) or A.B.C.WebHome
> * to A.B.WebHome (its parent) => [[A.B]] (ambiguous)
> 
> PROS:
> * shorter link references
> * hides WebHome from source syntax on 7.2+
> 
> CONS:
> * ambiguous link references
> * complex code
> * different output for <7.2 and 7.2+ in case of top level space [[WebHome]]
> or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested
> spaces is available)
> 
> 
> = OPTION 2: Always output unambiguous link references =
> 
> == <7.2 ==
> 
> Link from A.B
> * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> * to A.C (same space) => [[doc:C]] (relative)
> * to X.Y (different space) => [[doc:X.Y]]
> * to X.WebHome => [[doc:X.WebHome]]
> 
> == 7.2+ ==
> 
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[space:A]]
> * to A.B.C (terminal child) => [[doc:C]] (relative)
> * to A.B.C.WebHome (non-terminal child) => [[space:A.B.C]] (absolute)
> * to A.C (terminal sibling) => [[doc:A.C]]
> * to A.C.WebHome (non-terminal sibling) => [[space:A.C]]
> * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
> * to A.B.C.D.WebHome (non-terminal descendant) => [[space:A.B.C.D]]
> (absolute)
> * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
> * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
> * to X.Y.Z => [[doc:X.Y.Z]]
> * to X.Y.Z.WebHome => [[space:X.Y.Z]]
> 
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[space:A]]
> * to A.C (terminal sibling) => [[doc:C]] (relative)
> * to A.C.WebHome (non-terminal sibling) => [[space:A.C]] (absolute)
> * to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative)
> * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
> * to X.Y => [[doc:X.Y]]
> * to X.Y.WebHome => [[space:X.Y]]
> 
> Link from A.B.C (terminal) or A.B.C.WebHome
> * to A.B.WebHome (its parent) => [[space:A.B]] (absolute)
> 
> PROS:
> * unambiguous link references ("what you link is what you get")
> * slightly less complex code (but still complex)
> * hides WebHome from source syntax on 7.2+
> 
> CONS:
> * longer link references (because of "doc:" and "space:" prefixes)
> * cannot specify relative 'space:' references
> * different output for <7.2 and 7.2+ in case of [[doc:WebHome]] vs.
> [[space:A]]
> 
> 
> = OPTION 3: Always output 'doc:' references =
> 
> == <7.2 ==
> 
> Link from A.B
> * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> * to A.C (same space) => [[doc:C]] (relative)
> * to X.Y (different space) => [[doc:X.Y]]
> * to X.WebHome => [[doc:X.WebHome]]
> 
> == 7.2+ ==
> 
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[doc:A.WebHome]]

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

[Sergiu Dumitriu]

Perhaps [1] is what you're looking for.

XWiki's security mechanism [2] is tightly bound to internally stored
rights, and changing its code allows only minor cosmetic alterations to
the decision process.

PhenoTips' "authorization" mechanism [3] makes things extremely modular:
you're free to implement as many modules you want, and each module is
free to decide in whatever way how rights are given. All you have to do
is write a component that implements AuthorizationModule [4]. All
available modules are active, and they're chained based on their
priority [5]. The authorization manager service [6] calls each module in
the descending order of their priority, asking them [7] if a specific
action is allowed or not. When asked, each module can either allow
(return True), deny (return False), or take no decision and defer to the
following modules (return null).

The two already implemented modules defer to XWiki's classic security
module [8], and take a default (configurable) decision to either allow
or deny all so far undecided calls [9]. However, if [8] is active in the
system, [9] will never actually be reached, but it is still useful if
you decide to remove XWiki's rights altogether.

The "bridge" [10] registers this modular authorization mechanism with
XWiki, so that it is called instead of the current XWiki security
mechanism. All you have to do is set [11] as the rights class in xwiki.cfg:

xwiki.authentication.rightsclass=org.phenotips.security.authorization.ModularRightServiceImpl

Based on this mechanism, we have several modules that deal with specific
rights restrictions:

[12] allows to lock a document, preventing all edits, even from
administrators, until the document is unlocked again.
[13] allows assigning documents to "Projects", giving rights to project
owners over those documents.
[14] allows setting a document owner, who then is given all access on
that document.

And more optional modules will be added.

[1] https://github.com/phenotips/phenotips/tree/master/components/security
[2]
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwiki-platform-security
[3]
https://github.com/phenotips/phenotips/tree/master/components/security/authorization
[4]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java
[5]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L48
[6]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationService.java
[7]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L59
[8]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/XWikiACLAuthorizationModule.java
[9]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/BaseAuthorizationModule.java
[10]
https://github.com/phenotips/phenotips/tree/master/components/security/bridge
[11]
https://github.com/phenotips/phenotips/blob/master/components/security/bridge/src/main/java/org/phenotips/security/authorization/ModularRightServiceImpl.java
[12]
https://github.com/phenotips/phenotips/blob/master/components/record-locking/api/src/main/java/org/phenotips/recordLocking/internal/authorization/LockedAuthorizationModule.java
[13]
https://github.com/phenotips/phenotips/blob/PT-1987-projects/components/projects/api/src/main/java/org/phenotips/projects/authorization/ProjectAuthorizationModule.java
[14]
https://github.com/IJessa/phenotips/blob/issue-1023/components/patient-access-rules/api/src/main/java/org/phenotips/data/permissions/internal/OwnerAccessAuthorizationModule.java

On 04/12/2016 06:15 AM, Denis Gervalle wrote:
> Hi Andrey,
> 
> I would not advice to reimplement the ContextualAuthorizationManager, since
> it only provide context to the AuthorizationManager, and there is probably
> no need for you to change that part. I would not even advice to reimplement
> the AuthorizationManage (since the way it works provide some useful caching
> mechanism using the security cache), unless you really want to revamp the
> way rights are managed. This could be a lot of work, while there is a lot
> of room for customizing rights and the way these are interpreted.
> 
> The AuthorizationSettler, which receive information from the wiki (security
> rules) and take the decision is probably the easiest place where you can
> change the way decision are taken. Moreover, this one is configurable in
> xwiki.properties, see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module#HRightsandaccessdecisions
> .
> 
> If your need is 

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Alexandru Cotiuga]

Option (3) makes more sense to me, so I'm +1 for option (3).

Thanks,
Alex

On Tue, Apr 12, 2016 at 3:56 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi devs,
>
> We need to decide what is the expected link reference serialization
> produced by the WYSIWYG editor when you create a link to a wiki page. I
> think we have to choose between 3 options:
>
> (1) Output untyped (ambiguous) link references whenever possible
> (2) Always output unambiguous (typed) link references (both 'doc:' and
> 'space:')
> (3) Always output 'doc:' link references (no 'space:' references)
>
> Let's see the details:
>
> = OPTION 1: Output untyped link references whenever possible =
>
> == <7.2 ==
>
> Link from A.B
> * to A.WebHome (space home page) => [[WebHome]]
> * to A.C (same space) => [[C]]
> * to X.Y (different space) => [[X.Y]]
> * to X.WebHome => [[X.WebHome]]
>
> == 7.2+ ==
>
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[space:A]]
> * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
> [[C]] (very ambiguous)
> * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
> [[.C.D]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)
>
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[space:A]]
> * to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous)
> * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
> (ambiguous)
> * to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous)
>
> Link from A.B.C (terminal) or A.B.C.WebHome
> * to A.B.WebHome (its parent) => [[A.B]] (ambiguous)
>
> PROS:
> * shorter link references
> * hides WebHome from source syntax on 7.2+
>
> CONS:
> * ambiguous link references
> * complex code
> * different output for <7.2 and 7.2+ in case of top level space [[WebHome]]
> or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested
> spaces is available)
>
>
> = OPTION 2: Always output unambiguous link references =
>
> == <7.2 ==
>
> Link from A.B
> * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> * to A.C (same space) => [[doc:C]] (relative)
> * to X.Y (different space) => [[doc:X.Y]]
> * to X.WebHome => [[doc:X.WebHome]]
>
> == 7.2+ ==
>
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[space:A]]
> * to A.B.C (terminal child) => [[doc:C]] (relative)
> * to A.B.C.WebHome (non-terminal child) => [[space:A.B.C]] (absolute)
> * to A.C (terminal sibling) => [[doc:A.C]]
> * to A.C.WebHome (non-terminal sibling) => [[space:A.C]]
> * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
> * to A.B.C.D.WebHome (non-terminal descendant) => [[space:A.B.C.D]]
> (absolute)
> * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
> * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
> * to X.Y.Z => [[doc:X.Y.Z]]
> * to X.Y.Z.WebHome => [[space:X.Y.Z]]
>
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[space:A]]
> * to A.C (terminal sibling) => [[doc:C]] (relative)
> * to A.C.WebHome (non-terminal sibling) => [[space:A.C]] (absolute)
> * to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative)
> * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
> * to X.Y => [[doc:X.Y]]
> * to X.Y.WebHome => [[space:X.Y]]
>
> Link from A.B.C (terminal) or A.B.C.WebHome
> * to A.B.WebHome (its parent) => [[space:A.B]] (absolute)
>
> PROS:
> * unambiguous link references ("what you link is what you get")
> * slightly less complex code (but still complex)
> * hides WebHome from source syntax on 7.2+
>
> CONS:
> * longer link references (because of "doc:" and "space:" prefixes)
> * cannot specify relative 'space:' references
> * different output for <7.2 and 7.2+ in case of [[doc:WebHome]] vs.
> [[space:A]]
>
>
> = OPTION 3: Always output 'doc:' references =
>
> == <7.2 ==
>
> Link from A.B
> * to A.WebHome (space home page) => [[doc:WebHome]] (relative)
> * to A.C (same space) => [[doc:C]] (relative)
> * to X.Y (different space) => [[doc:X.Y]]
> * to X.WebHome => [[doc:X.WebHome]]
>
> == 7.2+ ==
>
> Link from A.B.WebHome
> * to A.WebHome (its parent) => [[doc:A.WebHome]]
> * to A.B.C (terminal child) => [[doc:C]] (relative)
> * to A.B.C.WebHome (non-terminal child) => [[doc:.C.WebHome]] (relative)
> * to A.C (terminal sibling) => [[doc:A.C]]
> * to A.C.WebHome (non-terminal sibling) => [[doc:A.C.WebHome]]
> * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
> * to A.B.C.D.WebHome (non-terminal descendant) => [[doc:.C.D.WebHome]]
> (relative)
> * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
> * to A.C.D.WebHome (non-terminal descendant of sibling) =>
> [[doc:A.C.D.WebHome]]
> * to X.Y.Z => [[doc:X.Y.Z]]
> * to X.Y.Z.WebHome => [[doc:X.Y.Z.WebHome]]
>
> Link from A.B (terminal)
> * to A.WebHome (its parent) => [[doc:WebHome]] (relative)
> * to A.C (terminal sibling) => [[doc:C]] (relative)
> * to 

[xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Marius Dumitru Florea]

Hi devs,

We need to decide what is the expected link reference serialization
produced by the WYSIWYG editor when you create a link to a wiki page. I
think we have to choose between 3 options:

(1) Output untyped (ambiguous) link references whenever possible
(2) Always output unambiguous (typed) link references (both 'doc:' and
'space:')
(3) Always output 'doc:' link references (no 'space:' references)

Let's see the details:

= OPTION 1: Output untyped link references whenever possible =

== <7.2 ==

Link from A.B
* to A.WebHome (space home page) => [[WebHome]]
* to A.C (same space) => [[C]]
* to X.Y (different space) => [[X.Y]]
* to X.WebHome => [[X.WebHome]]

== 7.2+ ==

Link from A.B.WebHome
* to A.WebHome (its parent) => [[space:A]]
* to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) =>
[[C]] (very ambiguous)
* to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) =>
[[.C.D]] (ambiguous)
* to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
(ambiguous)
* to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous)

Link from A.B (terminal)
* to A.WebHome (its parent) => [[space:A]]
* to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous)
* to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]]
(ambiguous)
* to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous)

Link from A.B.C (terminal) or A.B.C.WebHome
* to A.B.WebHome (its parent) => [[A.B]] (ambiguous)

PROS:
* shorter link references
* hides WebHome from source syntax on 7.2+

CONS:
* ambiguous link references
* complex code
* different output for <7.2 and 7.2+ in case of top level space [[WebHome]]
or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested
spaces is available)


= OPTION 2: Always output unambiguous link references =

== <7.2 ==

Link from A.B
* to A.WebHome (space home page) => [[doc:WebHome]] (relative)
* to A.C (same space) => [[doc:C]] (relative)
* to X.Y (different space) => [[doc:X.Y]]
* to X.WebHome => [[doc:X.WebHome]]

== 7.2+ ==

Link from A.B.WebHome
* to A.WebHome (its parent) => [[space:A]]
* to A.B.C (terminal child) => [[doc:C]] (relative)
* to A.B.C.WebHome (non-terminal child) => [[space:A.B.C]] (absolute)
* to A.C (terminal sibling) => [[doc:A.C]]
* to A.C.WebHome (non-terminal sibling) => [[space:A.C]]
* to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
* to A.B.C.D.WebHome (non-terminal descendant) => [[space:A.B.C.D]]
(absolute)
* to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
* to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
* to X.Y.Z => [[doc:X.Y.Z]]
* to X.Y.Z.WebHome => [[space:X.Y.Z]]

Link from A.B (terminal)
* to A.WebHome (its parent) => [[space:A]]
* to A.C (terminal sibling) => [[doc:C]] (relative)
* to A.C.WebHome (non-terminal sibling) => [[space:A.C]] (absolute)
* to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative)
* to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]]
* to X.Y => [[doc:X.Y]]
* to X.Y.WebHome => [[space:X.Y]]

Link from A.B.C (terminal) or A.B.C.WebHome
* to A.B.WebHome (its parent) => [[space:A.B]] (absolute)

PROS:
* unambiguous link references ("what you link is what you get")
* slightly less complex code (but still complex)
* hides WebHome from source syntax on 7.2+

CONS:
* longer link references (because of "doc:" and "space:" prefixes)
* cannot specify relative 'space:' references
* different output for <7.2 and 7.2+ in case of [[doc:WebHome]] vs.
[[space:A]]


= OPTION 3: Always output 'doc:' references =

== <7.2 ==

Link from A.B
* to A.WebHome (space home page) => [[doc:WebHome]] (relative)
* to A.C (same space) => [[doc:C]] (relative)
* to X.Y (different space) => [[doc:X.Y]]
* to X.WebHome => [[doc:X.WebHome]]

== 7.2+ ==

Link from A.B.WebHome
* to A.WebHome (its parent) => [[doc:A.WebHome]]
* to A.B.C (terminal child) => [[doc:C]] (relative)
* to A.B.C.WebHome (non-terminal child) => [[doc:.C.WebHome]] (relative)
* to A.C (terminal sibling) => [[doc:A.C]]
* to A.C.WebHome (non-terminal sibling) => [[doc:A.C.WebHome]]
* to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative)
* to A.B.C.D.WebHome (non-terminal descendant) => [[doc:.C.D.WebHome]]
(relative)
* to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]]
* to A.C.D.WebHome (non-terminal descendant of sibling) =>
[[doc:A.C.D.WebHome]]
* to X.Y.Z => [[doc:X.Y.Z]]
* to X.Y.Z.WebHome => [[doc:X.Y.Z.WebHome]]

Link from A.B (terminal)
* to A.WebHome (its parent) => [[doc:WebHome]] (relative)
* to A.C (terminal sibling) => [[doc:C]] (relative)
* to A.C.WebHome (non-terminal sibling) => [[doc:.C.WebHome]] (relative)
* to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative)
* to A.C.D.WebHome (non-terminal descendant of sibling) =>
[[doc:.C.D.WebHome]] (relative)
* to X.Y => [[doc:X.Y]]
* to X.Y.WebHome => [[doc:X.Y.WebHome]]

Link from A.B.C (terminal)
* to A.B.WebHome (its parent) => [[doc:WebHome]] (relative)

Link from A.B.C.WebHome
* to A.B.WebHome (its 

Re: [xwiki-devs] [Proposal] Add a new perSpace property to the XWiki.ConfigurableClass class

[Vincent Massol]

Hi Alex,

> On 12 Apr 2016, at 14:22, Alexandru Cotiuga  
> wrote:
> 
> Hello devs,
> 
> Since Nested Spaces has been introduced in XWiki, the need of configuring
> some applications at space level has also appeared.

It was there before (skin, rights, etc) but I agree that it’s even more 
important now.

> There are already some configurable sections at space level: Look & Feel
> (Presentation, Page Elements, PanelWizard), Users & Groups (Rights: Page &
> Children, Rights: Page) but they are not using the configurable class and
> they are defined in
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/AdminSheet.xml#L60
> having perSpace key.
> 
> The new installed applications that have a configuration page, can't be
> configured now at space level and what I'm proposing in order to ease the
> way this can be achieved is to add a new boolean property perSpace to the
> XWiki.ConfigurableClass class.

I think I’d prefer instead to introduce a “visibility” xproperty similar to 
what we have in wiki Macros and wiki components. Which could be for the moment: 
WIKI, SPACE (later on we could maybe add some config options that are only 
visible at the farm level, i.e. on the main wiki). Another use case in the 
future could be to have user-level configuration options too (with a visibility 
of USER); this could be a way to reuse ConfigurableClass for both Admin UI and 
User Profile UI in the future.

Of course this means deprecating the “configureGlobally”. 

> Another idea would be to create a mix between this non-existing property
> and existing configureGlobally property and to create a new one with some
> options: Wiki, Wiki & space, Space but this involves a lot of changes tha
> might not worth the effort.

I think it’s worth introducing a “visibility” xproperty.

Thanks
-Vincent

> WDYT?
> 
> Thanks,
> Alex

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Proposal] Add a new perSpace property to the XWiki.ConfigurableClass class

[Alexandru Cotiuga]

Hello devs,

Since Nested Spaces has been introduced in XWiki, the need of configuring
some applications at space level has also appeared.

There are already some configurable sections at space level: Look & Feel
(Presentation, Page Elements, PanelWizard), Users & Groups (Rights: Page &
Children, Rights: Page) but they are not using the configurable class and
they are defined in
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/AdminSheet.xml#L60
having perSpace key.

The new installed applications that have a configuration page, can't be
configured now at space level and what I'm proposing in order to ease the
way this can be achieved is to add a new boolean property perSpace to the
XWiki.ConfigurableClass class.

Another idea would be to create a mix between this non-existing property
and existing configureGlobally property and to create a new one with some
options: Wiki, Wiki & space, Space but this involves a lot of changes tha
might not worth the effort.

WDYT?

Thanks,
Alex
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

[Denis Gervalle]

Hi Andrey,

I would not advice to reimplement the ContextualAuthorizationManager, since
it only provide context to the AuthorizationManager, and there is probably
no need for you to change that part. I would not even advice to reimplement
the AuthorizationManage (since the way it works provide some useful caching
mechanism using the security cache), unless you really want to revamp the
way rights are managed. This could be a lot of work, while there is a lot
of room for customizing rights and the way these are interpreted.

The AuthorizationSettler, which receive information from the wiki (security
rules) and take the decision is probably the easiest place where you can
change the way decision are taken. Moreover, this one is configurable in
xwiki.properties, see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module#HRightsandaccessdecisions
.

If your need is better solved by injecting custom security rules, you may
also want to override the bridge part. The security module is completely
agnostic to XWiki itself, and the junction is made by the security bridge
module. This where you will found the default SecurityEntryReader.

When you need to override a component that does not have a dedicated
configuration, during your development or when installed as an extension,
you have to unregister the existing component (to be polite), and register
yours in replacement, see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HComponentRegistration
about
component registration.
If you end up packaging the component in a custom war, you may want to use
the priority override solution, as describe in
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides

I hope this answer your questions, I encourage you to read the Javadoc of
the security module for explanation about each roles and how they could
influence the whole system, as I said, a lot can be done without having to
rewrite the whole thing, which is a tough task.
Regards,


On Tue, Apr 12, 2016 at 10:16 AM, abtv  wrote:

> When I use XWikiCachingRightService I register it in xwiki.cfg file. Where
> should I register my implementation of ContextualAuthorizationManager
> interface? What is a relation between ContextualAuthorizationManager and
> AuthorizationSettler?
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-custom-permission-check-in-java-code-tp7598878p7598933.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Denis Gervalle
SOFTEC sa - CEO
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Questions, Gsoc2016, XWiki Android-authenticator

[Thomas Mortagne]

Hi Fitz,

Great to see so much motivation from you :)

Just don't forget that GSOC coding period is not started yet and that
we still have no idea how many slots Google will give us and who we
will select this year (this will be 22nd April).

On Tue, Apr 12, 2016 at 10:03 AM, fitz  wrote:
> Hello Dear devs,
>
> I am Fitz Lee, a CS Master's student from the University of Chinese Academy
> of Sciences. I'm very interested in this project, XWiki authenticator
> Android. I have submitted the final application for Gsoc2016
> (https://drive.google.com/file/d/0ByNx4jI3PEaNaGRxMkt0cUU3SjA/view?usp=sharing
> ).
> In order to furtherly understand the authenticator project, I have developed
> this android demo (https://github.com/fitzlee/SampleSyncAdapter), which is
> based on SampleSyncAdapter Google Android Sample. By deeply Analyzing the
> SampleSyncAdapter source,  I have implemented the material design(>=4.4) ui,
> the synchronization of contacts and the access of other apps .  But some
> functions in google server(https://samplesyncadapter2.appspot.com/sync)
> can't work well so that the client-to-server Synchronization function can't
> be tested and verified, and it needs to cooperate with server.  In my github
> repository(https://github.com/fitzlee/SampleSyncAdapter), I also show my
> analysis about the authenticator, synchronization, contactmanager, sign-in,
> sign-up and the whole process of the app. And now I am trying to develop the
> XWiki android authenticator project.
>
> Please consider my application, and I am eager to join this project and make
> a contribution. It's my first time to join the open source organization for
> enhancing my teamwork and technical skills. Please give me a chance, and I
> will try my best. If there is anything I can do for this project , I will be
> very happy.
>
> Here, i also have some questions which confuse me during my development:
> 1. contact synchronization
> (1)Situation:
> Now I have implemented the server-to-app synchronization with the modified
> SampleSyncAdapter (https://github.com/fitzlee/SampleSyncAdapter), and this
> demo can download contacts from server to local sqlite3 database. Also I can
> edit and modify the local contact and from logcat I have seen the dirty
> contacts being sent to the server. But the synchronization of server can't
> work so that I can't test this function.
> (2)Problem:
> Moreover, by analyzing the XWiki android authenticator in the repository
> (https://github.com/xwiki-contrib/android-authenticator). I have seen that
> some function has not been implemented, like getDirtyContacts and
> getRawContact in ContactManager. And the process of synchronisation in
> SynAdapter_onPerformSync also confuse me, like "ensureXWikiGroupExists>>
> XWikiConnector.getUsers>> ContactManager.updateContacts>>
> ContactManager.updateStatusMessages". I think it should be this process,
> like "ContactManager.getDirtyContacts>> NetworkUtilities.syncContacts>>
> ContactManager.updateContacts". Therefore, I don't know whether there is
> something wrong with me.  Could you give me some advice?

Yes contact synchronization in
https://github.com/xwiki-contrib/android-authenticator is not the
beginning or an experiment I never had time to finish so it's more
pseudo code that never worked yet.

>
> 2. A test xwiki server and test user which may help me a lot to develop this
> project for testing.
> I have analysed the sampleSynAdapter and implemented some function, for
> example material design(>=4.4), version support(2.3 with v7 library) and the
> synchronisation from server to the android local sqlite3
> database(contacts2.db) using ContactManager.But when client sends some dirty
> contact data to server, the synchronisation of server in google appengine
> can't work well so that I can't test my app's synchronisation. And the
> SampleSyncAdapter server also can't provide me more apis,like signing up and
> other necessary function.I have tried to upload a python server to google
> appengine,but failed because of the incompatibility between the source code
> by python version 2.5 and the cloud platform by 2.7 version.
> Question: Please if possible, could i have a test user and some server apis
> in xwiki server, or maybe i should write a test server by myself?

I see two main possibility for this:
* the first thing you should do I think is download the jetty/hsqld
all in one distribution on
http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
server (you have admin right in it and can create as many test users
or groups as you want)
* as soon as you want to test volume and compatibility with existing
instance of XWiki you can register on http://www.xwiki.org which
contains 1519 users right now

>
> 3. requirement
> I think this project mainly has the following requirements.

> (1) sign in
> it is easy,just like my analysis of android SampleSyncAdapter, including the
> server connection with XWikiconnector and the account 

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

[abtv]

When I use XWikiCachingRightService I register it in xwiki.cfg file. Where
should I register my implementation of ContextualAuthorizationManager
interface? What is a relation between ContextualAuthorizationManager and
AuthorizationSettler?



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-custom-permission-check-in-java-code-tp7598878p7598933.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] Questions, Gsoc2016, XWiki Android-authenticator

[fitz]

Hello Dear devs,

I am Fitz Lee, a CS Master's student from the University of Chinese Academy
of Sciences. I'm very interested in this project, XWiki authenticator
Android. I have submitted the final application for Gsoc2016
(https://drive.google.com/file/d/0ByNx4jI3PEaNaGRxMkt0cUU3SjA/view?usp=sharing
).
In order to furtherly understand the authenticator project, I have developed
this android demo (https://github.com/fitzlee/SampleSyncAdapter), which is
based on SampleSyncAdapter Google Android Sample. By deeply Analyzing the
SampleSyncAdapter source,  I have implemented the material design(>=4.4) ui,
the synchronization of contacts and the access of other apps .  But some
functions in google server(https://samplesyncadapter2.appspot.com/sync)
can't work well so that the client-to-server Synchronization function can't
be tested and verified, and it needs to cooperate with server.  In my github
repository(https://github.com/fitzlee/SampleSyncAdapter), I also show my
analysis about the authenticator, synchronization, contactmanager, sign-in,
sign-up and the whole process of the app. And now I am trying to develop the
XWiki android authenticator project.

Please consider my application, and I am eager to join this project and make
a contribution. It's my first time to join the open source organization for
enhancing my teamwork and technical skills. Please give me a chance, and I
will try my best. If there is anything I can do for this project , I will be
very happy.
 
Here, i also have some questions which confuse me during my development:
1. contact synchronization
(1)Situation:
Now I have implemented the server-to-app synchronization with the modified
SampleSyncAdapter (https://github.com/fitzlee/SampleSyncAdapter), and this
demo can download contacts from server to local sqlite3 database. Also I can
edit and modify the local contact and from logcat I have seen the dirty
contacts being sent to the server. But the synchronization of server can't
work so that I can't test this function.
(2)Problem:
Moreover, by analyzing the XWiki android authenticator in the repository
(https://github.com/xwiki-contrib/android-authenticator). I have seen that
some function has not been implemented, like getDirtyContacts and
getRawContact in ContactManager. And the process of synchronisation in
SynAdapter_onPerformSync also confuse me, like "ensureXWikiGroupExists>>
XWikiConnector.getUsers>> ContactManager.updateContacts>>
ContactManager.updateStatusMessages". I think it should be this process,
like "ContactManager.getDirtyContacts>> NetworkUtilities.syncContacts>>
ContactManager.updateContacts". Therefore, I don't know whether there is
something wrong with me.  Could you give me some advice?
 
2. A test xwiki server and test user which may help me a lot to develop this
project for testing.
I have analysed the sampleSynAdapter and implemented some function, for
example material design(>=4.4), version support(2.3 with v7 library) and the
synchronisation from server to the android local sqlite3
database(contacts2.db) using ContactManager.But when client sends some dirty
contact data to server, the synchronisation of server in google appengine
can't work well so that I can't test my app's synchronisation. And the
SampleSyncAdapter server also can't provide me more apis,like signing up and
other necessary function.I have tried to upload a python server to google
appengine,but failed because of the incompatibility between the source code
by python version 2.5 and the cloud platform by 2.7 version.
Question: Please if possible, could i have a test user and some server apis
in xwiki server, or maybe i should write a test server by myself?
 
3. requirement
I think this project mainly has the following requirements.
(1) sign in
it is easy,just like my analysis of android SampleSyncAdapter, including the
server connection with XWikiconnector and the account added by
AccountManager
(2) sign up
may also need some other api, like getting a list of xwiki user, adding
friends which can be synchronized in the local phone contacts. Also other
activitie may be possibly added, therefor the authenticator app will be very
complex.
(3) synchronization of contacts
(4) edit the contact
(5) access by other apps
Question: Are there more other requirements in this app, like adding
friends(general person) and creating new xwiki account(administrator)? 
maybe it will cause more demands and be more complex. 
 
4. support version and ui
(1) ui design
* material design >=4.4 with the support library support-v7
(2) support version
* The ui design can support the lowest 2.3 version and the android
sampleSynAdapter can also support 2.3 version. So I think our authenticator
app can support the lowest 2.3 version if needed.
Question: Maybe there are somethings I have not noticed, so this conclusion
is wrong, please give me some advice? Is that OK?
 
5. account permission
In AccountGeneral.java there are two permissions , like
AUTHTOKEN_TYPE_READ_ONLY, 

Re: [xwiki-devs] [Proposal] New Webjars URL format to support relative webjars URL

[Vincent Massol]

> On 11 Apr 2016, at 19:21, Thomas Mortagne  wrote:
> 
> On Mon, Apr 11, 2016 at 6:38 PM, Vincent Massol  wrote:
>> ok thanks for the help Thomas, I understand now and it seems like a good 
>> idea to support namespaces right now.
>> 
> 
>> One question though: do we have some tools to generate a namespace? In the 
>> getURL() method of the ScriptService, I’ll need to convert the current wiki 
>> id into a namespace and I’d rather not hardcode it if possible.
> 
> The is no platform level helper for this no. Been lazy on this. I
> guess some platform side internal NamespaceUtils (extending
> org.xwiki.component.namespace.NamespaceUtils) with
> toWikiNamespace(String wikiId) would do for now.

FTR, I really don’t like utils classes. IMO this is a sign that we need a 
NameSpace object and some serializer component impl.

BTW just found that Marius had already added a method in the ScriptService for 
webjars:
https://github.com/xwiki/xwiki-platform/blob/4f2f6fa823d3d222851f7001237b0bd5cee2d242/xwiki-platform-core/xwiki-platform-webjars/xwiki-platform-webjars-api/src/main/java/org/xwiki/webjars/script/WebJarsScriptService.java#L264-L264

Thanks
-Vincent

> Thanks
>> -Vincent
>> 
>>> On 11 Apr 2016, at 18:00, Thomas Mortagne  wrote:
>>> 
>>> On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol  wrote:
 
> On 11 Apr 2016, at 15:47, Thomas Mortagne  
> wrote:
> 
> On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol  
> wrote:
>> 
>>> On 11 Apr 2016, at 15:07, Vincent Massol  wrote:
>>> 
 
 On 08 Apr 2016, at 10:42, Thomas Mortagne  
 wrote:
 
 On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol  
 wrote:
> 
>> On 08 Apr 2016, at 10:00, Thomas Mortagne 
>>  wrote:
>> 
>> I'm hesitating, the thing is that what webjars really want to know in
>> practice is the namespace since that what it will provide to
>> ClassLoaderManager so maybe the best is to indicate the namespace
>> instead of the wiki in the URL. It means that webjar service can
>> support both wiki and users right now and any future namespaces
>> (document, space, etc).
> 
> Don’t you think that we need the wiki in order to validate 
> permissions:
> 
> "// 2) so that we can set the current user in the Context and at the 
> same time verify that the current user has
> //View Rights on this wiki"
> 
> At 
> https://github.com/xwiki/xwiki-platform/blob/4f2f6fa823d3d222851f7001237b0bd5cee2d242/xwiki-platform-core/xwiki-platform-webjars/xwiki-platform-webjars-api/src/main/java/org/xwiki/webjars/internal/WebJarsResourceReferenceHandler.java#L120-L120
> 
 
> Of course we could generalize and say that we pass a serialized 
> entity reference (or resource reference) instead of the wikiId. Note 
> that we would also need to pass the entity type (or resource 
> reference type), so it would need to be something like 
> “/wiki:wikiId/…”.
 
 "wiki:wikiId" is a the namespace for wiki with id "wikiId".
 
> 
> Maybe this is too much for now. It’s more work and I’m not sure about 
> the use cases...
 
 It's not really that simple IMO. You will have to change the URL
 format and find an alternative that can work along with the old format
 to not break it. The thing is you could have an extension in any
 namespace, the standard UI just give you wikis choice but it's not the
 case for classloadersmanager/extensionmanager API. As for the user
 case, I don't think installing an extension in a space would be so
 weird compare to installing an extension in a wiki. It does not really
 make much difference for Extension Manager.
>>> 
>>> However we still need to have the wikiId somewhere in the URL because 
>>> we'll need to set the current wiki (at least to validate permissions).
>>> 
>>> So what you’re saying (I think) is that we need 2 more info in the URL: 
>>> wikiId + namespace, right?
> 
> No I'm not saying that. You don't have wikis on one side and
> namespaces on another side being completely different things. Wikis
> have namespaces to represent them, you install an extension on a
> namespace for example (and then XAR extension handler understand from
> "wiki:toto" namespace that it will have to import pages on wiki
> "toto”).
 
 I’m not really familiar with namespaces. Is there a java class to 
 represent them?
 
> How to deal with permission depend on the kind of