We can resolve this for now as it's on Trixie.

OK thanks for the context; I did not make any changes recently so was not sure what happened. I thought I was on Bullseye all this time.

Are you still trying to move the project into Toolforge? If so, that is probably the best action right now

Given that an in-place upgrade was apparently performed for my VM (T433570), I'm now pretty confused. Is it that VMs that are not already migrated will be force-updated? I don't see this described anywhere in the documentation.

In-place upgrade @Andrew? Sorry, why was the VM upgraded without asking me? Is the data safe?

Let's try increasing it to 8 - 10 GB for now. If issues happen we'll see.

Yes that'd be helpful.

If we try 8 - 10 GB instead, (from your experience) is it still likely to be difficult to get the job scheduled?

The problem is deciding which link to use from the bot's point of view. For example, someone wanting to reapply for a local patroller right would usually apply at the administrator noticeboard or village pump, where if it's for admin, it'll usually be in a dedicated RfA page. Or do you have a different idea in mind?

Unless someone is willing to run the event on my behalf (and I don't expect anyone to), the Iran war has meant that I will not be able to show up for the conference.

@neriah Sorry seeing this only now. I've been thinking about the impact of this feature. My feeling is that

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.