search

fedwiki / wiki-client

Federated wiki client-side javascript as a npm module.
Other
115 stars 36 forks source link

Fork from transporter incorrectly seen as delete #199

Closed WardCunningham closed 6 years ago

WardCunningham commented 6 years ago

We suspect complains in the chat can be traced to incomplete logic in #197.

Regarding the trouble forking transported pages, If the screen shot provided is associated with that failure, I notice that DELETE that failed is probably not what you were trying to do. Perhaps when you were trying to fork the transported ghost page into your site, new logic though you were trying to delete the (not yet existing) page. riot

At the least, a fork of a ghost page without rev addressing should not be interpreted as a delete no matter what condition the journal is in (transporters can be lazy).

opn commented 6 years ago

I've made some progress tracking this issue down. For test purposes you can try the examples provided on the following page

The issue at least for the OneTab transporter is that the newly created page has a minimal journal entry rather than a full history of the creation of every element. I assume this is triggering a "delete page" action as per the new logic.

The MediaWiki Transporter also has an creation only journal - so this makes sense. I could get around this issue by restoring the full journal history creation in the transporter. However this might be a good time to consider issues and benefits of Journal simplification?

The journal json that is probably causing the error looks like this:

"journal": [
    {
      "date": 1507026807547,
      "type": "create",
      "item": {
        "story": "",
        "title": "100 Years of Film"
      }
    }
  ],
paul90 commented 6 years ago

This was closed by #200