Page MenuHomePhabricator

Investigation how to automatically add the now-commons-equivalent template to the file on the source wiki
Closed, ResolvedPublic2 Story Points

Description

AcceptanceCriteria

  • Determine whether the extension is actually able to make an edit in the name of the user, on that file page of that source wiki
  • If that is not possible, would there be another sensible option (that is not exploding in scope)

Notes

  • Why did this fail the first time? --> Fisch did some research T160181: Display new location in source wiki
  • What would be part of a follow up ticket would be adding a confirmation prompt allowing users to take a decision whether that step should happen

Only relevant in the future
Ideas for actual implementation acceptance criteria:

  • Add a config flag to allow people deciding whether they want auto edits in the other direction.

Idea for future: On the target wiki, instead of redirecting to a success page with success message, we would directly redirect to the new file page, with the success message being displayed there

  • If we know the now-commons-equivalent template for a source wiki, the FileExporter makes an edit in the source wiki, in the name of the user who moved the file
    • The edit would add the now-commons-equivalent template to the top of the page
    • The edit summary would say This file is now on Commons (moved with FileImporter) in the name of the moving user
  • Don't make this default behavior just yet, we would want to add a confirmation page before, once it is clear that and how this can be done. TODO should this be enablable by adding sth to the URL or so, so we can test it already?

Event Timeline

Lea_WMDE created this task.May 28 2019, 8:07 PM
Pikne added a subscriber: Pikne.EditedMay 29 2019, 6:27 AM

Administrator might want to delete the file straight away, instead of tagging it as "Now Commons". Also, on English Wikipedia a few exported files are tagged as Keep local, and not as "Now Commons". I think it's good if adding "Now Commons" was easier, but it would be also good if FileImporter would ask for confirmation to tag the source page, or there was another way to skip editing the source wiki.

Thanks for the hint @Pikne! It sounds like confirmation would be a good idea.

Lea_WMDE renamed this task from Automatically add the now-commons-equivalent template to the file on the source wiki to Investigation how to automatically add the now-commons-equivalent template to the file on the source wiki.May 29 2019, 9:32 AM
Lea_WMDE updated the task description. (Show Details)
Lea_WMDE updated the task description. (Show Details)Jun 3 2019, 1:11 PM
Lea_WMDE set the point value for this task to 5.

In T160181, Fisch left this final breadcrumb:

While working on this and starting a first approach with calling the API of the source wiki via CentralAuth token, we decided that the proper/better to do this is would be submitting a job on the sourcewiki that does the edit

This sounds like a good approach, but leaves us in a bad place if the job fails. I propose that we try to combine this source wiki job with a notification. If the source wiki job fails, then the importing user receives a notification about the failure, which includes the text that should still be appended to the source file. This is of course subject to the "two-phase commit" problem, where we probably cannot guarantee that the failure notification is sent in 100% of cases, but "good enough" is probably good enough. We might also want to notify on success, depending on configuration and user preferences?

I'm not sure we need a central auth token. These seem to be used for CORS requests from the client, for example if we redirected to a page which then made the API edits from the importing user's browser. On the other hand, I still don't know what the alternatives are.

I might be missing something here but couldn't we simply do the following:

After a successful import with FileImporter,

  1. we automatically redirect the user back to the source wiki
  2. we let FileExporter take care of tagging the file
  3. once the user confirms the changes to the source file
  4. they are automatically redirected to the new file on the destination wiki

(pro) process would work for third-party wikis
(pro) no need for job queues or notifications
(con) one extra button click on the user's side (although users may want the confirmation page anyway)

WMDE-Fisch moved this task from Sprint Backlog to Doing on the WMDE-QWERTY-Sprint-2019-05-29 board.
JStrodt_WMDE updated the task description. (Show Details)Jun 6 2019, 9:00 PM

I fiddled with this some time now, basically trying to get an example working for me on my local multi-wiki setup. - It felt a bit like history repeating because a was doing the same thing when originally working on T160181: Display new location in source wiki .

Although I'm still not able to get my local multi-wiki work as needed to do cross-wiki requests, I'm quite confident, that we can do these. The Echo extension is doing something similar when triggering notifications on foreign wikis and even have implemented a class for these cross-wiki requests [1]. Back in the days while exploring T160181 I also created a patch for the FileImporter roughly by c&p of the Echo class with adjustments made to fit into our setup [2].

Reading through the old stuff I think we did not really stop working on that because it's impossible, it was more because we were undecided if a job is not the better way to do it. And then we stalled it. ( Now I think a job is not better, it's best we go for the cross wiki edit. )

So, anyone else wants to give a multi wiki setup a try? ^^'

[1] https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/a334ab5d34c00a223e7d8f75b1b7b67751bbbfd8/includes/ForeignWikiRequest.php
[2] https://gerrit.wikimedia.org/r/386205/

Local vagrant environment with the centralauth role enabled is behaving well, I'll use that to debug our proof-of-concept patch tomorrow.

WMDE-Fisch changed the point value for this task from 5 to 2.
WMDE-Fisch moved this task from Sprint Backlog to Doing on the WMDE-QWERTY-Sprint-2019-06-12 board.

The patch works as intended, now. Only two minor changes: I had to change the action=edit request to a POST, and we needed an intermediate call to obtain a csrftoken. This approach will be fine!

Vagrant tips:

vagrant roles enable centralauth fileimporter

Upload a test file to http://centralauthtest.wiki.local.wmftest.net:8080
Import the file from http://dev.wiki.local.wmftest.net:8080/wiki/Special:ImportFile

awight closed this task as Resolved.Jun 25 2019, 2:58 PM