Server error message (404) when clicking on tasks migrated from Confluence using recent versions of confluence-xml

[raphj]

This is because the task document doesn't exist. And that is because during migration, the document creating event is discarded in AbstractTaskEventListener.java by the first condition of the onEvent method:

    @Override
    public void onEvent(Event event, Object source, Object data)
    {
        if (this.observationContext.isIn(
            otherEvent -> otherEvent instanceof BeginFoldEvent && !configuration.getNotSkippedFoldEvents()
                .contains(otherEvent.getClass().getName())))
        {
            return;
        }
        XWikiContext context = (XWikiContext) data;
        XWikiDocument document = (XWikiDocument) source;

        processEvent(document, context, event);
    }

I would guess that this is because we are indeed in a folded event while filtering, and I would also guess that it used to work because of the nested page migration, which we got rid of.

I believe one, or two of those two things are needed:

• lazily create task documents when they don't exist, so the task manipulation doesn't totally fail when clicking on checkbox (to make the app more defensive against such issues, or maybe provide a more user-friendly message when that happens. I'd be more a fan of an auto fixing situation though)
• update this condition so the event is handled. We need to consider that the migrator can produce several revisions. Maybe DocumentCreatedEvent and DocumentUpdatedEvent event types would be better suited than *ing events.

[trrenty]

Hello, @raphj . To fix this issue we could modify the admin section of the task manager the following way:

Currently, the value of the text area is: org.xwiki.contrib.nestedpagesmigrator.internal.executor.BeginMigrationEvent . The idea of this configuration option is that we don't want the listeners to be triggered during fold events, but in special cases such as confluence migrations, we want the listeners to trigger. NPM was the last step of a migration and it made sense for the listeners to trigger at that time.

I tested the proposed modification it works fine.

For clients that already migrated, they can simply save the page that contains the tasks and the associated task pages should be created. (so they dont need to migrate again)

As you mentioned, this might have an impact on the performance of the migrator. If the DocumentUpdated event doesn't trigger for revisions of the documents, then it would be indeed a good idea to use it.

I also like the idea of lazily creating the task documents. This would also cover the case when they dont get created by some unforeseen reason. (which doesn't really happen, but its a nice bullet proofing)

[raphj]

Hi @trrenty,

For some unknown reason I didn't manage to check whether DocumentUpdated / DocumentUpdating events are produced several time during filtering, I didn't see the events at all with a simple script component.

Your solution looks good, though it would be nice to check if the event isn't triggered too many times (for each revision). Fast migrations is important.

[trrenty]

The DocumentUpdated event fires as many times as the DocumentUpdating event. Making any changes in this regard won't solve the issue

Lazily creating the task presents us with a problem. When changing the status of a task via the checkbox present in the UI, we make a REST request to modify the task page associated with the modified task macro. This will emit an event that will trigger a listener whose responsability is to sync the task page with the task macro (modify the task macro inside the content of the page).

Taking this into consideration, we can't create the missing task page because we lack the information needed to populate it but also because we depend on that function for normal tasks.

I will implement the solution I proposed for now. From my tests, when running the largest migration i had (which isnt so big - 413 pages), i measured 31s without the task listeners and 32s with them executing. Second run: 32s, 34s; Third run: 30s, 33s.