https://bugzilla.wikimedia.org/show_bug.cgi?id=21312
--- Comment #14 from Church of emacs <church.of.emacs...@gmail.com> 2010-05-13 17:25:56 UTC --- 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 ;)) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
