Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tag: Fix regression leaving generic {{merge}} instead of {{merge to}} or {{merge from}} #714

Merged
merged 1 commit into from
Sep 30, 2019

Conversation

Amorymeltzer
Copy link
Collaborator

@Amorymeltzer Amorymeltzer commented Sep 29, 2019

As reported at WT:TW, Twinkle has been leaving {{merge}} on the other page when tagging with {{merge to}} or {{merge from}} (rather than {{merge from}} or {{merge to}}, respectively).

Stems from #485, where somewhere along the way the addition in L1274 at 95eac79 was removed but params.mergeTag remained.

I've added the line back when validating the various merge tags, since we're already evaluating them all.

*cries in .includes()*

@siddharthvp
Copy link
Member

Sorry for committing the bug. A better way to fix it is by simply adding

params.mergeTag = tagName;

after L1527. That is where the other merge-related params items such as params.discussArticle and params.talkDiscussionTitle are being set up.

… or {{merge from}}

As reported at [WT:TW](https://en.wikipedia.org/w/index.php?oldid=918480329#Merge_tags), Twinkle has been leaving `{{merge}}` on the other page when tagging with `{{merge to}}` or `{{merge from}}` (rather than `{{merge from}}` or `{{merge to}}`, respectively).

Stems from wikimedia-gadgets#485, where somewhere along the way the addition in [L1274](wikimedia-gadgets@95eac79#diff-03744d176dfd1e8a2178545886a87644R1606) at 95eac79 was removed but `params.mergeTag` remained.
@Amorymeltzer
Copy link
Collaborator Author

Thanks — not sure how I missed that section?

@Amorymeltzer Amorymeltzer merged commit 76fed61 into wikimedia-gadgets:master Sep 30, 2019
Amorymeltzer added a commit to Amorymeltzer/twinkle that referenced this pull request Feb 21, 2020
In doing wikimedia-gadgets#862, I undid the intent of wikimedia-gadgets#714 to avoid the client clock as much as possible for the specific case of soft redirects being nominated at RfD.  It never worked - thus wikimedia-gadgets#861 - but the idea is sound.  This has softredirects go through the same `curtimestamp` query and "typical" redirects, but simply skips processing of target or section.  It's not a free check anymore, but it should be incredibly infrequent and fairly quick.
Amorymeltzer added a commit to Amorymeltzer/twinkle that referenced this pull request Mar 2, 2020
In doing wikimedia-gadgets#862, I undid the intent of wikimedia-gadgets#714 to avoid the client clock as much as possible for the specific case of soft redirects being nominated at RfD.  It never worked - thus wikimedia-gadgets#861 - but the idea is sound.  This has softredirects go through the same `curtimestamp` query and "typical" redirects, but simply skips processing of target or section.  It's not an entirely free check anymore, but it should be incredibly infrequent and fairly quick.
wiki-ST47 pushed a commit to wiki-ST47/twinkle that referenced this pull request Sep 2, 2020
In doing wikimedia-gadgets#862, I undid the intent of wikimedia-gadgets#714 to avoid the client clock as much as possible for the specific case of soft redirects being nominated at RfD.  It never worked - thus wikimedia-gadgets#861 - but the idea is sound.  This has softredirects go through the same `curtimestamp` query and "typical" redirects, but simply skips processing of target or section.  It's not an entirely free check anymore, but it should be incredibly infrequent and fairly quick.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants