I wondering whether this should be completed in the first place. If we decided administrators do not need the unblocking permission, this should apply for blocks by filters as well, right? If we do this, I'm wondering where would be the line where unblocks need to be done by another admin.

See prior convo in T327034 about this.

In T396951#10915828, @A_smart_kitten wrote:

Might be worth bearing this (September 2023) comment from another GitHub issue in mind — I don't know whether/to what extent it's still an issue, but it seemed worth flagging here just in case:

https://github.com/freeotp/freeotp-android/issues/334#issuecomment-1711954232:

👋 GitHub PM for Identity here. We use an 80 bit secret for compatibility with Google Authenticator, which had a bug for a very long time around longer secrets. It's unclear if they've since fixed it since it was abandonware for so long - now that they've updated it to support sync, maybe they fixed that too.

@EMill-WMF For your awareness. This causes issues with the mandatory 2FA rollout we're currently working on. Would you mind flagging this to the appropriate subteam, please?

In T386492#10859924, @Tchanders wrote:

In T386492#10798615, @JJMC89 wrote:

In T386492#10797269, @Tchanders wrote:

Global groups that have the checkuser-temporary-account or checkuser-temporary-account-no-preference right should also have the checkuser-temporary-account-auto-reveal right. A list of rights assigned to global groups can be seen at: https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions

Would we need to ask a community member to add the checkuser-temporary-account-auto-reveal right to the relevant global groups?

Yes, a steward needs to do this.

@Urbanecm Would you be happy to do this?

@Dreamy_Jazz and I discussed this at Wikimedia-Hackathon-2025. Dreamy_Jazz pointed out this might happen if a cookie block gets involved. After some testing, I can confirm that hypothesis, a cookie block is issued for IP hard blocks. I previously wasn't able to reproduce on desktop, but I was testing this with a soft-blocked IP instead.

That is the expected behavior, then I did everything correctly. Can we move stewards-l to actual runs then, please?

Please see T351202#10616848 for a more general note on moving the maillists (other than stewards-l).

A general note on this: The biggest remaining problem to solve is the "it is very hard to see what you just done" problem. When running the sync, the onboarder tool doesn't tell you what changes are being made (as compared to the current maillist membership), mostly because it does not have a way how. Here is how the Gitlab integration currently behaves (for comparison and a "ideal end result" description):

@Dzahn Boldly assigning to you for step (1)!

@Dzahn Would you mind helping with this, please?

Noting @jrbs was added to the group in T220860, in order to be able to run changePassword.php on Wikitech (which back then was linked to LDAP directly). Running modify-ldap-userseems to be the today equivalent to that. I'm not sure if we want to allow password/email resets via Bitu.

I asked @Melos to email @KFrancis with their details to start the NDA process as well.

Approved from my end.

In T386479#10554979, @Nemoralis wrote:

@Urbanecm can we add Special:MyLanguage/ to wizard links? Wizard is translatable.

Resolving, as the patch has been merged.

In T351202#10529743, @Dzahn wrote:

Would it be useful to run dry-run syncs that don't actually modify things but show what _would_ happen and then email those out to you (a group)?

Filled T386410: TranslatableBundleMover does not lift the lock if an asynchronous move failed to be schedule as a related issue (when moving a translatable page, it erroneously stays locked even though the job was not actually scheduled, and thus no move is happening).

Happening for me as well (when moving translatable pages). Moved ~10 pages and got the error for 3 of them. I looked through the logs and found this:

In T385808#10532691, @KFrancis wrote:

Hi all, I checked my records, and I do have have a NDA for anything under kwa.schultz@gmail.com or user EP1C. What is this person's full name?

In T385833#10536830, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2025-02-10T21:23:38Z] <urbanecm> Start namespaceDupes.php on shwiktionary (T385833)

Approved.

In T351202#10506235, @Dzahn wrote:

@Urbanecm What's the latest here? Anything waiting for me or my team here? Would you consider this stalled for now?

Started to receive emails for wmcz-stats about this:

Done (both).

@AntiCompositeNumber FYI, this is the task for the issue you mentioned the other day.

This kind of failure happens intermittently on IP range queries. For example, several subsequent loads of this query always show only results of one wiki. For me, it showed rowiki only at first load, then only nowiki results, then again nowiki only and then it displayed dawiki results. This makes the tool hard to rely on, as it hangs mid-way.

Thanks @Dreamy_Jazz; I was looking for "DBQueryError", and didn't find anything). Sorry for the duplicate!

This would be useful in the following cases:

Ran namespaceDupes.php, since the change involved namespace changes:

I also attributed Nominatim on the page: https://www.wikimedia.cz/cs/akce/. All seems to work again!

Unfortunately, the key part of the message is truncated. Debugging showed the full error message was:

Moving to backlog, as I don't think this needs refinement anymore.

@MacFan4000 The problem happened again.

Hi @JJMC89, thank you again for the discussion we had on the task. I rewrote the task's description (and the acceptance criteria) to meet what we discussed in here. Personally, I slightly prefer having the preference only display to otherwise-eligible users (to avoid confusion that would happen when you check it, but nothing happens), but if you strongly prefer it to be displayed to everyone (and essentially be a no-op if you don't meet the other criteria), I believe we can make that work as well. If you have any other feedback regarding this, I'm curious to learn about it.

In T380375#10411591, @JJMC89 wrote:

I would add it to Tools on User and User talk pages.

IMO, its not needed for RC, history, or watchlist.

Thanks for the ping, @Tchanders! Unfortunately, this isn't the case. User rights (including checkuser/oversight) are generally removed in two cases:

Thanks for the catch (and for the fix)! I've +2'ed the patch you uploaded.

In T382805#10424503, @Bugreporter wrote:

Should wiki be closed? Closure mean editing will be restricted to stewards and global interface editors, and all sysops and crats of the wiki be removed.

In T382082#10403527, @JJMC89 wrote:

In T382082#10403117, @Niharika wrote:

We only want to allow global IP reveal blocks, not local ones, because if someone is abusing IP reveal on any wiki, they should not be able to use it on other wikis.

This is basically what we were discussing with Legal yesterday. I believe local IP reveal blocks should be permitted because if a local admin or Checker detects abuse, they should not have to wait for a steward or global sysop to take action against them.

Per policy, only Stewards and Trust & Safety are permitted to remove access.

I don't think this is an (immediate) problem. As far as I understand things, unserialize only poses a problem when it is given an untrusted input (as it can construct objects, and that involves running code). ArticleFeedback reads logging.log_params, which should be (reasonably) trusted.

In T381273#10371500, @Slst2020 wrote:

Has this worked for you in the past, then started failing today?

@Daimona Do you have any thoughts on this?

This was discussed during the December Stewards meeting. Stewards agreed on continuing this, We should also add a new global block option that would control whether emails are allowed to be sent (since sending an email from the wiki is the appeal process). To summarize the consensus, we would:

In T331193#10369672, @Ravitej_Neeli wrote:

@srishakatux I am working on this task, its very easy one!

I just ran into this as well. For some reason, this works for me from Python 3.9, but not Python3.11.

Uploaded https://gitlab.wikimedia.org/toolforge-repos/ircservserv-config/-/merge_requests/17.

I'm happy to help with setting this up, if someone grants me the permissions on that channel.

In T380308#10365300, @Niharika wrote:

I like it. @mszabo @Urbanecm what do you think?

In T381028#10363708, @Reedy wrote:

Deleting a global (user) account isn't the same as deleting a user account (which we don't really do)...

Thank you for the ping, @KColeman-WMF! Generally, the design seem like a step towards the right direction. I am wondering about a couple of things:

In T380743#10353886, @Xaosflux wrote:

So back to the list, I can also see reasons why when blocking a network globally we wouldn't want to block 'send email' locally as that will prevent use of Special:Contact (which is used for appeals as well).

In T380763#10354217, @Frostly wrote:

I completely agree that community consensus is not necessarily needed just because someone objects, but I also think that there are many relevant times when community consensus is legitimately needed for major changes to core or extension functionality.

In T380763#10354286, @Pppery wrote:

However, I disagree with the premise here entirely - the usage of the Community-consensus-needed tag means someone thinks the feature request needs a community discussion. That's different from personally disagreeing with it - I disagree with a lot of proposed features that I know are in the authority of the developers to implement or not, and usually express that with a token rather than with any tags.

In T378401#10352985, @ArielGlenn wrote:

kludging things enough for an integration test to fake a creation of a local account on another wiki, with a global account, with the right logging table entry etc, just felt like it was too fragile.

Note that prior to @Frostly 2023 changes, the tag was limited to configuration changes even more explicitly. It read:

Courtesy CC to @Xaosflux, who applied the tag on a feature task earlier today.