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?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 17 2022
Apr 11 2022
Apr 10 2022
Apr 3 2022
Mar 27 2022
Mar 26 2022
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.
Mar 19 2022
Jan 18 2022
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.
Jan 17 2022
Jan 16 2022
Oh, nice. Thanks! :)
Jan 3 2022
Oct 14 2021
Sep 6 2021
May 31 2021
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.
May 30 2021
Triaging as medium for now; feel free to escalate, if desired.
May 26 2021
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.
May 25 2021
Apr 28 2021
Apr 27 2021
Apr 14 2021
In T276688#7000606, @Universal_Omega wrote:@R4356th: is this really invalid? It was an actual issue that was self-solved not really invalid.
Apr 13 2021
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.
Apr 7 2021
Regarding https://phabricator.wikimedia.org/T268558#6981540, https://phabricator.wikimedia.org/T268558#6671206 already cross-references the task
Apr 6 2021
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?
Apr 3 2021
Mar 22 2021
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.
Mar 5 2021
Feb 22 2021
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 blockedIf 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
Feb 16 2021
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?
Jan 31 2021
Jan 12 2021
Jan 11 2021
Dec 30 2020
Dec 22 2020
Adding User-RhinosF1 project
Nov 19 2020
👍 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?
Nov 13 2020
Adding @Universal_Omega per his request on IRC
Nov 10 2020
@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.
Aug 29 2020
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.
Aug 15 2020
Jul 30 2020
@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?
Jun 27 2020
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.
Jun 23 2020
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.