Resolved now on extension level, should also be resolved on Wikimedia upon next message update.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 9 2022
Aug 6 2022
In T270854#7074330, @Amire80 wrote:Maybe: The latest {{PLURAL:$1|version of this page|version of each of these pages}} has been marked for translation. ?
Jan 29 2022
In T260140#6393512, @thiemowmde wrote:Just keep Project:Licensing as it is.
May 1 2020
In T92795#6079008, @Xaosflux wrote:So this is still stalled on idealistic concerns? @Vogone "I believe this restriction is harmful. It forbids users requesting a mass message delivery for their project to take advantage of this formatting option." ? My suggestion was that people that can send mass messages should be allowed to create mass message lists, and that is an improvement over the current state. How is making it incrementally better worse off then just blocking action? Additionally, any project could just add the editcontentmodel right to the 'users' group if they really wanted anyone to be able to just edit any content model. I'm even open to making a permission for Special:CreateMassMessageList, and a project could give it to mass-message-senders, or even 'users' if they really wanted to.
Dec 21 2019
@Urbanecm Yes, it is. I have also quickly added dewiki and ruwiki as import sources after an administrator has shown me templates which are to be imported. Thanks for pointing out the WIP status!
Dec 20 2019
Sep 14 2019
The described issue still persists, even with the same example as provided in the task description.
Aug 28 2019
Aug 15 2019
In T92795#5352317, @DannyS712 wrote:The gerrit patch was objected to by @Vogone, who hasn't responded yet to Xaosflux's question above
Jul 18 2019
In T202625#5344657, @Legoktm wrote:Per bawolff, this isn't really suitable for a user preference, sorry. Plus with UrlShortener, it would defeat the point of the whitelist since people could just shorten https://en.wikipedia.org/wiki/google:foo
Jun 9 2019
In T92795#5245358, @DannyS712 wrote:only users with the "editcontentmodel" right can create new mass message lists
Jan 6 2019
I a
Nov 30 2018
Thanks a lot for investigating the issue!
Nov 16 2018
In T203335#4753662, @gerritbot wrote:Change 474181 had a related patch set uploaded (by Greta WMDE; owner: Greta Doçi):
[mediawiki/extensions/WikibaseLexeme@master] I changed the lowercase into uppercase of Lexeme/Form/Sense/Item
Oct 26 2018
Sorry, I had not seen this task, only the fact that "item" was mostly lower case and the WikibaseLexeme entity types mostly upper case. I decided to make them all lower case because that reflects natural language, and obviously a decision for upper case pseudo-proper names would get lost in translation, anyway.
Oct 14 2018
Oct 7 2018
Sep 27 2018
Sep 24 2018
Sep 19 2018
Aug 31 2018
Aug 23 2018
In T202597#4527510, @Xaosflux wrote:@Vogone, this could be re titled - unless you want to build a community consensus on metawiki for changing their group only - I think in the discussion so far we've identified that this is really a "global" problem that could be fixed a few ways.
In T202625#4527067, @Bawolff wrote:Yes its anti-phising. e.g. Someone giving a link to https://en.wikipedia.org/wiki/somewhereevil:Foo making it look like a wikipedia link in an email ( https://cwe.mitre.org/data/definitions/601.html )
In T202625#4527067, @Bawolff wrote:In T202625#4527047, @Vogone wrote:Are you sure there is a real security concern for users who explicitly disable the splash page only for themselves? For example, normal external links don't need to a splash page either. The main reason for this being introduced seem to be "phishing" concerns which mostly affect users who are not familiar with the interwiki system, I would assume.
Yes its anti-phising. e.g. Someone giving a link to https://en.wikipedia.org/wiki/somewhereevil:Foo making it look like a wikipedia link in an email ( https://cwe.mitre.org/data/definitions/601.html )
This is not a high severity issue by any means - if it was really annoying I'd be open to having a preference (Although in principle I dislike preferences for security features. Its often users who don't think it can happen to them who are the one's who end up being tricked. I also think this is a very specialized usecase to make a preference for). Maybe we could use a user-script for this?
Are you sure there is a real security concern for users who explicitly disable the splash page only for themselves? For example, normal external links don't need to a splash page either. The main reason for this being introduced seem to be "phishing" concerns which mostly affect users who are not familiar with the interwiki system, I would assume.
In T202597#4526274, @MarcoAurelio wrote:@Vogone If you're using the new UI (PolyGerrit) you can't edit patches. Switch to the old UI (there should be a link at the footer of the page) then go to the patch and you'll see an Edit button on the patch that'll let you edit, add, rename and remove files. Then Done editting and Publish edit (at the top} and you're all set. When you think the patch is ready for review hit Start Review so it appears on people's review dashboards. Let me know if I can help. Regards.
In T202597#4525853, @gerritbot wrote:Change 454762 had a related patch set uploaded (by Vogone; owner: Vogone):
[operations/mediawiki-config@master] This change adds the permission 'editcontentmodel' to the 'massmessage-senders' user group on metawiki. The change will allow 'massmessage-senders' on metawiki to use Special:CreateMassMessageList.
Started community discussion at https://meta.wikimedia.org/wiki/Meta:Babel#'editcontentmodel'_permission_for_'massmessage-senders'.
In T202597#4525596, @Xaosflux wrote:This is not an "error" it is by design. Simply being able to use the massmessage extension doesn't require changing content models.
Aug 21 2018
May 29 2018
As to why I called it a "hack": I created this redirect by importing the redirect from metawiki which is obviously a rather unusual way of creating pages in the wikidatawiki ns0.
If I remember correctly, I was asked by Lydia to delete this because the WMDE developers had some technical concerns due to ns0 being the item namespace. But since this is almost 5 years ago by now, my memory could be wrong.
May 12 2018
Sorry, I meant <listname>-join@… as per http://www.list.org/mailman-member/node13.html.
Although the idea sounds nice I believe it would not prevent all bot-generated subscription requests since sending a <listname>-request@lists.wikimedia.org mail as well causes a subscription request.
Jun 13 2017
In fact, this is exactly the "side-effect" described in LFaraone's initial commit. This means we need a solution which works for both, users with only 'deleterevision' and those with only 'deletedhistory'.
In T128914#3342706, @Legoktm wrote:In T128914#3337294, @Vogone wrote:This change broke the accessibility of Special:RevisionDelete to ombudsmen which causes quite some trouble. I would suggest to revert this change and look for another way to solve this bug.
I've read this discussion again, and maybe I'm missing it, but could you clarify what accessibility was broken? AIUI you have deletedhistory & deletedtext rights. What functionality do you expect to have that is currently missing?
Jun 10 2017
I'm sorry if this may sound a little impolite, but is it really so hard to check Special:GlobalGroupPermissions (https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions)? FWIW, I am an ombudsman myself and should probably know which technical access I have.
In T128914#3337515, @Huji wrote:In T128914#3337491, @Vogone wrote:In T128914#3337478, @Huji wrote:In T128914#3337294, @Vogone wrote:In T128914#2091895, @gerritbot wrote:Change 275268 had a related patch set uploaded (by LFaraone):
Allow users with deleterevision but not deletedhistory to delete revisionsThis change broke the accessibility of Special:RevisionDelete to ombudsmen which causes quite some trouble. I would suggest to revert this change and look for another way to solve this bug.
Why not give the Ombudsmen the appropriate rights? Just like how they have CheckUser access. If we can trust them with having CheckUser and Oversight access on every project, we can certainly trust them to have deletedhistory and deletedtext rights or even sysop rights everywhere.
In other words, you are trying to revert something that works correctly for many, just because there is a select few for whom it does not work, when there is an easy way to fix the permissions of those few.
I think you are misunderstanding the issue. Ombudsmen do have these passive rights, we would need to add 'deleterevision' in order to "fix" it which would allow ombudsmen to actively hide revisions which is certainly not intended.
I think you are misunderstanding my point. The Ombudsmen currently have rights such as CheckUser and Oversight, using which they could "actively run checks" or "actively suppress revisions". They do not use it for those purposes though, because they know they are not supposed to.
Similarly, it is fine to give them "deleterevision" with the understanding that they are not to use it to actively delete a revision.
In T128914#3337478, @Huji wrote:In T128914#3337294, @Vogone wrote:In T128914#2091895, @gerritbot wrote:Change 275268 had a related patch set uploaded (by LFaraone):
Allow users with deleterevision but not deletedhistory to delete revisionsThis change broke the accessibility of Special:RevisionDelete to ombudsmen which causes quite some trouble. I would suggest to revert this change and look for another way to solve this bug.
Why not give the Ombudsmen the appropriate rights? Just like how they have CheckUser access. If we can trust them with having CheckUser and Oversight access on every project, we can certainly trust them to have deletedhistory and deletedtext rights or even sysop rights everywhere.
In other words, you are trying to revert something that works correctly for many, just because there is a select few for whom it does not work, when there is an easy way to fix the permissions of those few.
In T128914#2091895, @gerritbot wrote:Change 275268 had a related patch set uploaded (by LFaraone):
Allow users with deleterevision but not deletedhistory to delete revisions
Feb 9 2017
Jan 24 2017
Steps: 1) Go to wikitext editor, 2) put --~~~~ in, 3) click preview, 4) wait a minute, 5) save the edit.
Result: Timestamp shows the time when the edit has been previewed instead of the time when the edit has been saved.
Jan 23 2017
Jan 15 2017
Dec 24 2016
Please revert, community discussion has been closed as "no consensus" by a bureaucrat.
Dec 16 2016
In T153397#2880221, @Krenair wrote:Obviously? If I go to the simple form, type some text, then "Configure Form" and "View Form Configurations", then press the back button to return to the form, I get my text back.
Just a technical task, I suppose. But it still requires some time to complete, because there is still an issue with Wikidata as outlined in a comment above:
In T27522#2655109, @Zordsdavini wrote:Redirect sgs → bat-smg is not needed, because bat-smg was temporary decision until we got normal ISO code
Dec 6 2016
Why should we do this?
Dec 3 2016
+1, 'importupload' is not a right which should be assigned automatically to any administrator, since it requires a fair amount of technical skills besides community trust. Entire page histories can be messed up (no matter if intentionally or by accident); I would strongly discourage from implementing this and would indeed suggest considering to follow the suggestion above and add transwiki import sources instead.
Nov 26 2016
Sep 21 2016
In T27522#2649432, @Amire80 wrote:be-tarask was indeed moved, but it uncovered a Wikidata issue, which must be resolved before further changes: T112426.
Sep 19 2016
Any progress here? It's been 6 years now and there are examples (be-x-old moved, jpwiki redirected) which show that this here is a resolvable task.
Jun 29 2016
In T138919#2413993, @Glaisher wrote:You can use https://meta.wikimedia.org/wiki/MediaWiki:Globalrenameuser-text. It is not enabled by default.
May 11 2016
@Dereckson I suppose the Wednesday "Morning SWAT" (today 15-16 UTC) will be just fine for this, Though, this obviously requires someone to create the patch before. Are you willing to do so? I will certainly not be available anymore before that time.
Mar 4 2016
I can confirm this happens on multiple pages.
Feb 25 2016
Also happens on other wikis.
In T64717#2063405, @Dzahn wrote:In T64717#2062666, @Candalua wrote:In T64717#2062328, @Dzahn wrote:I don't see why this is "Traffic". but it's declined anyways
Why is it declined?
See the comment above mine by Luke081515
"Declined per T124354. There is no consensus for this change yet. Please reopen the task if consensus reached."
Feb 2 2016
This doesn't make any sense. Why do we need duplicate requests? And why would we want to wait until there is "no consensus"?
Jan 9 2016
I have a question concerning the user preferences. If I choose to use the old wikitext editor as my personal default editor, do I need to switch from VE to WT manually and individually on every wiki and every device I use or will there be an easy way to make this decision with global effect? This is quite important to me, because as a globally active user I edit several hundred different wikis and my slow internet connection does not appreciate VisualEditor at all.
Dec 11 2015
In T121168#1873247, @Hydriz wrote:Two questions:
- Why do you need to modify global groups? If there is a need, a task in Phabricator is preferred so discussion can take place.
- Testing? Do you really need steward rights for doing "tests" that global sysop isn't sufficient?
Judging from your comments, I am inclined towards just allowing global sysops to modify global abusefilter rules on beta to fit your use case.
In T121168#1872602, @Luke081515 wrote:I discovered some of the bugs by the way, so unwanted, like the both bugs concerning mediawiki currently triaged as low. For the bug triaged as high you need just the right to view, so nobody can replicate this, if he just can see my logs/actions. The bug at normal priority concerning logging is just visible for people with more rights, so you can't discover the bugs I reported, if you only see my logs, so it's not discernable in this situation. But there are other issues, I found at beta, reproducilbe for production too, and I can't find them at the future without the possibility to simulate some situations there, so in this point the consequence could be, that we have more bugs, which are unknown, because no one discovered them.
Dec 10 2015
In T20954#1869876, @Luke081515 wrote:
Nov 8 2015
Please don't, talk pages have to be editable by anyone, not just by people who are into flow.
Jun 26 2015
Apr 23 2015
In T96899#1230121, @Glaisher wrote:For user rights, @* already works. It might be useful to show it even if Special:Log/rights is not specifically selected though (i.e. Special:Log (all public logs))
Apr 22 2015
Apr 9 2015
Apr 8 2015
In T95408#1189527, @Legoktm wrote:I suppose we need a javascript confirm button on the rename queue like Special:GlobalRenameUser has?