Extension:MirrorTools/Tasks


 * ✅ pushbot -- handle mirrornorcedit
 * ✅ pullbot -- get the redirect ID (it now should be easy to find the comment2)
 * ✅ Grep to find all the log actions; document them in Manual:Log actions
 * ✅ move &mdash; yup, we'll need this too, although the only revisions that will move will be the ones on the Wikipedia page that's being moved. In other words, suppose article X contains revisions 1, 2, and 4 (from Wikipedia) and 3, 5, and 6 (Inclupedia-only). Wikipedia article X moves to Y. Only revisions 1, 2, and 4 move; 3, 5, and 6 remain where they are and are buried under the new redirect to Y. Now suppose there already was an Inclupedia article Y that had revisions 7, 8, and 9. No matter; revisions 1, 2, and 4 get merged into its history. If Y subsequently gets moved to Z on Wikipedia, only revisions 1, 2, and 4 move to Z. You get the gist.
 * ✅ delete &mdash; this will be done as just an informational log entry, and as an event that causes page control to pass from one wiki to the other.
 * Scope out implications of move_redir.
 * import &mdash; somehow we'll need to implement this. Looks like it'll be a variation of delete-restore. Import from file and import interwiki.
 * merge &mdash; Merge history. This'll be interesting. We'll need to make sure we're only merging the remote revisions.
 * renameuser &mdash; What does this do, exactly? We'll probably need to use rev_mt_user for this.
 * upload &mdash; yup, we'll need to mirror these, unless we're going to rely on the instantcommons. There'll be upload-overwrite and upload-upload.
 * Semi-deletion.
 * Updating all the links, caches, etc. after these mirror actions.

Cancelled

 * newusers &mdash; Yeah, we'll need this.
 * patrol &mdash; it would be nice to include as an optional feature, although I'm not sure how much demand there will be for it.
 * protect &mdash; so that we know whether to bother referring Wikipedia users to the Wikipedia edit page when they try to edit. (Of course, there's always the Override: namespace...)