[xwiki-devs] Will XWiki Activity Stream deprecation affect activitystream_events table?

[ktc]

Hi devs,

Right now we are building a feature based on XWiki Activity Stream and get
data from activitystream_events table from database. We've heard that XWiki
will replace Activity Stream with Notification. Does this mean
activitystream_events table will be deprecated as well? If it is, do you
have any suggestions for replacement like where we can get similar data from
database and which application/extension with similar support features that
we can rely on? Thanks a lot!



--
Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

Re: [xwiki-devs] A subtle problem with the Workflow Application and nested pages

[Clemens Robbenhaar]

On Fri, Dec 15, 2017m 17:36  Marius Dumitru Florea wrote:
On Fri, Dec 15, 2017 at 12:10 PM, Clemens Robbenhaar 
 wrote:





Am 15.12.2017 10:18 schrieb Marius Dumitru Florea:


On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar <
c.robbenh...@posteo.de>
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.

Re: [xwiki-devs] A subtle problem with the Workflow Application and nested pages

[Marius Dumitru Florea]

On Fri, Dec 15, 2017 at 12:10 PM, Clemens Robbenhaar  wrote:

>
>
> Am 15.12.2017 10:18 schrieb Marius Dumitru Florea:
>
>> On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar <
>> c.robbenh...@posteo.de>
>> 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
>

Re: [xwiki-devs] [XWiki Day] BFD#158

[Alex Cotiugă]

Results: http://www.xwiki.org/xwiki/bin/view/Blog/Bug%20Fixing%20Day%20158.

Thanks,
Alex

On Wed, Dec 13, 2017 at 6:33 PM, Alex Cotiugă 
wrote:

> Hello devs,
>
> This Thursday is BFD#158:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays
>
> Our current status is:
>
> * -13 bugs over 120 days (4 months), i.e. we need to close 13 bugs to have
> created bugs # = closed bugs #
> * -55 bugs over 365 days (1 year)
> * -49 bugs over 500 days (between 1 and 2 years)
> * -213 bugs over 1600 days (4.3 years)
> * -676 bugs since the beginning of XWiki
>
> See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
>
>
> Here's the BFD#158 dashboard to follow the progress during the day:
> https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13933
>
> Happy Bug Fixing Day,
> Alex
>

Re: [xwiki-devs] A subtle problem with the Workflow Application and nested pages

[Clemens Robbenhaar]

Am 15.12.2017 10:18 schrieb Marius Dumitru Florea:
On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar 


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

Re: [xwiki-devs] A subtle problem with the Workflow Application and nested pages

[Marius Dumitru Florea]

On Thu, Nov 30, 2017 at 1:10 AM, Clemens Robbenhaar 
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
>