As the operator of a bot affected by this, I'm also confused as to what exactly is being achieved here. Can you give concrete examples of requests that would be impacted if that right isn't there? My feeling is that most bots don't need it.

@A_smart_kitten This will require a global RfC.

This is a tricky one, and I can see both sides to this. That being said, I think it should be enough to give interface-admin to bots in such a situation.

It seems to have been already adjusted indeed, so closing this one.

What do people think of my writing a script to retrospectively fix the bug by having a bot fix any inconsistent suppression? @Xaosflux complained that https://meta.wikimedia.org/wiki/Global_statistics was printing suppressed users' usernames (which is expected given this bug), but @Ajraddatz said not to bother as I'm not a steward. Note that external tools such as Wikiscan are also equally affected.

Can you force-create a local account for Leaderbot? It fails when I try to login, telling me that I am not authorised to perform the action.

I was pleasantly surprised to see this - it's particularly helpful for the global reminder bot as I can easily check whether I've already added a wiki at https://meta.wikimedia.org/wiki/Global_reminder_bot/global (i.e, to prevent duplicates).

I think T370842 makes this redundant (enabled on like 80+ wikis). The only reason why I'm not making it as complete at the moment is that the bot doesn't have global bot status.

@Aklapper: I see what you mean, but then see "Convincing reasons for raising the priority of a bug include evidence that it affects normal, everyday work significantly". I felt that was applicable and also: I did say in my above comment that I am thinking of writing a bot to fix the bug, at least retrospectively.

I don't think this one is "low" in my opinion. As a patroller, I regularly hit cases where I look at the account and it looks as if nothing has been done to it, but the account is actually globally suppressed. Similarly, there are multiple suppressed account freely visible at https://meta.wikimedia.org/wiki/Global_statistics (also: restricted task T331046), to the extent that I was motivated to consider writing a bot to fix this retroactively (see https://meta.wikimedia.org/wiki/Stewards%27_noticeboard#phab:T25310).

For what's worth, T370842 does this now (have been busy applying for authorisation on various projects, and already running on a few projects). I'm not sure how important this task itself is as a result.

See https://meta.wikimedia.org/wiki/Global_reminder_bot

I think this is stale and needs to be declined. Beta-Cluster is a testing platform, so it's used in ways that wouldn't be used in production. Also "userrights-interwiki" does not cover all cases even on production (i.e, when a right not on Meta-Wiki needs to be changed).

The closing session is already in progress, so I don't get the purpose of this request (or was this created for fun?).

In T371995#10050337, @Aklapper wrote:

Why can you not test these gadgets as personal user scripts on zh.wikipedia.org ?

Hi if possible that would be nice.

I generally prefer leaving the user name as part of the summary (which would happen only if one person edited that page, right), so prefer this as an option.

@Mystrixo a thumbs down is just the default icon Phabricator (this software) uses to indicate a declined request.

Closing this old report; as Legoktm pointed out, the proposal is unfeasible as it stands.

@lbowmaker it's been almost a year - is there an update on this?

Statanalyser seems to be affected, as it did not run this morning.

@Acagastya

To be clear, you want to get some sort of "added_lines" feed (not "added_edits") feed from which projects.

/data/project paths are specific to each Cloud VPS project, so you can't access the home dir of a Toolforge tool directly from a Cloud VPS instance

@rook One more thing - is it possible to increase the disk limit to ~200 GB? This is because I did not know that I cannot access Toolforge data from Cloud VPS (Wikitech didn't give any such indication), and while my data is highly compressible, I need the initial temporary space to hold them. Apologies for reopening again (I didn't know whether I should have created a new request instead).

@rook That's fine.

I have managed to optimise my code so that it now runs with ~20-23 GB of memory. However this still runs into Toolforge issues; is there a way around that? I see that Cloud VPS has a 36 GB RAM instance which should be enough.

Is there an update to this request?

However, it sounds like the toolforge environment is working for you, apart from the memory limitations.

I would encourage you to profile the application and make sure it's acting as you expect

In T286859#7223008, @bd808 wrote:

In T286859#7220127, @Leaderboard wrote:

In T286859#7219964, @bd808 wrote:

I actually haven't found a local override for MediaWiki:Badaccess-groups yet to borrow ideas from yet. There is no override for that message on meta, mediawiki.org, or enwiki.

This just means that anonymous editors are not allowed, and I would change it to reflect that. Something like "to edit Wikitech, please log in".

In this very particular case you are correct that any authenticated user satisfies the missing group-user right. The thing that might not be obvious is that any message override we create will be used for all badaccess-groups responses and these could be parameterized with other needed rights which are not satisfied by merely authenticating. I am not sure that there are any other group based restrictions on page edits configured for Wikitech today--there very well may not be any--but there is no guarantee that there will not be others in the future. Overriding the system message to document one specific error cause and resolution without support for other messages that the system may be trying to present will actually make confusion worse rather than better.

I know I am an insider in my use of both Wikitech and MediaWiki, but the current message: "The action you have requested is limited to users in the group: Users." actually provides factual information and if you click through to the page on meta that it links to seems to clearly state that the fix is authenticating to the wiki.

In T286859#7219964, @bd808 wrote:

I actually haven't found a local override for MediaWiki:Badaccess-groups yet to borrow ideas from yet. There is no override for that message on meta, mediawiki.org, or enwiki.

In T286859#7219632, @Aklapper wrote:

in line with other Wikimedia projects

What do other Wikimedia projects do? Please include expected behavior in tickets - thanks!

@Zabe It seems that you have assigned the removal of flood from self to WIkisource, not Wikibooks. Also with that change you can safely remove add/remove flood from 'crats.

In T285130#7163499, @Billinghurst wrote:

I would thought that it would be reasonably obvious why that is not a great idea to grant it to all autoconfirmed users

In T285130#7163461, @Billinghurst wrote:

Do you know what you are talking about? That is not the proposal nor the consensus of the community. The purpose *is* to create a limited scope for the right.

You were welcome to have joined the conversation. You are welcome to read it to enhance your understanding.

How about giving this to autoconfirmed users instead of creating an entirely new group with such limited scope?

My response above was to MarcoAurelio, but will supply a response to JEumerus' question below.

In T284241#7132994, @MarcoAurelio wrote:

I think rMW maintenance/reassignEdits.php can be used to do this, but I've never seen this being used on Wikimedia.

In T237890#5930305, @TerraCodes wrote:

Couldn't you just temporally add yourself to the bot usergroup?

You should also include WSL (by dual-booting the iMac/Macbook Air). That's a killer Windows 10 feature that I think is being underreported.

In T282624#7101559, @Alfa80 wrote:

I am also thinking of this approach (to further reduce concerns about 2FA status by using 2LA, see below ):

Is it possible to mark the changes made by an IA with some "Requires review" flag so that all other users keep seeing/using/loading the latest approved version before that change. When someone with adequate permission approves the change, it will become active and visible worldwide. Hence we achieve a two-layer approval (2LA)

In T281600#7099050, @Acagastya wrote:

@Leaderboard we can't have the mailserver there. So we can really drop that part of the request.

In T281600#7095826, @Bstorm wrote:

Just wanted to make sure you still wanted/needed it.

In T281600#7094315, @Bstorm wrote:

Ok, I think we can create the project so you can create some VMs. What was the verdict on the floating IP? I'm a bit lost on that.

In T281600#7086223, @Bstorm wrote:

In T281600#7086207, @bd808 wrote:

No. Using Cloud VPS as a proxy to access geo-blocked content is not an acceptable use.

+1 This is not a grey area. It is simply not an acceptable use.

In T281600#7085517, @Bstorm wrote:

By "infrastructure" I mean a blank virtual computer, per @Leaderboard 's comments. You have to build a database, web server, etc. and keep them safe.

In T281600#7084372, @Acagastya wrote:

Re guarantees, are you referring to loss of data, or backups, or storage failures?

In T282624#7083246, @jrbs wrote:

Hi all. Thanks for your input. I apologise for the hasty implementation here.

Taking into account the feedback provided here, T&S will put together a more comprehensive communications plan around this change.

In T282624#7081664, @Leaderboard wrote:

Also, I am not happy with the practice of WMF delegating everything it wants to stewards - why can't the WMF do it themselves if it's really that important? Remember that stewards are often overworked (T162297).

I would like to clarify that this change was not made alone. We have been discussing this with the Stewards for months. This is not a case of a random decision by a rogue staffer, it's just a staffer who made some communications mistakes.

In any case - please allow us some time to come up with a better way to communicate how this change will happen, what it will look like from a practical perspective, etc. I would like to ask @Quiddity to remove or potentially reword the Tech News item about this task too please. :)

In T282624#7083009, @Tks4Fish wrote:

In T282624#7082771, @Leaderboard wrote:

How would bureaucrats removing 2FA from the request of the user (or abuse unrelated to 2FA) be an issue? I don't think 'crats need to check for 2FA when removing access; the only reason for stewards to remove should be for the lack of 2FA and nothing else according to the proposal.

<small>Bureaucrats would remove IA, not 2FA, think you mixed up the names.</small>'Crats won't check 2FA when removing access. What I'm referring to is a regular audit for 2FA status of IAs. If they don't have it enabled, the access is removed after a warning and a period to reenable it. The issue starts because, when stewards do that, local 'crats would say that stewards are overstepping their boundary, and that is why it'd the removal is also being removed from 'crats.

In T282624#7082771, @Leaderboard wrote:

Also, if you don't explain why "you should make the function not work if 2FA isn't enabled", us users can't understand why that's not an option (I'm not sure what BEANS has to do with that either, unless I am missing something).

Discussing why is saying "hey, do this and that and you can go over our security", that's why WP:BEANS was invoked.

In T282624#7082657, @Tks4Fish wrote:

As for the whole "you should make the function not work if 2FA isn't enabled" there's a huge BEANS complication here, so not going to go deeper.

The check only works in the moment, yes, but there's work on the pipelines for regular audits of 2FA status for users that should have it enabled.

Due to that, 'crats can't also remove the flag, as stewards doing the audit would be overstepping the boundary when removing it due to lack of 2FA, and 'crats can't check it due to the above.

I'm also reopening this task as this comes from the office and thus doesn't need consensus.

Going bold, anyone can feel free to revert if people think my action is inappropriate. I can't, in good faith, allow a proposal that has not been discussed beforehand and raises so many questions.

Why is such a drastic change not widely announced? I've never heard of this plan before today. At the very least you have got to be informing every community with an active bureaucrat. I would support allowing bureaucrats to verify 2FA - that should be a no-brainer. Such a ridiculous proposal with no notice...

For the record, it works properly when trying to rename the same user globally (returns an error saying that "you cannot rename yourself"). The problem is only local.

In T281600#7063113, @Ladsgroup wrote:

sysadmins don't like creating it on prod so will give this a try and see if it works; fought hard but they are persistent

What type of phrasing is this?

I outlined my reasoning in the declined ticket. I see no need to "fight" (iterate again) here. The requested material are not private in sense of NDA-protected private information and certainly WMCS is much more secure than some random third party vendor.

In T281600#7062941, @bd808 wrote:

In T281600#7062873, @Acagastya wrote:

Frankly, the seriousness of it should be treated no less than CU, or OC wiki, though it won’t require near the same amount of maintenance. As I mentioned, we need a simple wiki to have revision control, and option to upload files.

This is the part that make me wary of Cloud VPS as the hosting environment your data requires. The Cloud VPS project is setup to make it easier for Wikimedians to collaborate on technical projects and share information with each other. It is not a core goal of the project to enable collection, storage, and long term security of sensitive information. That is not to say that we force everyone's data to public, there are certainly "secrets" in many Cloud VPS hosted projects, but typically these "secrets" are in the form of passwords and API access tokens which can be revoked if leaked. Holding data that could cause a human to have legal, financial, or physical safety issues if disclosed is a completely different sort of secret.