Allow for tagging multiple history merges #117

Open
atlight opened this Issue Jun 17, 2012 · 0 comments

Projects

None yet

1 participant

@atlight
Collaborator
atlight commented Jun 17, 2012

From WT:TW:

I found an article which was multiple times splitted and copy and pasted to another place. Why am I not allowed to tag the article with multiple history merges requests? mabdul 14:26, 3 May 2012 (UTC)

Twinkle doesn't have very good history merge functionality at the moment. For some reason, history merge tagging is done using the CSD (speedy deletion) module, which doesn't make a lot of sense. I don't have much experience with history merges; how would you like Twinkle's functionality in this area to work? — This, that, and the other (talk) 09:38, 7 May 2012 (UTC)

Tagging for non administrators is not bad actually. The problem with history merges is, that "easy merges" (clear copy and paste moves) are correctly tagged, but prevent the "tagger" to tag a page with multiple history merges. (which happens really seldom, but a few days ago I found an article which was moved two times by a user by copy and paste.)
I would like to see (at least) a possibility to place multiple {{db-historymerge}} on a page.
For more complex merges, I normally ask User:Anthony Appleyard at Wikipedia:Cut and paste move repair holding pen‎. Maybe ping him if more complex task should get added by TW at this page. (I have no opinion on that) mabdul 09:51, 7 May 2012 (UTC)

@mc10 mc10 referenced this issue Oct 14, 2013
@atlight atlight speedy: convert to use subgroups, other misc. changes
In hindsight, this should have been done in several "atomic" commits, but
so much for that idea!

Changes include:
- removing calls to prompt() when CSD-tagging an article and replacing them
  with subgroups, similarly to the tag module in 7acac36
  (based on feedback on WT:TW and inspired by Siddhartha Ghai's work)
- overhauling the means by which the list of criteria is prepared. This
  makes it more flexible, to suit the variety of "modes" in which it can
  exist (e.g. checkboxes/radio buttons), and also future-proofs it against
  future changes
- changing the getParameters function to validate the subgroup inputs
  instead of displaying prompt dialogs
- various updates to the logic of the parameter inputs (e.g. several that
  were optional are now mandatory, to match the behavior of the associated
  db- template)
- removal of speedyPromptOnG7 pref - now unnecessary
- simplification of G13 API query added in 34fa873

It has been tested in various scenarios. Fingers crossed that it works in
*every* scenario!
a04f034
@atlight atlight added the Module: tag label Jun 1, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment