get(admin|bots)/batchgetusers should fully update the list of users

[MarcoAurelioWM]

Apologies if this already happens.

The getadmins/getbots/batchgetusers commands should fully upgrade the list of admins, bots or admins and bots. That means not only adding missing people to the list, but also removing people no longer in those groups.

Example: we have a wiki with these sysops A, B, and C. B is desysopped and D is promoted to sysop; the list should contain in the next upgrade A, C and D, and B should be removed.

Like I said I am not sure if this is already happening, but if it is not, it'd be good if we could do it so we can have reliable list of users.

Thank you.

[Krinkle]

@MarcoAurelioWM Thanks for reporting. I understand your example and I agree that we should aim to make that possible.

The behaviour you describe is not (yet) the case right now. The CVN get* functions only add users, not remove.

I will accept this feature request, but I am unsure how to do it.

There is more than 1 reason for a user to be on a whitelist. For example, a user can be on the whitelist because they are a good editor without being an admin, or they can be on the whitelist because they are an admin on a different wiki.

Therefore, the getadmins test.wikipedia command should not remove all users from the whitelist that are not currently admin on test.wikipedia. It is more difficult.

The CVN database does have a "reason" field, but it can only contain one value at a time. This means when I run getadmins mediawiki.wikipedia and then getadmins commons.wikimedia. It will try to add me ("Krinkle") twice. Once for admin on mediawiki.org, and the latter overwrites it with reason "admin on commons.wikimedia.org".

It looks like we will need to support multiple reasons, which is a big technical change that requires a lot of (volunteer) time and knowledge of databases and C#. Even then, it is possible that a user can stop being an admin without being a bad user and still be trusted.

For example, if you are initially on the whitelist automatically as an admin, then I would not add you a second time as a good editor. But, if you discontinue being an admin, I would want you to stay on the whitelist. I would not expect you to be removed by default.

Perhaps it should keep the getadmins function unchanged, and instead recognise when "desysop" happens, and then react by removing from whitelist. That would be simpler and also means you don't have to do the getadmins command. It would happen automatically.

[MarcoAurelioWM]

Thank you, @Krinkle, for your detailed reply.

I was assuming that there was one admin and bot list per project (I guess the p=<project> parameter made me think so; the white/blacklist don't require a p= parameter so I guess they're indeed global).

I agree that a desysop per se should not harm the user. It can be due to inactivity or resignation (which usually doesn't mean the user is now "bad" and thus can still be kept/moved to the whitelist) or due to a desysop process (which might warrant that at least said user for said project should not even be in the whitelist). However if we have a single database for every project (or the DB just accepts one reason value) then indeed looks a bit more complicated.

Feel free to decline if you think this is an enormous ammount of job that cannot be accomplished at this moment or in the near future. The least I want is to give you people more complicated work. Although I still think it'd be a good idea. Maybe the DBs could have some sort of new values like project. That said, my MySQL knowledge is rather scarce so apologies if I've said a silly thing.

Thank you.

[Krinkle]

I was wrong. The adminlist and whitelist as separate things. It is true that there is only one reason field, and no per-project whitelist. But, the adminlist is always per-project. A username can be on multiple per-project adminlists, and on the (global) whitelist, for example.

CVNBot14> Krinkle is on commons.wikimedia admin list, added by CVNBot until the end of time ("Auto-download from wiki") and on global whitelist, added by Krinkle until the end of time ("No reason given")

This means it should be fairly easy to remove outdated entries from the admin list. And, since the adminlist has precedence over the whitelist when it comes to filtering and display logic, this could actually change behaviour and be of some use.

However, we would probaly want to first make it so that admins are automatically (also) added to the global whitelist, so that when they are later removed, they at least stay on the general medium filter of good editors unless someone manually removes them there as well. But, at least they would (correctly) no longer be reported by the bot as an "Admin", and no longer subject to the filtering logic applied to admins.

[Krinkle]

I'll decline this per the above. Keeping them on the wl/al respectively seems fine. I'd actually be in favour of merging those two lists.