Wikimedia Bugzilla is closed!

This sounds like a good idea, as long as it's possible to display 50 or 100 edits at a time for enormous histories, and it's possible to select all edits besides one or two (like the invert selection button). I assume that the edits that are left behind would be placed in the archive table so they wouldn't clutter the page history.

I always use selective undeletion for history merges, so this wouldn't entireley supercede the selective undeletion feature. With my method, where A is the current title of the page and b is the one with the edits  that need to be merged, I history merge like this: move page A to page B (Page B is deleted to make way for the page move), undelete old content edits of B, move B back to A, undelete remaining redirect edits of B. Maybe I'm over-fussy, but I don't like adding irrelevant redirect edits to an article's page history.

Minor clarification: if this function existed, then one could package all the deletion tools and resolve bug 21279 by simply making the problem never arise:

1/ Add RevisionDelete
2/ Add RevisionMove
3/ Prevent selective undelete (only allow full delete/full restore)
4/ Prevent RevisionDelete or RevisionMove of deleted revisions (must be undeleted first)

Effects/results:

1/ Any redaction would need to be done by RevDelete not traditional "vanishing" of a revision (and undeleting then redacting if it was a deleted revision)
2/ Any page merge or copy/paste fix would need to be done using RevisionMove not traditional delete
3/ Traditional delete exists, but only to delete/undelete full pages
4/ Traditional partial delete (ie full delete + partial restore) is phased out by making it impossible; one can only delete to fully delete or fully restore a page, anything else must be done by RevDelete redaction, or RevisionMove)
5/ All traditional uses of deletion are still fully available, but traditonal partial delete becomes deprecated/redundant/historic, and RevDelete never needs to be used (or able to be used) on a deleted revision, which fixes bug 21279.

As long as the logging is good, this would also have the effect of making history merges a lot more reversible than now.

> 3/ Prevent selective undelete (only allow full delete/full restore)

What about copyvios? What about people who just want to clear the history of their userpage?

I think we should still allow selective undeletion.

(In reply to comment #4)
> > 3/ Prevent selective undelete (only allow full delete/full restore)
> 
> What about copyvios? 

These can be deleted using RevisionDelete, if necessary

>What about people who just want to clear the history of
> their userpage?

I don't see why we need to support this ability. The whole purpose of the page history is to record all the changes that led to the current version. Deleting all but the current revision defeats the purpose of having the history (by deliberately obscuring it), and if anyone but the user made a substantial edit, it could be a license violation.

> I think we should still allow selective undeletion.
> 

Nonetheless, disabling selective deletion just seems like unnecessarily limiting choice. 

I suppose the ability to disable it on a site-by-site basis could be provided and a discussion be held whether we want to disable it on en.wiki. 

(In reply to comment #5)
> What about copyvios? What about people who just want 
> to clear the history of their userpage?

Both are easily handled by RevisionDelete. In the former case the copyvio is placed out of public access completely, and inaccessible to non-admins, but the editor's name is not (it's not a copyvio), nor is the fact there was a deletion. Net benefit.

In the latter case a user who wants to completely delete their user page or talk page can. But a user who wants to selectively remove some material, it's again arguably beneficial that the record shows there were edits there at some point, otherwise the record has actually become falsified; the page history is made to appear as if nothing took place when in fact a great deal may have taken place. Redaction's more honest.

Per comment #5, a site by site on disabling selective deletion would be fine. The problem is that right now selective deletion is breaking links everywhere, badly. Doing this would allow an easy fix to all that, probably _much_ easier than trying to fix major link-breaking bug #21279, while simultaneously improving history merges and copypaste fixes (comment #3) and improving transparency of page histories where selective deletion is traditionally used (comment #5). 

That in itself could be compelling, if delete link breakage can't be otherwise easily fixed.

Considering that this bug is inactive for such a long time now, I'm going to be bold and try to fix it.

Here's what I'd like to to:

Create a new special page "Special:RevisionMove", that allows selective move of revisions of a page – for admins only (by default; there will be a new user right), because this can mess up histories pretty badly.
I'm going to try to make it possible to merge Special:MovePage into this (in case we want to do that some distant time in the future).

The UI for selecting revisions would use same as with RevisionDeleting in the page history, with a new button "Move selected revisions". The rest would also look pretty similar to the revision delete page.

Considering the fact that we want to move away from the archive table system, this probably will only work for not-deleted pages.

When moving a set of revisions, the special page has to differentiate between an existing target or a nonexisting one. In the latter case, a new page has to be created.

Any ideas, comments, suggestions?

One problem might be logging of such events. It is not feasible to have a log entry for each individual moved revision, but an entry like "x Revisions have been moved" doesn't tell you *which* revisions were moved.

On the other hand, RevisionDelete has the same problem and there aren't many complaints about that.

But that isn't enabled on WMF wiki's yet...

It is for oversights and stewards.

By imposing permission restrictions, I think we can justify this lack of transparency. Admins can do a lot of nasty stuff, this would just be one of them.

(In reply to comment #9)
> One problem might be logging of such events. It is not feasible to have a log
> entry for each individual moved revision, but an entry like "x Revisions have
> been moved" doesn't tell you *which* revisions were moved.
> 
> On the other hand, RevisionDelete has the same problem and there aren't many
> complaints about that.

At the risk of proliferating an extra table or an extra field, this is a one-way lookup, from (log action id) -> (list of revisions) or (log action id) -> (html string containing list of revision links). It should not be difficult to have a log entry like:

  "User X moved [[LINK | 17 revisions]] from [[article-1]]
  to [[article-2]] (REASON)"

or

  "User X changed visibility of [[LINK | 17 revisions]] of 
  [[article-1]] from OLD-VIS to NEW-VIS (REASON)"

with the link going directly to the revision or revdelete page if one revision was moved, or a hoverable list, or a list of revisions (or a list collapsed on the revdelete page) if more than one was moved.

(In reply to comment #8)
> Here's what I'd like to to:
> (Snip)
> Considering the fact that we want to move away from the archive table system,
> this probably will only work for not-deleted pages.
> 
> When moving a set of revisions, the special page has to differentiate between
> an existing target or a nonexisting one. In the latter case, a new page has to
> be created.
> 
> Any ideas, comments, suggestions?


1/ Moving only undeleted revisions works and can help keep it clean. If deleted revisions are involved then the deleted revisions can be undeleted, moved, then (if applicable) any deletable content removed using RevisionDelete. I think this is what you meant?

2/ A few "ease of use" suggestions to throw into the mix:

* An "undo this move" button. RevisionMove needs a one click undo, as RevDelete effectively has. People make mistakes and will need to quickly reverse "whatever they just did".

* A "Preserve deletion status?" option that's available if any revisions are deleted. Checking the box means that RevisionMove will undelete these, and revisiondelete them again, to hide the fields specified (or all fields for simplicity), before moving them, with a reason such as "automated conversion from selective delete to revision delete, see (LINK TO REVISIONMOVE ACTION)". 

This will be a common sequence in the early days and is easy and useful to automate.

* A confirmation dialog "this target page does not exist, are you sure you wish to create a new page?" will be sensible.

* An "invert" button to specify all revisions except those checked, and usual shift click + ctrl click options. If those don't exist they are useful enough that they should.

Hi FT2, thanks for your feedback.

(In reply to comment #12)
> At the risk of proliferating an extra table or an extra field, this is a
> one-way lookup, from (log action id) -> (list of revisions) or (log action id)
> -> (html string containing list of revision links).

I thought about storing the information *which* revisions have been moved (instead of just the count) somewhere in the DB, and here's why I don't want to do it:
1. Schema changes suck.
2. RevisionMove is a rarely used feature which means
2.1 a schema change only for that minor feature would be controversial
2.2 it isn't really necessary or worth the effort
3. Users who have permissions to move revisions (I suggest admins by default) usually know what they're doing.
4. The current revision move process (delete, partial undelete, move, undelete) allows you to screw up just as bad
5. Other operations that affect multiple revisions don't store exact information about which revisions were affected as well.

(In reply to comment #13)
> 1/ Moving only undeleted revisions works and can help keep it clean. If deleted
> revisions are involved then the deleted revisions can be undeleted, moved, then
> (if applicable) any deletable content removed using RevisionDelete. I think
> this is what you meant?

Yes.
I was referring to revision which are deleted in the old way (i.e. in the archive table, not in the revision table). I don't want to implement anything for a soon-deprecated deletion schema. RevisionMove won't touch RevisionMove restrictions. There are no special restrictions in moving RevDeleted (even suppressed) revisions.

> 2/ A few "ease of use" suggestions to throw into the mix:
> 
> * An "undo this move" button. RevisionMove needs a one click undo, as RevDelete
> effectively has. People make mistakes and will need to quickly reverse
> "whatever they just did".

A "undo" link on the success page would be possible. However, an undo link in the log (or something like that) would require saving which revision where moved. That is not going to happen anytime soon, see above.

> * A "Preserve deletion status?" option that's available if any revisions are
> deleted. Checking the box means that RevisionMove will undelete these, and
> revisiondelete them again, to hide the fields specified (or all fields for
> simplicity), before moving them, with a reason such as "automated conversion
> from selective delete to revision delete, see (LINK TO REVISIONMOVE ACTION)". 

Why should RevisionMove change deletion status of revisions? RevisionMove just moves revisions from A to B, nothing more.

> * A confirmation dialog "this target page does not exist, are you sure you wish
> to create a new page?" will be sensible.

We assume that the admin knows what he is doing. If he accidentally creates a new page, it's trivial to move all the revisions of the new page to the desired target page.

> * An "invert" button to specify all revisions except those checked, and usual
> shift click + ctrl click options. If those don't exist they are useful enough
> that they should.

That would indeed be useful – not only for RevisionMove, but also for RevisionDelete. Note that it would only affect currently displayed revisions (e.g. not the 50 older revisions ;))

I'm not convinced that "It wasn't covered in the past" and "old extensions don't always do it" are good rationales. Surely the eseence of a wiki is to be able to trace who did what, and to improve as time passes. So even if we had not done it in the past, revDelete does attempt to, and I think RevMove should probably attempt to as well. It's good wiki-practice.

A second thought is, RevMove alone is minor, however it parallels RevDelete which isn't, and which does keep a note of revisions acted upon. So there's probably already space to store the data in the db.

Agree that making RevMove only work for non-deleted pages and revisions (including non-deleted revisions with RevDeleted fields) will help to prevent a number of possible issues that would arise if it tried to be usable on "traditional" deleted revisions.

Agree its easier that the admin corrects a creation error, than top be asked each time "are you sure".

Done in r67094. Still experimental.

Test it with the following line on your local test wiki:
$wgGroupPermissions['sysop']['revisionmove']  = true;

Is this available on any WMF test wiki? To see how it works?

This function messes around with the database, so I think the code should be reviewed before it goes live on a public test wiki.
A review would be nice, though :)

And of course you are free to test it on your own (local) wiki.

Re-opened because this bug is technically not resolved (imo) until it's actually available on WMF wikis (at the very least testwiki so it can be reviewed by laypersons who don't run their own wiki...).

Don't mix code issues with site configuration. This bug was for a feature to be developed. It exists now, so this bug should remain closed. All requests to enable it somewhere should be filed separately.

(In reply to comment #20)
> Don't mix code issues with site configuration. This bug was for a feature to be
> developed. It exists now, so this bug should remain closed. All requests to
> enable it somewhere should be filed separately.

It has not been reviewed for the WMF branch - how does one request that?

(In reply to comment #21)
> (In reply to comment #20)
> > Don't mix code issues with site configuration. This bug was for a feature to be
> > developed. It exists now, so this bug should remain closed. All requests to
> > enable it somewhere should be filed separately.
> 
> It has not been reviewed for the WMF branch - how does one request that?

By doing what Max said above. Open a bug requesting it be enabled on xyz wiki(s), then before it's deployed someone will review it.

The other option is waiting for normal code review + deployment to catch up.

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > Don't mix code issues with site configuration. This bug was for a feature to be
> > > developed. It exists now, so this bug should remain closed. All requests to
> > > enable it somewhere should be filed separately.
> > 
> > It has not been reviewed for the WMF branch - how does one request that?
> 
> By doing what Max said above. Open a bug requesting it be enabled on xyz
> wiki(s), then before it's deployed someone will review it.
> 
> The other option is waiting for normal code review + deployment to catch up.

Kind of like we did with https://bugzilla.wikimedia.org/show_bug.cgi?id=24157 ?

This was backed out of trunk in r86155.

Comment 20 states "This bug was for a feature to be developed. It exists now, so this bug should remain closed."

But r86155 states it was backed out "until somebody has the time to work on it again".

Are there issues? What has to be done to get any issues related to its backing out resolved, and the code enabled on a test wiki so it can be this reviewed (per r86155 comment) re-added and enabled on a test basis for people to play with?

See https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment for information on what is needed to get an extension reviewed before potentially deploying it on a wikisite.

unassigning this from myself, I currently don't have time to work on MediaWiki.

In what does this differ from mergehistory?
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56356

(In reply to comment #26)
> See https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment for
> information on what is needed to get an extension reviewed before potentially
> deploying it on a wikisite.

-> moving to extension requests.

(In reply to comment #28)
> In what does this differ from mergehistory?
> http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56356
> 
This extension would make it possible to separate edits with exactly the same timestamp (see bug 37465) and it would also make it much easier to remove one or two edits in a page containing several thousand revisions like this: http://en.wikipedia.org/wiki/User_talk:Graham87/Archive_18#Unusual_history_merge

Can Mergehistory do that?

Can this be normal priority rather than low? History merges are a regular maintenance task, and it would be really great to be able to do it simply.

Incidentally, I recently had to undo a mistaken history merge, and it was a ridiculously complicated experience - see https://en.wikipedia.org/wiki/User:Scott/How_not_to_manage_article_history for the gory details - which would have benefited greatly from a RevisionMove tool.

(In reply to Scott Martin from comment #30)
> Can this be normal priority rather than low?

It won't change much as long as nobody works on a patch...

(In reply to Nemo from comment #28)
> In what does this differ from mergehistory?
> http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56356

Scott, we're still waiting for an answer to this question. If you want to see this bug move, the best you can do is to find or set up a test wiki (e.g. [[mw:MWV]]), enable mergehistory there, see what's missing from it, file bugs/enhancement requests.

That's a very reasonable request, Nemo, and I'll see if I can have a stab at it. Strikes me as a useful opportunity for a learning experience as well.