@Dr-Taher @Ahmed_M_Farrag I did ping folks at T271823#6958921 but I realize on-wiki communication would have been better. My apologies! (I also admit I'm not great with wikitext-based discussion on RTL wikis, but that's my fault :)

I'm not sure if this is still a problem. Boldly closing, anyone please re-open if you feel this still needs attention.

In T331219#8730423, @GMikesell-WMF wrote:

@MusikAnimal The number links are now visible and are able to be clicked on but it went to the next line as seen in the screenshot.

In T331219#8722897, @GMikesell-WMF wrote:

Also wanted to make sure on the Leaderboard, it's just supposed to link to the reviewed by and not also the actual number that's on the Leaderboard, right? (ex. Star Mississippi: 2, it's not going to only show 2 of them but all "Reviewed by:" under that user's name)

This is an engineering-only kind of thing, so I'm going to just resolve and move to Done.

PR: https://github.com/wikimedia/CopyPatrol/pull/165

PR merged and deployed! This could benefit from QA, but I'm going to leave it to our QA engineers to decide whether it's worth their time, as I assume they're unfamiliar with CopyPatrol. The acceptance criteria hopefully details all you need to know. Please ping me if you'd like a general walk-through of CopyPatrol, or if you have any other questions! The tool is at https://copypatrol.toolforge.org and we also have user documentation.

MR merged! @Samwilson Did you want to point this task and move it to the sprint? I realize you worked on this weeks ago; Sorry it took so long to get it merged :/

@Samwilson I gave this 1 point (in the context of this task by itself), please feel free to adjust as you deem appropriate :)

Should be fixed now following 079a9b0d. I'll do a deploy sometime today.

In T324233#8690718, @dom_walden wrote:

…
From https://www.php.net/manual/en/language.operators.array.php

The + operator returns the right-hand array appended to the left-hand array; for keys that exist in both arrays, the elements from the left-hand array will be used, and the matching elements from the right-hand array will be ignored.

…

With the continued hiccups with SlimApp (T332635 for example), I wonder if it's worthwhile to migrate CopyPatrol to use the Symfony framework, which is what we use for most of the external Community Tech applications. This would make maintenance easier down the road, since whatever changes are needed on one repo apply to all of them, and a lot of such changes would only be needed in one place -- the shared ToolforgeBundle.

Moving to the sprint since I spent so much time debugging this! I figure some points should go towards our velocity.

In T332650#8716712, @Tgr wrote:

In T332650#8716622, @jsn.sherman wrote:

Considering that all of the impacted clients are oauth 1.0a, I wonder if moving to oauth 2.0 might resolve the issue for us.

This specific one, yes. In general, I think since most tools use OAuth 1, it gets more attention (OAuth 2 was fully broken for a day just last week), even though in theory OAuth 2 is simpler and so easier to maintain on both sides.

We also talked about tracking the number of clicks on the (i) icon. This can easily be added as we're already tracking clicks on other Phonos elements. This is not critical data, but it'd be interesting to see!

In T332349#8712365, @Scardenasmolinar wrote:

@MusikAnimal do you know in what part of the code the authentication breaks? The Wikipedia Library's authentication seems to be breaking here: https://github.com/mediawiki-utilities/python-mwoauth/blob/master/mwoauth/functions.py#L193

I've spend several hours debugging this and finally concluded it's something with MediaWiki-extensions-OAuth itself that's failing. I've filed T332650: Frequent OAuth failures on Wikimedia wikis since eqiad was repooled due to db-mainstash replication lag.

Quarry seems to have the symptoms of "not every login works", and same for CopyPatrol (T332636). Perhaps this is a broader issue?

Both https://copypatrol.toolforge.org and staging have been updated. Logging out no longer seems to throw an error. Resolving as this is very tiny and I don't think requires QA resources.

Note we already have a 5 TB volume (T297446) that holds the data for 5 wikis. There is room left, but we need to save some room for those languages to grow. I believe it's also possible to expand the size of the current volume, which we can explore if recommended, but the thought with the preexisting concerns with very large volumes (T297446#7573058), we're better off using a new volume.

More of an engineering-only thing, so boldly closing as resolved.

More of an engineering-only thing, so boldly closing as resolved.

The instructions are referring to adding the bot to a new wiki, just as it says. It sounds like this is for an existing supported wiki (English Wikipedia). In the same section it says "WikiProjects can sign-up or modify their enrollment on the configuration page", which is what applies to this request.

In T330173#8704673, @Ladsgroup wrote:

I wrote this long time ago. Maybe that'd be useful? https://www.mediawiki.org/wiki/User:ASarabadani_(WMF)/Database_for_devs_toolkit/How-to/Data_migration

I started on this, but it's more of a "free time" project so not putting it in the sprint just yet.

This to me is a bit counter-intuitive, but it's perhaps me just being used to the status quo...

PR: https://github.com/wikimedia/CopyPatrol/pull/158 (combined work with T331220 as otherwise we can't get the CI build to pass)

PR: https://github.com/wikimedia/CopyPatrol/pull/158 (I combined work with T293688 since otherwise we can't get CI to pass)

In T293688#8627887, @JJMC89 wrote:

@MusikAnimal, some questions before I finalize this for you to update the front end:

Added T331219: Search through reviews a user has done at copypatrol as a subtask as at least for me, it cannot be tested until the CSS issue is resolved.

What a pity that Wikimedia's fork of SlimApp is not versioned! I guess we could target a specific commit, but better we upgrade to PHP 7.4, anyway, I suppose.

Wow, thank you @JackPotte! I've left a review of the PR.