Thanks! I've enrolled my primary and backup Yubikeys now.

Yeah, a delete is probably good enough as a fix. Not sure if there's anyone else with this same issue; might be worth a quick query to check? Just so that there won't be any more tasks on the same thing.

n.b. I'm affected by the same issue and I have "Bureaucrats" in the "Disabled group" section of my preferences, but I'm unable to enroll a 2FA method. I've tried twice now, but it seems that MediaWiki does not remember that I enrolled a 2FA method as soon as I finish trying to enroll one.

Yes, the logo changes only affect the websites and do not affect the app. For app related requests, you'd want to reach out to the Apps Team instead, though I don't think the logo is normally changed on apps.

Gonna keep this open until the undeploy in a month from now which I've saved in my calendar. June 30 luckily lands on a deploy day, though the window (UTC late, 20:00 UTC) is going to be two hours earlier than the requested end time on this task (30 June 2026, 22:00 UTC). It'll likely ride that window, unless someone's down to do another out-of-window deploy at the end of this month (22:00 intersects with the Security team window, so 23:00 is likely the earliest possible time after 22:00).

Gotcha. Thanks! Please check the below and see if it's all good to go :)

Vector Legacy	Vector 2022	Minerva (mobile)

In T424519#11973081, @Ciell wrote:

Thanks Chlod!

• I think I was using an older skin myself at the time of filing the request, haha. It would be great of we could have "25 jaar de vrije encyclopedie" for the duration of June. The verb "celebrating" does not translate well here, so I would propose to stick with our translation of "25 years of the free encyclopedia", if possible.
• And yes please, the same change across all skins would be great.

Hi, @Ciell! Sorry this didn't get picked up earlier. Just asking for some clarification with this request:

• The file you linked to appears to be the plain untranslated version of the logo. Would you like to have this logo but with the standard "Wikipedia, celebrating 25 years" text below it?
  • If yes, we'll need Dutch translations for that text. Feel free to provide this here; I can make the image files as necessary.
• The logo you linked to is applicable only for Vector Legacy, which is not the default skin, so this wouldn't be seen by many readers of the Dutch Wikipedia. Would you also want the respective logo changes for Vector 2022 and Minerva? (see F71496396 and F71496402 for an example)
  • If yes, we'll also need a translation for "25 years of the free encyclopedia".

The EDS integration is something we've worked out with @Samwalton9-WMF who manages The Wikipedia Library. EBSCO maintains contact with his team and agreed to give us an API key for copyright enforcement purposes. Probably hit Sam up with an email (or Sam can tell you where the best place would be?)

Still missing some details (author name, DOI, etc.) but that's because I still have to sort out proper formatting on the source titles.

Worked on this for the Hackathon. Surpised that EBSCO still has not revoked the credentials we got from them!

In T419116#11728238, @Jdlrobson-WMF wrote:

In this case from what I can see, this has not been implemented the advised way (as documented on https://www.mediawiki.org/wiki/Skin:Vector/Customizing_the_logo_for_special_events)
...
Please note we have guidelines around how to customize the logo for this exact use case here: https://www.mediawiki.org/wiki/Skin:Vector/Customizing_the_logo_for_special_events#Adding_images_after_the_wordmark

These URLs actually should be removed from the response; the only ones that have them are the /api/(uid|cn|mail) endpoints, and I initially intended all normal endpoints to have that but it seemed a bit excessive (API docs felt like a better place to find these than throwing blind requests to the API). That said, I have no clue if people actively rely on this, so I'm willing to give some very minor support for it while there isn't a "real" API docs page for the tool yet.

Whoops, refactor gone wrong.

The discussion closed without a specific determination on what to do with the logo, but I think it's fairly safe to say that there's support to have the logo on for longer. I'm unlicking this task for now to avoid the implication that it's actively being worked on. Nevertheless, the patch remains valid, just unscheduled. If anyone has opposition; please feel free to make your voice heard. If you want to pick this task up yourself, also feel free to build off the existing revert patch.

Potentially Regression related to 023e989? The edit seems to have added a reject to the "missing summary" flow that wasn't there before. cc @Dreamy_Jazz; I currently don't have much experience working with this file so I'm not sure of the consequences of just having that flow resolve the promise instead, though a cursory glance at the context (T407202) and the tests added tells me this is not something you'd want.

Noting here that there's a proposal to extend the logo until March 16 to complement Birthday Mode (MediaWiki-extensions-WP25EasterEggs).

I've found ncdu (side note: this article really doesn't seem like it should exist) to be more useful when trying to find out what's taking so much of disk space. It also has an --exclude <pattern> option if you want to exclude the mounted volumes.

Deployed, and the required CSS for Vector 2022 has been applied by @Izno. Happy birthday, Wikipedia! 🎉

Hi, @Nurtenge! The wordmark and tagline are separate and thus need to be uploaded separately on Commons. Please see the request for enwiki (T414271, file of wordmark, file of tagline) for an example.

Hi, @GeographieMan! The wordmark and tagline are separate and thus need to be uploaded separately on Commons. Please see the request for enwiki (T414271, file of wordmark, file of tagline) for an example.

Timeless situation is fixed. I ended up changing $wgLogos['icon'] anyway. Also added the CSS required to hide the logo on Vector 2022 to the comment above. See below for Timeless preview.

I've prepared the patch and scheduled it for deployment at the January 14 UTC late backport window. This window is 3 hours before January 15 00:00 UTC, but being a bit early shouldn't be that big of a problem.

I'll close this as declined for now. Looking into the code, it seems like there's going to be additional complications if we silently permit invalid page titles. Refactoring the code to support this (by using page IDs instead) sounds like something that's not worth an edge case that could be solved by running the maintenance script.

DummyWiki is now back up and I'm seeing redlinked existing pages from the user that you included in the replication steps: https://wiki.dummywiki.eu/index.php?title=Special%3AContributions&target=BZPN&namespace=all&tagfilter=&newOnly=1&start=&end=&limit=50

@BZPN We would appreciate if the details of the bug were copied here on Phabricator. This helps add more context to this task for anyone coming across it.

Deployed and now fixed!

Sample email address provided privately. Deploy in ~10 minutes.

@Gopavasanth: Please provide replication details, i.e. an email address that causes this issue. Alternatively, a developer account UID with an email that uses uppercase letters.

Done and deployed! I'm using the user events API here, so the data isn't as good as it is with GitHub. The tool tries its best to make use of the data provided to it by the events API, which is not a lot of info and sure as hell not detailed at all. But it sure is better than nothing!

This one seems to be harder than I thought it would be. It turns out GitLab doesn't really have the same level of indexing that GitHub has. The procedure for GitHub is we search for every commit that a user has across all repos in the @wikimedia organization, so that we get a full scan of everyone's commits, regardless of time. Unfortunately, commit searching is unavailable without Advanced search, which is only available on GitLab Premium when running GitLab Self-Managed. Of course, this means we don't have that functionality. An alternative is that we could provide historical data by directly targeting /merge_requests, etc. to search for merge requests by a specific user. Unfortunately, this requires a GitLab account with administrator access, so that's also a no-go. I thought about scanning commits of the projects that a user is a member of, but seeing the memberships of a user also requires administrator access (so we can't have something like Gerrit where we show a user's group memberships).

Happy to work on a patch for the latter solution if someone's willing to review.

Hi, @Niharika! Sorry for the late update. Yeah, this can be closed now. It seems we haven't received any reports of issues with Ultraviolet during the rollout of temporary accounts. We'll work on further UI/UX improvements as part of the tool later down the line.

Putting this on stalled because this can't continue without a Gerrit account with authorization. At the very least, the code does exist now. The /groups/{group}/group endpoint appears to require non-anonymous access (unlike many other endpoints) and will toss you a non-JSON error if you try to make a request without access. I could use my own account but I assume that's discouraged because Gerrit bot accounts are a separate concept and there appears to be a distinction on what threads can be used for user interactive work and bot work. Maybe I should request a Gerrit bot account (with just read-only access) for this? 🤷

On second thought, either of these would require one request per group anyway. 🤦 Did not think of the request logic that far ahead. I guess that's the only option here if we really want this. Might just add a lot of caching in to prevent a flood of requests.

Noting here that it's possible to build an inheritance tree with the Gerrit REST API /groups/{group}?o=INCLUDES option, but this seems to be disabled in Wikimedia Gerrit, because I'm not getting a list of direct included subgroups. It'd be nice if this were enabled, though I'm not an SRE so I have no clue of the ramifications of that. The alternative to this is calling /groups/{group}/group (subgroups) on every single group that we initially get from Gerrit, but that would suck as well since we have to make a lot of requests to Gerrit, even if we started culling detected subgroups before we get their subgroups.

In T393322#11376563, @Novem_Linguae wrote:

Very nice. Two small suggestions:

• remove "primary" from primary ldap groups. Im not aware of any "secondary" ldap groups

Your Toolforge tool and Cloud VPS memberships are technically LDAP groups, but they are indeed shown on a different panel. If the tradeoff of just simply calling them "LDAP groups" (which is a little bit misleading) is fine, then sure, we can drop the word.

• limit posix group descriptions to 95 characters, and chop the rest of the string after that, and add a ... . 95 chars is about the width of one line, and most other posix descriptions are one line. See this example: https://techcontribs.toolforge.org/uid/taavi

That's my initial thought, though this is very likely going to break the text. A URL will be chopped off and lead to a non-existent page, or (if we use analytics-privatedata-users as an example) it will just have completely incomplete information (e.g. This group is the main entry point to the Analytics cluster, since it gives access to the stat1...). This method would be great if there was any other user-friendly place to view these groups for a user that I can link to (similar to how Phabricator projects link to their on-Phabricator tasks), but alas I don't think such thing exists.

Now deployed! Initially was going to wait for other tasks to be done but I thought I should get this out now. "Primary groups" have been renamed to just "groups". The name "primary groups" originated from wt:SRE/LDAP/Groups, and since we're including more than just that now, I've changed the groups from LDAP to be specifically named "Primary LDAP groups". I've gone with the name "production access groups" for the groups defined in Puppet, because as you point out, that's what Wikitech calls it. Changing what it's called is out of scope for the tool; I just follow what Wikitech says. Please feel free to reopen the task if there's anything that needs changing! Live examples: taavi, novemlinguae

I've long wanted to use a pie chart but with lines to denote which slice is which, but the library used for the charts do not support this. A different chart is probably the way to go here. As to what chart that is, that's a ? for now.

Also affects: fountain, PetScan

Late response to this (sorry!), but upon inspection of the code, there's nothing in both Ultraviolet or RedWarn that would require significant changes ahead of deployment. The only things that require changing are small QoL changes (e.g. saying "a temporary account" rather than "a user" in the interface). For the most part, Ultraviolet should already treat temporary accounts much like regular accounts, and also do any required template changes on the wikis that require it (e.g. changing {{IPvandal}} to {{vandal}}, not using {{Shared IP address}}).

Should work now. It seems like Nginx just doesn't like super long cookies.

Yeah, I'm in the middle of trying different things out to see if the proxy is blocking something specific. According to the logs, the entire "login" process is fully completed, so the part that fails is somewhere in between the "setting the session cookie → redirecting the user to the main page" part. The error there was because I set the cookie security to Strict, which turns out isn't a good idea when handling OAuth responses from Meta-wiki. I've set it back to Lax and yep, still not working.

In T401274#11198942, @Samwalton9-WMF wrote:

I'm getting a Toolforge error when attempting to login. I click login, get taken to Meta to approve the OAuth login, and then got sent to https://unwatchlist.toolforge.org/login?code=[a long code available on request]

In T401274#11196730, @Samwalton9-WMF wrote:

In T401274#11196518, @Chlod wrote:

https://unwatchlist.toolforge.org has been created and deployed but it's currently pending OAuth application approval for it to be usable by anyone besides myself.

Amazing! Let me know when it's approved and I can QA.

https://unwatchlist.toolforge.org has been created and deployed but it's currently pending OAuth application approval for it to be usable by anyone besides myself.