To be clear, this won't propose to restrict stewards from adding or removing wikis from WikiSets, but rather just retain the current opted in or opted out wikis from the respective WikiSet, correct?

In T267663#7808516, @Xaosflux wrote:

With T268558 being solved - do we really need this done? Isn't this request now along the lines of: "If a user inputs garbage, garbage is output"?

In T267663#7738492, @Xaosflux wrote:

OK, that's what I requested in T302257 - fixing the problem in general; the user story on this one seems to be asking for the extension to insert matching closing tags.

In T299317#7625449, @Aklapper wrote:

@dmehus: Thanks for reporting this. For future reference, please use the feature request form (linked from the top of the task creation page) to create feature requests. Thanks.

Oh, nice. Thanks! :)

In T284010#7124408, @ashley wrote:

To state some of the obvious points:

• Account creation is restricted so I'm not able to create a dummy user account to try to reproduce the bug, but...

We disabled that because the spambots were quite active on test3wiki. Nevertheless, I've reenabled it now.

Triaging as medium for now; feel free to escalate, if desired.

In T283616#7114273, @Niharika wrote:

Yep, this is a duplicate. @RhinosF1 thanks for filing this. Our team has recently been involved in SecurePoll work which is taking up much of our time. We'll pick this work back up soon.

In T276688#7000606, @Universal_Omega wrote:

@R4356th: is this really invalid? It was an actual issue that was self-solved not really invalid.

In T279838#6995680, @Dzahn wrote:

This would mean I have to somehow remove Gyaanipedias from the Miraheze table or the totals would be wrong. I am a bit reluctant to do that because it seems we might soon have more special cases to be removed from the miraheze table.. that need to be maintained somewhere.

@Dzahn Gyaanipedia is not a separate wiki farm, despite the name and number of Gyaanipedias. It is actually a series of Gyannipedia wikis hosted by Miraheze; therefore, Gyannipedia wikis are already included here

Regarding https://phabricator.wikimedia.org/T268558#6981540, https://phabricator.wikimedia.org/T268558#6671206 already cross-references the task

While kind of messy, and not sure if it's related to the other two downstream tasks, there does seem to be a workaround for https://phabricator.miraheze.org/T7099 / https://phabricator.miraheze.org/T7099 whereby when the writeapi is added to the * group, the issue is resolved. If not able to easily resolve, it might be nice to have StructuredDiscussions return a user friendly error message like, "Please add the writeapi user right to the all users (*) user group," or something maybe?

In T259265#6914394, @Aklapper wrote:

@Reception123: Following https://www.mediawiki.org/wiki/How_to_report_a_bug to provide a list of clear steps to reproduce (step by step, as a list), then what you expect, and what happens instead, would increase chances that someone would take a look into this. Please structure your bug reports - thanks.

In T19929#228729, @bzimport wrote:

quentinv57 wrote:

I've put the priority to normal, as suggested above. We're now waiting for three years.

It would be very nice if this could be processed, even if I agree that it would be time-consuming for developers. But the time you will spend doing this is insignificant regarding the time stewards have lost due to this for now. As Marco Aurelio said above, this will be an amazing gain of time.

Now, when stewards want to globally block a crosswiki vandal, they have to perform the following operations :
1- lock the account
2- give themselves the CheckUser status locally
3- check the user IP
4- block the IP globally
5- remove themselves the CheckUser status
6- lock and delete the stuff the vandal has spread between the time the account has been locked and the IP globally blocked

If we had an auto-block that works, we would no more have to perform the last five points. The gain of time is at least 80%.

Moreover, some vandals know we can't perform checks on projets with local CheckUsers. Indeed, the steward policy forbids us to do this. So sometimes they play with us creating multiple accounts to vandalize, and move from a wiki with local CUs to an other. And we have to wait sometimes for dozens of minutes that a local CheckUser is available to perform the check and to globally block the IP.

I hope I was convincing enough. Thanks for your understanding.

Quentinv57

Adding User-RhinosF1 project and moving on that workboard to Miraheze Linked, as we're quite curious when this bug will be fixed. All local log entries have the performers and targets updated following a global rename, so why not global log entries, such as the global rights log?

Thanks, @RhinosF1 and @Paladox for following up on this error. Thanks, @Reedy, for your troubleshooting. So what was the outcome of this, did we have to update our schema, @Paladox?

Adding User-RhinosF1 project

👍 This would definitely be a useful feature, particularly for monitoring users that have requested multiple renames. I'm not sure how often this occurs on the Wikimedia projects, but it certainly does happen fairly often on non-Wikimedia projects. Should we re-add this idea to the community wish list for 2021?

Adding @Universal_Omega per his request on IRC

@RhinosF1 mentioned that I should be able to manually add the four tildes (~~~~) as my signature, which I hadn't initially considered. It's less ideal, as I do feel this shouldn't be too difficult to resolve this bug by having the extension check for an unclosed <small> tag and close any <small> tags present in the reply, but is still an acceptable workaround; however, upon further testing, the four tildes (~~~~) is simply added to the auto-added signature that the extension adds. So, as a secondary or in addition to fix, the extension should check for any four tildes already in the reply and, if present, not add a signature.

Completely agree with @Reception123. I'd actually like to see Special:ActiveUsers improved to be a full-fledged special page, capable of being linked to via Special:ActiveUsers/role and/or transcluded into wiki pages.

@Aklapper There's a clear use case here. Respectfully, MediaWiki does not revolve around Wikimedia (and the inverse is also true, too). There are many other organizations and wiki farms, including Miraheze, that use MediaWiki. I am one of those users who feels this is useful. If two or more users feel it would be useful, there's a use case, in my opinion. Moreover, this doesn't strike me as particularly problematic to implement; thus, the threshold for the use case is comparably lower than something that is complex or would require a significant rewrite.

@Reception123 Can you fix the typo in my username in your original post?

Okay, it looks like when I was updating my global preferences from within English Wikipedia, I was enabling some preferences that can be set globally and must've accidentally enabled that English Wikipedia-only "Temporarily disable the visual editor while it is in beta" option (when I meant to untick the second box). In my troubleshooting, I set a local exception by unticking that second box, and it wouldn't let me untick it (since it had been set globally, I guess). When I went back in to Special:GlobalPreferences, I was able to unselect that option, then unselect the local exception in Special:Preferences. It's not very clear, so perhaps the wording of the first and second checkboxes next to each preference item could be clearer in a future release. Nevertheless, doing that restored my ability to use the new wikitext editor.

I further removed the CharInsert gadget and, just to clarify or reiterate, have disabled Reference Previews globally and locally. I have Navigation Popups enabled, but also disabled the ReferenceTooltips gadget.

Thanks for the quick reply and update, @Reedy. I appreciate that the "or by namespace" isn't possible due to the way in which the short URLs are stored in the database. That idea isn't really necessary anyway.

I came here to open a task to create this feature request, but saw it already exists. Can we retriage this request to medium priority? Creating a special page to list all short URLs on a wiki or by namespace would be very helpful for managing unnecessarily created short URLs.