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.

An update on this: I left the project untouched since Wikimania but I just finished the bulk of the code yesterday when I remembered this task existed. I aim to release the (probably-super-buggy-but-not-so-much-because-I-did-my-best) beta today.

Both of the libraries I just linked both use EventStreams, which is a push-based system for receiving server-sent events. No polling is happening there; I know because I created the JavaScript library and have contributed to the Python one. A cursory look at the documentation page for EventStreams explains that it uses Kafka as an event streaming platform. Events are fired as soon as they happen; if you want an example, try playing Asteroids (this uses EventStreams).

Are you intentionally suggesting this as a MediaWiki core feature? Wikimedia already provides the EventStreams HTTP Service and there are libraries in both JavaScript and Python which do exactly this.

In T404198#11173782, @Catrope wrote:

@Chlod More specifically, what was missing from CodexHTMLForm that meant you couldn't use it for Nuke and used Codex-PHP instead? Knowing that would help me plan for my upcoming work to improve CodexHTMLForm and hopefully make it good enough that Nuke could switch to it.

In T153988#11168207, @Chlod wrote:

Can add this in on a subsequent patch. I'll attach it to this task.

Well, it seems like Lookup doesn't actually have the focus method of its underlying TextInput exposed. We can't have autofocus on that field for now, as it requires a focus() to be called upon component mount. T404328: Lookup: expose focus() method filed.

In T153988#11169129, @DanielQ wrote:

The up and down buttons on the numeric fields are:

1. Really far away from the numeric value (not as easily found as they should be).
2. Very small and difficult to accurately click (probably almost impossible to click on a tablet or phone).

In contrast, the up/down buttons for numeric fields in OO.UI are easy to find and use. (Note the current OO.UI interface for nuke is not using those.)

It seems this is the same for Codex in Vue. So perhaps intentional, but I'm not sure. Changing that design isn't under the scope of this task, but it may be something worth bringing up to the Codex Steering Committee.

I'm currently unsure about this due the comments I mentioned at T153988: Migrate Special:Nuke to Codex.

In T153988#11168001, @Samwalton9-WMF wrote:

@Soda pointed out that on wider displays the form boxes stretch to fill the entire view:

whereas previously they had an upper width limit:

Is this something that design folks have an opinion on?

Likewise, I'm aware of the effort and responsibilities, and I'll help out with managing project resources.

Thanks, @Samwalton9-WMF! I was a bit busy recently so I couldn't have this done quick. I've attached the patch to this task now. :)

I'm tentatively wondering if we should remove the HTMLForm renderer considering Codex PHP is now in mediawiki/vendor and could be used in MW core. HTMLForm has the concept of display formats which actually does already include a somewhat usable "codex" option (though there hasn't been much progress on it recently it seems?) which ideally should be what we use in the long term, as many forms within the MediaWiki ecosystem already use HTMLForm and it makes no sense switching away from it just for Codex.

It seems like I had inadvertently removed the nuke-delete-more message which shows up at the bottom of the Nuke results page. The patch I just posted restores the message, and also reverts the commit by the Translation updater bot which removed those messages. Ideally, this should be reviewed whenever possible so we can cherry pick this into wmf/1.45.0-wmf.15 before it hits larger wikis and ends up breaking the workflow (since it completely removes the backlink to Special:Nuke on the results page).