A subtle problem with the Workflow Application and nested pages

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

A subtle problem with the Workflow Application and nested pages

Clemens Robbenhaar-2
Hi Devs,

 some users reported a problem to me concerning the Publication Workflow Application and the nested pages feature.
The problem is as follows:

 In their old instance (some 6.4.x) they had a draft space and a public space and workflows attaching each page in the draft space with a page in the public space in an 1:1 manner, like:

  Draft.WebHome --> Public.WebHome
  Draft.PageA   --> Public.PageA
  Draft.PageB   --> Public.PageB

Now if a link in, say, PageA in the Draft space points to another page, e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]]
After publishing PageA, the link of the published variant points to the published variant of PageB (and not the variant in the Draft space), which is the desired effect from the users point of view.

Now after migration to 9.10 the situation is as follows:

  Draft.WebHome        --> Public.WebHome
  Draft.PageA.WebHome  --> Public.PageA.WebHome
  Draft.PageB.WebHome  --> Public.PageB.WebHome

Now a link to PageB in PageA looks like: [[link text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the same space, but each in their own space.
Publishing the draft makes the link in the published variant point back to the Draft space, of course. However this is different from the behavior before nested pages and the users experience this as a bug.

A manual solution would be to edit all pages and make the links point to the published variant of the pages. However this is not only a cumbersome and error prone task, but also the users are used to the "automatic" link conversion that made links in the published variant point to published pages and are wont to continue setting links to pages in the draft space, expecting them to point to the "right place" after publishing.
The fact that now titles are used throughout in the navigation tree, and the titles of the draft and published variant are usually the same and thus indistinguishable complicates the problem even more.

To fix this I could write a separate extension that listens to Publish events send from the Workflow extension, and which converts the links in the published variant before it gets saved.
However I remember that I once experienced strange issues where the events were sometimes not send to the event listener in question, probably due some class loader issues or the like.
(I only experienced these problems in a production instance and was not able to hunt them down in a development instance.)

Also I cannot think of a use case where users want to link from a published variant back into the draft space (except for pointing to the draft version of the page itself, which is provided by the panel, however.)

Thus I would like to implement the link transformation in the extension itself. If a link in a page points to a page in the draft space of that workflow, I would change that link in the published variant to point to the corresponding published variant of the link target.
I could add a checkbox to the workflow class so people can switch of that link transformation if they do not want it.


What do you think? Are there any objections to implementing such a feature? Or do you have different ideas how to solve the problem?

Best Regards
Clemens
Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Clemens Robbenhaar-2
Hi Devs,

 as nobody seems to have any objections to this, I will create a Jira issue for it and start working on a feature branch on this problem.

Clemens

> Hi Devs,
>
>  some users reported a problem to me concerning the Publication Workflow Application and the nested pages feature.
> The problem is as follows:
>
>  In their old instance (some 6.4.x) they had a draft space and a public space and workflows attaching each page in the draft space with a page in the public space in an 1:1 manner, like:
>
>   Draft.WebHome --> Public.WebHome
>   Draft.PageA   --> Public.PageA
>   Draft.PageB   --> Public.PageB
>
> Now if a link in, say, PageA in the Draft space points to another page, e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]]
> After publishing PageA, the link of the published variant points to the published variant of PageB (and not the variant in the Draft space), which is the desired effect from the users point of view.
>
> Now after migration to 9.10 the situation is as follows:
>
>   Draft.WebHome        --> Public.WebHome
>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>
> Now a link to PageB in PageA looks like: [[link text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the same space, but each in their own space.
> Publishing the draft makes the link in the published variant point back to the Draft space, of course. However this is different from the behavior before nested pages and the users experience this as a bug.
>
> A manual solution would be to edit all pages and make the links point to the published variant of the pages. However this is not only a cumbersome and error prone task, but also the users are used to the "automatic" link conversion that made links in the published variant point to published pages and are wont to continue setting links to pages in the draft space, expecting them to point to the "right place" after publishing.
> The fact that now titles are used throughout in the navigation tree, and the titles of the draft and published variant are usually the same and thus indistinguishable complicates the problem even more.
>
> To fix this I could write a separate extension that listens to Publish events send from the Workflow extension, and which converts the links in the published variant before it gets saved.
> However I remember that I once experienced strange issues where the events were sometimes not send to the event listener in question, probably due some class loader issues or the like.
> (I only experienced these problems in a production instance and was not able to hunt them down in a development instance.)
>
> Also I cannot think of a use case where users want to link from a published variant back into the draft space (except for pointing to the draft version of the page itself, which is provided by the panel, however.)
>
> Thus I would like to implement the link transformation in the extension itself. If a link in a page points to a page in the draft space of that workflow, I would change that link in the published variant to point to the corresponding published variant of the link target.
> I could add a checkbox to the workflow class so people can switch of that link transformation if they do not want it.
>
>
> What do you think? Are there any objections to implementing such a feature? Or do you have different ideas how to solve the problem?
>
> Best Regards
> Clemens
>
Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Marius Dumitru Florea
In reply to this post by Clemens Robbenhaar-2
On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar <[hidden email]>
wrote:

> Hi Devs,
>
>  some users reported a problem to me concerning the Publication Workflow
> Application and the nested pages feature.
> The problem is as follows:
>
>  In their old instance (some 6.4.x) they had a draft space and a public
> space and workflows attaching each page in the draft space with a page in
> the public space in an 1:1 manner, like:
>
>   Draft.WebHome --> Public.WebHome
>   Draft.PageA   --> Public.PageA
>   Draft.PageB   --> Public.PageB
>
> Now if a link in, say, PageA in the Draft space points to another page,
> e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]]
> After publishing PageA, the link of the published variant points to the
> published variant of PageB (and not the variant in the Draft space), which
> is the desired effect from the users point of view.
>
> Now after migration to 9.10 the situation is as follows:
>
>   Draft.WebHome        --> Public.WebHome
>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>

You should be able to force the application to create terminal pages as a
temporary workaround. Then we need to see if it makes sense to add support
for publishing a hierarchy of nested pages.


>
> Now a link to PageB in PageA looks like: [[link
> text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the
> same space, but each in their own space.
> Publishing the draft makes the link in the published variant point back to
> the Draft space, of course. However this is different from the behavior
> before nested pages and the users experience this as a bug.
>
> A manual solution would be to edit all pages and make the links point to
> the published variant of the pages. However this is not only a cumbersome
> and error prone task, but also the users are used to the "automatic" link
> conversion that made links in the published variant point to published
> pages and are wont to continue setting links to pages in the draft space,
> expecting them to point to the "right place" after publishing.
> The fact that now titles are used throughout in the navigation tree, and
> the titles of the draft and published variant are usually the same and thus
> indistinguishable complicates the problem even more.
>
> To fix this I could write a separate extension that listens to Publish
> events send from the Workflow extension, and which converts the links in
> the published variant before it gets saved.
> However I remember that I once experienced strange issues where the events
> were sometimes not send to the event listener in question, probably due
> some class loader issues or the like.
> (I only experienced these problems in a production instance and was not
> able to hunt them down in a development instance.)
>
> Also I cannot think of a use case where users want to link from a
> published variant back into the draft space (except for pointing to the
> draft version of the page itself, which is provided by the panel, however.)
>
> Thus I would like to implement the link transformation in the extension
> itself. If a link in a page points to a page in the draft space of that
> workflow, I would change that link in the published variant to point to the
> corresponding published variant of the link target.
> I could add a checkbox to the workflow class so people can switch of that
> link transformation if they do not want it.
>
>
> What do you think? Are there any objections to implementing such a
> feature? Or do you have different ideas how to solve the problem?
>
> Best Regards
> Clemens
>
Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Clemens Robbenhaar-2


Am 15.12.2017 10:18 schrieb Marius Dumitru Florea:

> On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar
> <[hidden email]>
> wrote:
>
>> Hi Devs,
>>
>>  some users reported a problem to me concerning the Publication
>> Workflow
>> Application and the nested pages feature.
>> The problem is as follows:
>>
>>  In their old instance (some 6.4.x) they had a draft space and a
>> public
>> space and workflows attaching each page in the draft space with a page
>> in
>> the public space in an 1:1 manner, like:
>>
>>   Draft.WebHome --> Public.WebHome
>>   Draft.PageA   --> Public.PageA
>>   Draft.PageB   --> Public.PageB
>>
>> Now if a link in, say, PageA in the Draft space points to another
>> page,
>> e.g. PageB, this is done via a relative link like [[link
>> text>>doc:PageB]]
>> After publishing PageA, the link of the published variant points to
>> the
>> published variant of PageB (and not the variant in the Draft space),
>> which
>> is the desired effect from the users point of view.
>>
>> Now after migration to 9.10 the situation is as follows:
>>
>>   Draft.WebHome        --> Public.WebHome
>>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>>
>
> You should be able to force the application to create terminal pages as
> a
> temporary workaround. Then we need to see if it makes sense to add
> support
> for publishing a hierarchy of nested pages.
>
>
[...]

The problem here is that the Workflow Publication App does not create
the pages themselves.
Instead the workflow is attached to already existing pages.

At least that is how people around here handle it. Maybe this is simply
the wrong approach?

Clemens
Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Marius Dumitru Florea
On Fri, Dec 15, 2017 at 12:10 PM, Clemens Robbenhaar <[hidden email]
> wrote:

>
>
> Am 15.12.2017 10:18 schrieb Marius Dumitru Florea:
>
>> On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar <
>> [hidden email]>
>> wrote:
>>
>> Hi Devs,
>>>
>>>  some users reported a problem to me concerning the Publication Workflow
>>> Application and the nested pages feature.
>>> The problem is as follows:
>>>
>>>  In their old instance (some 6.4.x) they had a draft space and a public
>>> space and workflows attaching each page in the draft space with a page in
>>> the public space in an 1:1 manner, like:
>>>
>>>   Draft.WebHome --> Public.WebHome
>>>   Draft.PageA   --> Public.PageA
>>>   Draft.PageB   --> Public.PageB
>>>
>>> Now if a link in, say, PageA in the Draft space points to another page,
>>> e.g. PageB, this is done via a relative link like [[link
>>> text>>doc:PageB]]
>>> After publishing PageA, the link of the published variant points to the
>>> published variant of PageB (and not the variant in the Draft space),
>>> which
>>> is the desired effect from the users point of view.
>>>
>>> Now after migration to 9.10 the situation is as follows:
>>>
>>>   Draft.WebHome        --> Public.WebHome
>>>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>>>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>>>
>>>
>> You should be able to force the application to create terminal pages as a
>> temporary workaround. Then we need to see if it makes sense to add support
>> for publishing a hierarchy of nested pages.
>>
>>
>> [...]
>
> The problem here is that the Workflow Publication App does not create the
> pages themselves.
>


> Instead the workflow is attached to already existing pages.
>

I thought there is a template that is used to create the pages. If these
are plain wiki pages then indeed, I don't have other options.


>
> At least that is how people around here handle it. Maybe this is simply
> the wrong approach?
>
> Clemens
>
Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Clemens Robbenhaar-2


On Fri, Dec 15, 2017m 17:36  Marius Dumitru Florea wrote:

> On Fri, Dec 15, 2017 at 12:10 PM, Clemens Robbenhaar
> <[hidden email]> wrote:
>
>>
>>
>> Am 15.12.2017 10:18 schrieb Marius Dumitru Florea:
>>
>>> On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar <
>>> [hidden email]>
>>> wrote:
>>>
>>> Hi Devs,
>>>>
>>>>  some users reported a problem to me concerning the Publication
>>>> Workflow
>>>> Application and the nested pages feature.
>>>> The problem is as follows:
>>>>
>>>>  In their old instance (some 6.4.x) they had a draft space and a
>>>> public
>>>> space and workflows attaching each page in the draft space with a
>>>> page in
>>>> the public space in an 1:1 manner, like:
>>>>
>>>>   Draft.WebHome --> Public.WebHome
>>>>   Draft.PageA   --> Public.PageA
>>>>   Draft.PageB   --> Public.PageB
>>>>
>>>> Now if a link in, say, PageA in the Draft space points to another
>>>> page,
>>>> e.g. PageB, this is done via a relative link like [[link
>>>> text>>doc:PageB]]
>>>> After publishing PageA, the link of the published variant points to
>>>> the
>>>> published variant of PageB (and not the variant in the Draft space),
>>>> which
>>>> is the desired effect from the users point of view.
>>>>
>>>> Now after migration to 9.10 the situation is as follows:
>>>>
>>>>   Draft.WebHome        --> Public.WebHome
>>>>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>>>>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>>>>
>>>>
>>> You should be able to force the application to create terminal pages
>>> as a
>>> temporary workaround. Then we need to see if it makes sense to add
>>> support
>>> for publishing a hierarchy of nested pages.
>>>
>>>
>>> [...]
>>
>> The problem here is that the Workflow Publication App does not create
>> the
>> pages themselves.
>>
>
>
>> Instead the workflow is attached to already existing pages.
>>
>
> I thought there is a template that is used to create the pages. If
> these
> are plain wiki pages then indeed, I don't have other options.
>

I created https://jira.xwiki.org/browse/XAWORKFLOW-37 and will give it a
try in the next days.

Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Anca Luca
In reply to this post by Clemens Robbenhaar-2
Hello Clemens,

Indeed, this is _one_ of the problems that the workflow application has on
a "nested" environment.

I think it's a good approach for the fix, the only thing that you should
try to take care of is to make this as generic as possible wrt the
configured draft space in the publication workflow config of the document
being published (fix links relative to this space). Don't hesitate, if
needed, to add a configuration of the "default publication space" in the
publication workflow config, I found the need for it in other situations as
well, so it won't hurt.

Also, one issue I can think of (which is related to the other issues that
publication workflow has on nested) is that the page to which the link is
might not yet be published, and in this case, imo, the link should be
refactored and be a "broken link" until the target page gets published.

Thanks for working on this,
Anca

On Thu, Nov 30, 2017 at 12:10 AM, Clemens Robbenhaar <[hidden email]
> wrote:

> Hi Devs,
>
>  some users reported a problem to me concerning the Publication Workflow
> Application and the nested pages feature.
> The problem is as follows:
>
>  In their old instance (some 6.4.x) they had a draft space and a public
> space and workflows attaching each page in the draft space with a page in
> the public space in an 1:1 manner, like:
>
>   Draft.WebHome --> Public.WebHome
>   Draft.PageA   --> Public.PageA
>   Draft.PageB   --> Public.PageB
>
> Now if a link in, say, PageA in the Draft space points to another page,
> e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]]
> After publishing PageA, the link of the published variant points to the
> published variant of PageB (and not the variant in the Draft space), which
> is the desired effect from the users point of view.
>
> Now after migration to 9.10 the situation is as follows:
>
>   Draft.WebHome        --> Public.WebHome
>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>
> Now a link to PageB in PageA looks like: [[link
> text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the
> same space, but each in their own space.
> Publishing the draft makes the link in the published variant point back to
> the Draft space, of course. However this is different from the behavior
> before nested pages and the users experience this as a bug.
>
> A manual solution would be to edit all pages and make the links point to
> the published variant of the pages. However this is not only a cumbersome
> and error prone task, but also the users are used to the "automatic" link
> conversion that made links in the published variant point to published
> pages and are wont to continue setting links to pages in the draft space,
> expecting them to point to the "right place" after publishing.
> The fact that now titles are used throughout in the navigation tree, and
> the titles of the draft and published variant are usually the same and thus
> indistinguishable complicates the problem even more.
>
> To fix this I could write a separate extension that listens to Publish
> events send from the Workflow extension, and which converts the links in
> the published variant before it gets saved.
> However I remember that I once experienced strange issues where the events
> were sometimes not send to the event listener in question, probably due
> some class loader issues or the like.
> (I only experienced these problems in a production instance and was not
> able to hunt them down in a development instance.)
>
> Also I cannot think of a use case where users want to link from a
> published variant back into the draft space (except for pointing to the
> draft version of the page itself, which is provided by the panel, however.)
>
> Thus I would like to implement the link transformation in the extension
> itself. If a link in a page points to a page in the draft space of that
> workflow, I would change that link in the published variant to point to the
> corresponding published variant of the link target.
> I could add a checkbox to the workflow class so people can switch of that
> link transformation if they do not want it.
>
>
> What do you think? Are there any objections to implementing such a
> feature? Or do you have different ideas how to solve the problem?
>
> Best Regards
> Clemens
>
Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Eduard Moraru
Hi,

Yes, this makes sense because in the previous "doc:PageB" version, the link
was in relative form (no space specified) and it was resolved to the
current space (which was "Public" when PageA was in the "Public" space).
After NS, using "doc:Draft.PageB.WebHome" means using a very explicit and
absolute reference that does no resolution so it will behave the same,
regardless of the context where PageA(.WebHome) is located (hence, it will
link to the "Draft" space).

There are a couple of cases where you could get away with it without any
refactoring and using advanced knowledge on xwiki's link syntax resolution
algorithm. TL;DR; These are the ones that involve links coming from higher
in the hierarchy towards pages lower in the hierarchy or when linking
between sibling pages (i.e. same level in the hierarchy).
You can find more details on
http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax/?syntax=2.1&section=Links
(see the "[[.PageA]]" and "[[.PageA.PageB]]" examples and then the details
on the resolution of "Untyped" links).

Now, I have mentioned this just for the sake of completeness on the matter
and would not really advise to rely on these "relative" links, since they
are currently more of a side effect of our current model than a feature
that is well-thought and recommended (e.g. we don't have support for
relative links upper in the hierarchy like "../../PageX").

Given the proper support for relative links in our syntax, indeed, the
listener and link fixing solution would be the recommended one.

Hope this helps,
Eduard

On Sat, Dec 16, 2017 at 2:06 PM, Anca Luca <[hidden email]> wrote:

> Hello Clemens,
>
> Indeed, this is _one_ of the problems that the workflow application has on
> a "nested" environment.
>
> I think it's a good approach for the fix, the only thing that you should
> try to take care of is to make this as generic as possible wrt the
> configured draft space in the publication workflow config of the document
> being published (fix links relative to this space). Don't hesitate, if
> needed, to add a configuration of the "default publication space" in the
> publication workflow config, I found the need for it in other situations as
> well, so it won't hurt.
>
> Also, one issue I can think of (which is related to the other issues that
> publication workflow has on nested) is that the page to which the link is
> might not yet be published, and in this case, imo, the link should be
> refactored and be a "broken link" until the target page gets published.
>
> Thanks for working on this,
> Anca
>
> On Thu, Nov 30, 2017 at 12:10 AM, Clemens Robbenhaar <
> [hidden email]
> > wrote:
>
> > Hi Devs,
> >
> >  some users reported a problem to me concerning the Publication Workflow
> > Application and the nested pages feature.
> > The problem is as follows:
> >
> >  In their old instance (some 6.4.x) they had a draft space and a public
> > space and workflows attaching each page in the draft space with a page in
> > the public space in an 1:1 manner, like:
> >
> >   Draft.WebHome --> Public.WebHome
> >   Draft.PageA   --> Public.PageA
> >   Draft.PageB   --> Public.PageB
> >
> > Now if a link in, say, PageA in the Draft space points to another page,
> > e.g. PageB, this is done via a relative link like [[link
> text>>doc:PageB]]
> > After publishing PageA, the link of the published variant points to the
> > published variant of PageB (and not the variant in the Draft space),
> which
> > is the desired effect from the users point of view.
> >
> > Now after migration to 9.10 the situation is as follows:
> >
> >   Draft.WebHome        --> Public.WebHome
> >   Draft.PageA.WebHome  --> Public.PageA.WebHome
> >   Draft.PageB.WebHome  --> Public.PageB.WebHome
> >
> > Now a link to PageB in PageA looks like: [[link
> > text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the
> > same space, but each in their own space.
> > Publishing the draft makes the link in the published variant point back
> to
> > the Draft space, of course. However this is different from the behavior
> > before nested pages and the users experience this as a bug.
> >
> > A manual solution would be to edit all pages and make the links point to
> > the published variant of the pages. However this is not only a cumbersome
> > and error prone task, but also the users are used to the "automatic" link
> > conversion that made links in the published variant point to published
> > pages and are wont to continue setting links to pages in the draft space,
> > expecting them to point to the "right place" after publishing.
> > The fact that now titles are used throughout in the navigation tree, and
> > the titles of the draft and published variant are usually the same and
> thus
> > indistinguishable complicates the problem even more.
> >
> > To fix this I could write a separate extension that listens to Publish
> > events send from the Workflow extension, and which converts the links in
> > the published variant before it gets saved.
> > However I remember that I once experienced strange issues where the
> events
> > were sometimes not send to the event listener in question, probably due
> > some class loader issues or the like.
> > (I only experienced these problems in a production instance and was not
> > able to hunt them down in a development instance.)
> >
> > Also I cannot think of a use case where users want to link from a
> > published variant back into the draft space (except for pointing to the
> > draft version of the page itself, which is provided by the panel,
> however.)
> >
> > Thus I would like to implement the link transformation in the extension
> > itself. If a link in a page points to a page in the draft space of that
> > workflow, I would change that link in the published variant to point to
> the
> > corresponding published variant of the link target.
> > I could add a checkbox to the workflow class so people can switch of that
> > link transformation if they do not want it.
> >
> >
> > What do you think? Are there any objections to implementing such a
> > feature? Or do you have different ideas how to solve the problem?
> >
> > Best Regards
> > Clemens
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: A subtle problem with the Workflow Application and nested pages

Clemens Robbenhaar-2

Actually using a listener to rewrite the links has been less complicated than what I thought;
for now I have a version finished locally (but not pushed yet) that rewrites the links
to pages from the draft variant to the published variant with just a few lines of code.

Now I need to handle the case for attachments, and also for embedded images.
There is also a problem for macros like the "display" an "include" macro,
but because figuring out which macro field is actually containing an entity reference
seems not possible to me (except by hardwiring the known macro/field name combinations)
and also because these macros seem to be used mostly by "advanced" users who might figure
out by themselves that they better point to the published variant of the page,
I prefer not to handle these cases.

About the other issues which might appear with nested pages, I found these issues:
  https://jira.xwiki.org/browse/XAWORKFLOW-34
  https://jira.xwiki.org/browse/XAWORKFLOW-20

Are there more issues that I overlooked? I hope to find the time to look into these
issues, too, but with my current workload I am hesitating to make any promises.

Thanks,
Clemens

> Hi,
>
> Yes, this makes sense because in the previous "doc:PageB" version, the link
> was in relative form (no space specified) and it was resolved to the
> current space (which was "Public" when PageA was in the "Public" space).
> After NS, using "doc:Draft.PageB.WebHome" means using a very explicit and
> absolute reference that does no resolution so it will behave the same,
> regardless of the context where PageA(.WebHome) is located (hence, it will
> link to the "Draft" space).
>
> There are a couple of cases where you could get away with it without any
> refactoring and using advanced knowledge on xwiki's link syntax resolution
> algorithm. TL;DR; These are the ones that involve links coming from higher
> in the hierarchy towards pages lower in the hierarchy or when linking
> between sibling pages (i.e. same level in the hierarchy).
> You can find more details on
> http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax/?syntax=2.1&section=Links
> (see the "[[.PageA]]" and "[[.PageA.PageB]]" examples and then the details
> on the resolution of "Untyped" links).
>
> Now, I have mentioned this just for the sake of completeness on the matter
> and would not really advise to rely on these "relative" links, since they
> are currently more of a side effect of our current model than a feature
> that is well-thought and recommended (e.g. we don't have support for
> relative links upper in the hierarchy like "../../PageX").
>
> Given the proper support for relative links in our syntax, indeed, the
> listener and link fixing solution would be the recommended one.
>
> Hope this helps,
> Eduard
>
> On Sat, Dec 16, 2017 at 2:06 PM, Anca Luca <[hidden email]> wrote:
>
>> Hello Clemens,
>>
>> Indeed, this is _one_ of the problems that the workflow application has on
>> a "nested" environment.
>>
>> I think it's a good approach for the fix, the only thing that you should
>> try to take care of is to make this as generic as possible wrt the
>> configured draft space in the publication workflow config of the document
>> being published (fix links relative to this space). Don't hesitate, if
>> needed, to add a configuration of the "default publication space" in the
>> publication workflow config, I found the need for it in other situations as
>> well, so it won't hurt.
>>
>> Also, one issue I can think of (which is related to the other issues that
>> publication workflow has on nested) is that the page to which the link is
>> might not yet be published, and in this case, imo, the link should be
>> refactored and be a "broken link" until the target page gets published.
>>
>> Thanks for working on this,
>> Anca
>>
>> On Thu, Nov 30, 2017 at 12:10 AM, Clemens Robbenhaar <
>> [hidden email]
>>> wrote:
>>
>>> Hi Devs,
>>>
>>>  some users reported a problem to me concerning the Publication Workflow
>>> Application and the nested pages feature.
>>> The problem is as follows:
>>>
>>>  In their old instance (some 6.4.x) they had a draft space and a public
>>> space and workflows attaching each page in the draft space with a page in
>>> the public space in an 1:1 manner, like:
>>>
>>>   Draft.WebHome --> Public.WebHome
>>>   Draft.PageA   --> Public.PageA
>>>   Draft.PageB   --> Public.PageB
>>>
>>> Now if a link in, say, PageA in the Draft space points to another page,
>>> e.g. PageB, this is done via a relative link like [[link
>> text>>doc:PageB]]
>>> After publishing PageA, the link of the published variant points to the
>>> published variant of PageB (and not the variant in the Draft space),
>> which
>>> is the desired effect from the users point of view.
>>>
>>> Now after migration to 9.10 the situation is as follows:
>>>
>>>   Draft.WebHome        --> Public.WebHome
>>>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>>>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>>>
>>> Now a link to PageB in PageA looks like: [[link
>>> text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the
>>> same space, but each in their own space.
>>> Publishing the draft makes the link in the published variant point back
>> to
>>> the Draft space, of course. However this is different from the behavior
>>> before nested pages and the users experience this as a bug.
>>>
>>> A manual solution would be to edit all pages and make the links point to
>>> the published variant of the pages. However this is not only a cumbersome
>>> and error prone task, but also the users are used to the "automatic" link
>>> conversion that made links in the published variant point to published
>>> pages and are wont to continue setting links to pages in the draft space,
>>> expecting them to point to the "right place" after publishing.
>>> The fact that now titles are used throughout in the navigation tree, and
>>> the titles of the draft and published variant are usually the same and
>> thus
>>> indistinguishable complicates the problem even more.
>>>
>>> To fix this I could write a separate extension that listens to Publish
>>> events send from the Workflow extension, and which converts the links in
>>> the published variant before it gets saved.
>>> However I remember that I once experienced strange issues where the
>> events
>>> were sometimes not send to the event listener in question, probably due
>>> some class loader issues or the like.
>>> (I only experienced these problems in a production instance and was not
>>> able to hunt them down in a development instance.)
>>>
>>> Also I cannot think of a use case where users want to link from a
>>> published variant back into the draft space (except for pointing to the
>>> draft version of the page itself, which is provided by the panel,
>> however.)
>>>
>>> Thus I would like to implement the link transformation in the extension
>>> itself. If a link in a page points to a page in the draft space of that
>>> workflow, I would change that link in the published variant to point to
>> the
>>> corresponding published variant of the link target.
>>> I could add a checkbox to the workflow class so people can switch of that
>>> link transformation if they do not want it.
>>>
>>>
>>> What do you think? Are there any objections to implementing such a
>>> feature? Or do you have different ideas how to solve the problem?
>>>
>>> Best Regards
>>> Clemens
>>>
>>


--
Clemens Klein-Robbenhaar
Belßstrasse 34E
("In der Puppenstube")
12277 Berlin
0177 61 33 529