As a solution for this case, it's possible to move the page, by its id, to a different name using an api. But we need to make sure this doesn't happen again.

Can we mark this as resolved? I can confirm that it works as expected on hewiki.

Can we mark this as resolved? I can confirm that it works as expected on hewiki.

Can we mark this as resolved?

This just happened again on a checkuser patch set - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1352449

This works for ⇧ + mouse-click. I think this can be marked as resolved.

Can we mark this as resolved?

In T440303#12400457, @neriah wrote:

We could fix this the same way I fixed NewUserMessage (T440028#12393842), but that way the block wouldn't be immediate, which could be problematic. What do you think?

We could fix this the same way I fixed NewUserMessage (T440028#12393842), but that way the block wouldn't be immediate, which could be problematic. What do you think?

Maybe T433224#12393862 caused this?

Well, I don't know. either way, I agree that it's worth discussing with the community.

In T423355#12391858, @stjn wrote:

Then it’s better to invest time and effort in improving/adding more ways to leave those personal messages to the user talk page etc. (like WikiLove) instead of hijacking an existing feature for a quick message of acknowledgement.

There's something about the thanks not being prominent on the talk page that makes it feel more "lightweight," and that way users thank each other more. In my opinion, that's something worth preserving.
For wikis that until now required a confirmation step (WMF, for example), adding an optional step for a reason won't make the workflow harder, instead of an extra click to confirm, a dialog will pop up offering them to write a reason, or just send the thanks without one. For sites where there was no such confirmation step, it would indeed be more cumbersome, but we can add a configuration setting and let each wiki installation decide for itself what it wants.

@Ciencia_Al_Poder No, when I'm viewing vandalism diffs and I see that a patroller reverted another edit by the same vandal, sometimes I want to thank them for that. If I could do it directly without having to go to the previous edit first, it would be much better. Don't forget that we want to encourage sending thanks to others, since it greatly boosts editors' motivation.

In many cases you can tell what an edit contains from the summary, and that's what it's meant for. I see this with vandalism reverts, which is why I liked the idea. Either way, you're right that it's not too harmful :)

@dcausse, thanks for the fix!
Just one small problem, which I'm mentioning here because it seems related (it only happens for a special namespace): Search results for special pages appear twice, which is quite annoying. I checked other wikis where DWIM isn't enabled (enwiki), and the problem exists there too.

Oh, that's cute. Because the edit happens in the same web request as account creation/the user's first wiki action, the tags from that action are also applied to the extension's edit. I assume what we need to do is run the action as a separate job.

In T439805#12383454, @HideonRosie wrote:

For any system administrators, I have a question: Why does the renaming process often become slow or get stuck at wikidatawiki?

I've also been encountering this slowness lately, maybe it's worth seeing what causes it. @Ammapad

yep, this is the main use case. The goal is to prevent the user from creating new pages in certain namespaces, without preventing them from editing existing pages. In the case of the article namespace, this way we could direct the user to work in the user namespace on new pages, but edit regular pages as usual.
Regarding creating a new redirect, as a sysop I believe this should be prevented too - the purpose of the block is to prevent the user from creating new pages in the namespace across the board (on hewiki, I think this will mainly be used for mandatory mentorship), and in such a case I would want to block creating redirects as well.

Resolved, tests added

T395817#12327034, ping @Tgr.

@Dreamy_Jazz, I assume this can be marked as resolved?

It's deployed.

I assume this can be marked as resolved? Also, @Tgr, I didn't understand what kind of user notice is required here.

In T437978#12321040, @Dreamy_Jazz wrote:

To me the chip number indicates how far you are away from the default view, and so if you no longer see cases this is a hint there may be more if you reduce that number

What the view is with no chip icon number could be unclear, but I'd suggest that this is always the filter settings that provides the widest possible view where all are cases shown. So to me the sockpuppet queue still shows "6" in the chip text

I believe the filter count should only count filters that have been changed, and therefore shouldn't count the default as a filter. but that's your decision to make..

@STran Shouldn't the default be "Not required"? Right now it seems contradictory- on one hand, the default is edits, but on the other hand it shows a "1" on the filters button, as if I had set a personal filter...

I think this task is a bit messy.

• as a feature request, this already exists.
• as a proposal to change the default for wmf, I assume this should go through an RfC on meta
• as a request for an experiment, it should be a separate task

Maybe it would be better to close this task as Invalid and proceed in a more organized way. :)

Technically, it would be easy to do this, but I'm having trouble understanding the need for it. Do you know of a wiki that would need this? If not, adding this magic word is unnecessary.

In T374053#10635119, @ANakanishi_WMF wrote:

We're working with @kostajh and @SimoneThisDot to modify the rejection flow such that notifications are no longer sent to Legal, but rejected requests and reason for rejection is documented such that we're able to look this up when needed (eg, in the rare case that we receive a related legal inquiry). This would mean making the reason for rejection field required as opposed to optional (current setting). We're asking for this change on the assumption that it wouldn't be an overly burdensome change for Renamers, please do let us know if that's wrong and we should take pause and reconsider. We're keen to balance potential legal risks and volunteer needs.

we could, though I'm not sure how much value it adds. In places where it's already valid, I don't see much reason for it to break again :)

https://meta.wikimedia.org/w/index.php?diff=30922362

In T413395#11539550, @matmarex wrote:

You actually make a good point that the email subject shouldn't have a trailing full stop. None of the other notification emails I see in my inbox have it, only the "X thanked you" ones.

per https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalPreferences/+/1309683/comments/2b8c7cbc_d9995ff8