In T365121#9804221, @Sebastian_Berlin-WMSE wrote:

Thanks for the info, @Urbanecm. I wasn't aware of acl*userdisable.

Hi @Sebastian_Berlin-WMSE! FWIW, all people listed in acl*userdisable are able to disable user accounts via https://phab-ban.toolforge.org/. If that would be useful, I can add someone from WMSE (possibly you or Lokal_Profil?) to that group, and then you would be able to disable accounts on your own, without needing a task (you would need a task if you ever need to re-enable an account, but that should be a less common operation).

This indeed is a site request (more than it is a maint script run), as it involves a config change deployment.

Patch uploaded, should be deployed sometime next week.

Done. @Pppery, per your request, I ignored all subpages and talk pages. I also deleted the /2024 page before starting the move. Would you mean helping with the rest of the cleanup here, please?

Done.

In progress.

In progress :).

Thanks for the quick fix @taavi!

Problem is now resolved.

An idea that originates from a recent-ish meeting with @Tchanders is introducing a temporary "IP addresses visible" mode, which would ensure all temporary accounts are resolved to an IP, which can be enabled from time to time (for a specific reason). Conceptually, this would be similar to Phabricator's high-security mode, which removes the need to enter a MFA token every time a sensitive action is taken. If this mode exists, it could help with the logging. It would be more similar to T346809 (except it would still be multipage, just not unlimited over time).

In T358852#9690255, @Tchanders wrote:

Do we need this for Special:DeletedContributions too?

In T351202#9682286, @Dzahn wrote:

In T351202#9678542, @Urbanecm wrote:

@Dzahn: Can you please make a dry-run of syncmembers and share it as a private past on this task, so that I can take a look at the changes it would make?

Done. Please see P59236

We also need to move the list of users from ~urbanecm/config/users.yaml to a better location. Filled T361547 to track that. Also, we should create a more reasonable export path than somewhere in my home. Maybe /srv/exports?

In T351202#9639225, @Dzahn wrote:

Following up on the last comment by Legoktm. I am also in favor of this option and would be happy to make the relevant puppet change to add a systemd timer for this on the lists server.

Could you export the list of stewards/email addresses on the stewards* machines locally and let me know where they are and then I take a look at the rest?

Hi @Dzahn, do you have any thoughts on this, please?

That sounds perfect to me @Dzahn! Thanks for the suggestion.

This was actually done AFAICS. Closing.

Move is in progress.

In T359553#9612508, @Superpes15 wrote:

In T359553#9612388, @sbassett wrote:

Accounts without Phab MFA enabled:

1. @Ajraddatz

Many thanks! I added the 6 members who have 2FA enabled to acl*security_steward and notified Ajraddatz about this :) We let you know when you should check again :D

Should be done now. Sorry it took so long, and thank you for your patience.

Done.

I've performed the removals. According to the last years decision of security team, we just now need to confirm 2FA is enabled as it should be before performing the additions (no extra approval is necessary anymore). Filled T359557 to be able to fully handle the ACL on our end.

Thanks @Msz2001! That was quick :).

Thanks for filling the request. Would it be possible to provide SVG versions for the logos you desire to use? With a SVG file version, we would be able to handle your request in a much easier way.

Move started.

In T320108#9542469, @dcaro wrote:

In T320108#9539081, @Urbanecm wrote:

Thanks @dcaro! I was figuring out how to make this work in k8s instead, and it was just a typo.

The question still stands though: assuming the grid engine is going to go away, how would I keep the tool working there? Or does this qualify for some sort of extension, as you mentioned in your prior message?

We can extend it for up to a month yes, you are clearly working on moving to k8s :), it's a hard limit though.

In T338032#9530131, @Dzahn wrote:

In T338032#9530072, @RoySmith wrote:

Is there some way I can track those zendesk tickets?

I am waiting for a response to the general question whether people outside @wikimedia.org can open ITS tickets. Will let you know soon.

Hi @Trizek @NemoLePoisson, I have good news! It took way longer than originally anticipated, but thanks to the conditional user options project I worked on recently with my WMF staff hat on, this change can now be fulfilled w/o issues, assuming French Wikipedia still wants to go ahead. Please let me know.

Thanks @dcaro! I was figuring out how to make this work in k8s instead, and it was just a typo.

Hi @dcaro, thanks for asking. I'm having troubles with migrating the webservice. I have a mix of Python CGI scripts and generic files to host under the urbanecmbot URL, and for certain reasons (such as, dependency of the Android app on the exact URI), I can't really move the Python part to a different tool and host it via the k8s webservice. I've been using the lighttpd grid service, which allowed the use of Python CGI scripts as well as other scripts, but I can't reach the same effect at k8s.

Thank you for creating this task. My name is Martin Urbanec and I am one of the system administrators responsible for performing site configuration changes. As of now, MediaWiki does not support restricting only the INDEX magic word – such a configuration setting simply does not exist, and as such, it cannot be changed. This means it is only possible to disable both the INDEX and NOINDEX magic words. However, this setting is a per-namespace one, which means we can disallow those magic words in one namespace, but leave them working in another. For more details, please see the docs at MediaWiki.org and documentation for the $wgExemptFromUserRobotsControl configuration setting.

FTR, I'm filling this ticket as a response to a question I received from WMCZ staff. I answered (using my understanding of how Wikistats, AQS and Hadoop work with each other), but I'm filling a ticket anyway, considering I indeed find the selected data visualisation to be very confusing and hard to understand (without reviewing the individual HQL queries).

Done.

Deployed.

As of now, this is not really actionable. From the description and the voting, there is clear consensus on introducing autopatrolled and patroller user groups at skwiki, which can be done. However, it is NOT clear who is supposed to be granting and revoking those groups (by default, it is stewards only, which is likely not intended) .

I (temporarily) "fixed" the issue by disabling the faulty test, but I'd appreciate help with identifying where the actual issue lies and how to fix it.

In T350568#9383011, @Xqt wrote:

@Urbanecm: I wasn't able to exclude Pywikibot-test from User Agent regex Pywikibot/8\.[56].+Python/3\.6 e.g. with (?!test) but get a 504 error. Any idea?

In T350568#9381768, @Xqt wrote:

@Urbanecm: Thank you. Currently I have no glue how can I get access to stat1005 and how to call the python statements you did last year in T312794. Can you lead me for the first steps?

In T350568#9377934, @Xqt wrote:

@Legoktm, @Urbanecm: Could one of you take over this task. Looks like it is too complicated to make it by my own.