@dancy: should parent task be added?

Is this worth getting permission to deploy today for?

Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team

Has anyone left them a message?

While I fully understand your wish, If as @Nemo_bis, claims we follow an externally set standard then it might be the case that our hands are tied and we need to review how whoever made the call came to that decision and have it reviewed but that could be a long while or come up with an answer for you.

In T255938#6344207, @Nemo_bis wrote:

Fallback languages are not decided by Wikipedia consensus. The Italian fallback for vec must stay.

Caused by @bd808 (intentionally) in T248130

Was gonna do a patch but I'll review what exists

In T264505#6514867, @Krinkle wrote:

Could you paste the contents of your LocalSettings.php file (taking care to leave out any database passwords, upgrade keys, or other sensitive strings). I suspect this might have to do with some cache or localisation configuration indeed.

Also, do you have any other MediaWiki:-namespace override pages on your wiki? Check Special:PrefixIndex?prefix=&namespace=8 to find out about this.

I just noticed the IR on wikitech says:

duplicate key for ip banning

Please don't randomly change task priorities without a reason. Your account may be disabled if you do so again.

@Urbanecm; Is there not the exemptFromUserRobotsControl flag?

Thanks for splitting this off @matmarex. Completely agree that a more useful error would have been helpful here although not sure how common this sort of race condition is.

I'm assuming job queue only does that after specific time like a cronjob

It's ran by calling runJobs.php constantly on loop. On a small wiki it should be fairly quick.

Work on this probably shouldn't start until the TechCom-RFC at T202673 is complete

In T194697#6496818, @Toni_Mueller wrote:

Hi, is there any progress on this? This task is now open for over two years, but nothing happened so far. It can't take years to program that several blocking parameters are possible at the same time.

Were you by any chance editing when the page was deleted?

Not sure this qualifies as UBN. It's a few isolated cases as far as I can tell.

Thanks for the quick reply @jcrespo

After discussing proposed fix of table inconsistency with enwikivoyage admins

Was this public anywhere for the sake of transparency? Could a log / page be linked to?

Is this resolved?

A 7 year old task isn't UBN

Is there a reason behind this being abandoned for the record?

I don't know how to solve this problem.

You already have @Bawolff, @Urbanecm, @Marostegui that have worked together to try and get it back on for you and propose long term fixes.

But Katherine told me that the Foundation's management monitors this task. We have draw their attention to this.

I'm sure they can discuss it as a board but that's not going to magic up developer time and a fix. People have looked into it and @Bawolff has proposed patches to try and fix it.

In T262391#6473696, @Krassotkin wrote:

@RhinosF1 And why can't we identify and transfer critical code to WMF staff support?

They have hundreds of other components to work on. I have no idea how maintained DPL has been up to now but it may have never needed any additional work until now that wasn't being done.

In T262391#6473688, @Krassotkin wrote:

@Aklapper Sorry, but I didn't get it. Doesn't the Foundation have its own developers?

Not all deployed code is maintained by WMF staff. A lot of work is done by volunteers.

Blocker ---> UBN!

Train blocker --> UBN!

Congrats Martin!

It looks like this will need to be done anyway because Russian Wikinews is in the TOP 100 Wikimedia projects now and we plan to triple the number of articles in the very near future.
Who decides on this issue? What do we need to do?

I'm also seeing intermittent cirrussearch-too-busy-error when searching (on all wikis).

They were a couple reports on the Wikimedia Discord about this affecting searches in the main namespace.

Closing as such then

Is this not a duplicate of the parent task?

Down for me now

https://sal.toolforge.org/log/qqieeHQBLkHzneNN6q_k ?

@Bugreporter, @Pintoch: Have you tried following https://wikitech.wikimedia.org/wiki/Reporting_a_connectivity_issue

None of the 3 mentioned here show a 502 for me

@hashar: Should this be UBN with it blocking the train?

Could you link to a discussion on wiki?

Not a site request

You would have to in this case ask Stewards via https://meta.wikimedia.org/wiki/Steward_requests/Bot_status

Allow administrators to grant bot, administrator or interface admin rights

Rejected because granting and removing those flags is a task for bureaucrats where present, or stewards. Interface administrators also have highly sensitive permissions (to edit CSS and JS pages) and requests for granting must be carefully considered. As such, it is necessary that only bureaucrats or stewards handle this task.

Could you describe exactly what you want in English?

In T233336#6414979, @elukey wrote:

https://meta.wikimedia.org/wiki/Wikimedia_URL_Shortener#Security

Users or IPs who cannot edit Meta-Wiki (blocked) are not allowed to create short URLs

From what I can tell, the IP is listed as a CDN Server in mediawiki's config and then the list of CDN servers is soft blocked in the config.

I would imagine it's an entry in https://github.com/wikimedia/operations-mediawiki-config/blob/e0969147a87cdb961c07abd39d7dd66554e9b58c/wmf-config/reverse-proxy.php#L5 because of https://github.com/wikimedia/operations-mediawiki-config/blob/167a7bd1a1c7c5d2051c229e50d7525f1b745993/wmf-config/CommonSettings.php#L3765 to blame.

Does anyone know what the external IP of http://webproxy.eqiad.wmnet:8080 is? I mean you could try authenticating to an account first?

System administrators make the final call. @Ladsgroup is part of that team.

In T261065#6404804

@cicalese edited subscribers, added: @cicalese; removed: @CCicalese_WMF.

In T233336#6401796, @ayounsi wrote:

Yes, the url shortener works fine with Turnilo URLs, the "feature request" is to integrate it in Turnilo UI.
To have a one click short url generation kind of thing instead of having to copy paste the URL between Turnilo and the url shortener.

To integrate it using the extension on meta, 08:33:13 <RhinosF1> XioNoX: https://meta.wikimedia.org/w/api.php?action=help&modules=shortenurl seems to exist so if you can make a valid POST request and paste the output. It should work. I'm not sure how it's built though for you to integrate that somewhere.

Isn't this intentional?

I see https://github.com/wikimedia/operations-mediawiki-config/blob/83b34e1bd1ed804a70f67e089580e082f89e2a0f/wmf-config/CommonSettings.php#L1207 which should allow *.wikimedia.org

In T233336#6401764, @ayounsi wrote:

Ping? SRE relies a lot on Turnilo and we often end up sharing links to each others, especially while investigating issues.
If this is an easy fix it would be great to implement it.
On the other hand, if it's more complex, I can understand :)

I updated the description per the title, feel free to change if wrong.

In T260469#6386651, @NullPointer wrote:

I do not know how to make pull requests with Gerrit, but the proposed changes are:

 json
" Q98391507"{"factor": 4184000000,"unit":null,"label":"J","silable:"Joule"}

Hey, https://www.mediawiki.org/wiki/Gerrit/Tutorial has a really good walkthrough.

Hi @Cparle, per the description of SRE-Access-Requests, you need to add the following information to the task:

In T260281#6385334, @NullPointer wrote:

I suggest setting this a security issue since this may cause people to intentionally make memory leaks to damage servers using this software.

With a single common keyword such as "gerrit" we match a ton of documents and the result set is huge, probably not very useful. I don't think there is a solution to that other than narrowing the search with more words.

Should this block the train?

In T260102#6375031, @Cocopuff2018 wrote:

DO not close this i closed the 1st one and merged it

First report was https://www.mediawiki.org/wiki/Topic:Vpds5hda4ilx90c4

tagging T&S seen as they handle 2FA resets to see if they are happy with this

I've seen this before on rare occassions in operations/mediawiki-config. It was a while ago though so can't remember when exactly but prior to new gerrit switch.

In T143162#6353539, @Aklapper wrote:

In T143162#6152069, @fgiunchedi wrote:

nowadays that gerrit patches are (very helpfully!) shown in "related changes in gerrit". IMHO we could completely get rid of gerritbot task updates

That might collide with the workflow of Platform Engineering (as GerritBot adds Patch-For-Review tags) (but not sure how exactly that data is pulled).

Yes. I planned on putting out an announcement a couple of days ago, but it turns out to be more complicated than expected. There will definitely be an email to mediawiki-announce at some point, and some of the private tasks will be made public.

Will there be any disclosure of the issue so 3rd party sites that followed suit in disabling it know what's safe?