mike.lifeguard+bugs wrote:

Clarified summary by adding " to API"

Changing product/component to MediaWiki extensions/Central Auth since this is an issue with the extension and not MediaWiki

matthew.britton wrote:

Making this more general. There needs to be at minimum read-only API access to CentralAuth's public data, that is:

1. List of global groups, and their associated rights. (Analogous to Special:GlobalGroupPermissions)
2. Global user list, most importantly, the users in a particular group. (Analogous to Special:GlobalUsers)
3. Global logs -- blocks, group membership changes, and global account locking/hiding. (Analogous to Special:Log/gblblock etc.)
4. List of wiki sets, and the wikis in each. (Whatever the stewards see on Special:EditWikiSets, without the editing)

Currently only 3) is available, by virtue of integration with the standard logs.

4. currently seems to be completely hidden from public view, something that I see absolutely no reason for. I guess I'll have to address that separately and be ignored as usual.

Concievably there could also be write-mode modules for these things but I think the stewards can manage without that.

(In reply to comment #3)

Making this more general. There needs to be at minimum read-only API access to
CentralAuth's public data, that is:

1. List of global groups, and their associated rights. (Analogous to

Special:GlobalGroupPermissions)

Would be nice. We also don't have a module for Special:Listgrouprights (the local equivalent), that would be nice to have too (in core, of course).

2. Global user list, most importantly, the users in a particular group.

(Analogous to Special:GlobalUsers)

Makes perfect sense.

3. Global logs -- blocks, group membership changes, and global account

locking/hiding. (Analogous to Special:Log/gblblock etc.)

As you said, this is already available.

4. List of wiki sets, and the wikis in each. (Whatever the stewards see on

Special:EditWikiSets, without the editing)

Sounds reasonable; we would need to confirm that this data can indeed be made public, and it'd also be nice to just go ahead and expose it in the UI as well.

Concievably there could also be write-mode modules for these things but I think
the stewards can manage without that.

Write modules would be of very limited use: there's not many users with the right permissions, and I don't see why bots would want, need or even be allowed to modify stuff here.

mike.lifeguard+bugs wrote:

(In reply to comment #4)

4. List of wiki sets, and the wikis in each. (Whatever the stewards see on

Special:EditWikiSets, without the editing)

Sounds reasonable; we would need to confirm that this data can indeed be made
public, and it'd also be nice to just go ahead and expose it in the UI as well.

I can't think of any reason this shouldn't be available. It isn't through the UI AFAICT - it'd be very useful there as well.

Concievably there could also be write-mode modules for these things but I think
the stewards can manage without that.

Write modules would be of very limited use: there's not many users with the
right permissions, and I don't see why bots would want, need or even be allowed
to modify stuff here.

Actually, locking vandal accounts en masse would be very useful. As would global blocking (some other bug, too lazy to find the number). User scripts currently are required to use screen scraping. Please do provide write access via API.

matthew.britton wrote:

(In reply to comment #5)

(In reply to comment #4)

4. List of wiki sets, and the wikis in each. (Whatever the stewards see on

Special:EditWikiSets, without the editing)

Sounds reasonable; we would need to confirm that this data can indeed be made
public, and it'd also be nice to just go ahead and expose it in the UI as well.

I can't think of any reason this shouldn't be available. It isn't through the
UI AFAICT - it'd be very useful there as well.

OK; as this is somewhat a separate issue I've submitted it as bug 22054.

Concievably there could also be write-mode modules for these things but I think
the stewards can manage without that.

Write modules would be of very limited use: there's not many users with the
right permissions, and I don't see why bots would want, need or even be allowed
to modify stuff here.

Actually, locking vandal accounts en masse would be very useful. As would
global blocking (some other bug, too lazy to find the number). User scripts
currently are required to use screen scraping. Please do provide write access
via API.

I'm with Roan on this one, hence why I only said "concievably". Not sure Brion et al. would approve of exposing steward functions in this way, either.

(In reply to comment #4)

Write modules would be of very limited use: there's not many users with the
right permissions, and I don't see why bots would want, need or even be allowed
to modify stuff here.

At least two steward bots (using stewbot) already access CentralAuth, along with JavaScript run by several stewards. Not creating an API doesn't prevent them from doing so; it just makes things more likely to break, more tightly coupled to the form layout, and more difficult to maintain.

For example, this is the rewrite that was needed in stewbot to interact with the overhauled Special:CentralAuth form: < http://github.com/Pathoschild/stewbot/commit/d6ab51587bee8a472185d0980044320c98085df9 >.

matthew.britton wrote:

(In reply to comment #7)

At least two steward bots (using stewbot) already access CentralAuth, along
with JavaScript run by several stewards.

The rate of CentralAuth actions is on the order of 50 every 24 hours.

I'm not convinced it's necessary to run bots for such a small workload. More importantly, I'm not at all convinced it's wise to trust any sort of unsupervised process with actions that have no transparency or oversight.

If an adminbot goes mad anyone can look at the log and see that's it's deleting the wrong pages, or blocking the wrong users, and take action. If a steward-bot goes mad... "(log action removed) (crosswiki abuse)". It's an awkward enough situation trusting stewards not to screw up things we can't double-check. Stewards were chosen though a touch election process because these things are important, not to sit and let a bot do them.

(In reply to comment #8)

Stewards were chosen though a touch election process because these things are
important, not to sit and let a bot do them.

The bot doesn't act on its own, it simply automates the tedious steps when prompted by its operator. Consider the normal flow to lock and hide an account, and review its local edits:

1. Copy vandal username from RC feed.
2. Open or move focus to browser.
3. Navigate to Special:CentralAuth.
4. Set focus in name textbox.
5. Paste vandal username.
6. Press 'Enter'.
7. Wait for page to load.
8. Scroll down page.
9. Click "Account is locked from editing".
10. Click "Account is hidden from public lists".
11. Click "Other reason" menu.
12. Click "crosswiki abuse" option.
13. Click the "Set status" button.
14. CTRL + Click the edit link for every local account that has edits.
15. For each account, make sure their edits have been reverted and page creations deleted.

The vandal has created five new accounts in the time it took you to do this. Set focus to RC feed, start over from step 1, and work faster next time!

Compare this to a semi-automated flow:

1. Copy vandal username.
2. Type "!stabhide " and CTRL + V to paste vandal username.
3. Press 'Enter'.

You're done. The vandal probably hasn't even had time to edit yet, and if he has the bot will notify you if he has unreverted edits on any wiki. Another bot will notify #wikimedia-stewards that you locked and hid an account.

matthew.britton wrote:

(In reply to comment #9)

(In reply to comment #8)

Stewards were chosen though a touch election process because these things are
important, not to sit and let a bot do them.

The bot doesn't act on its own, it simply automates the tedious steps when
prompted by its operator. Consider the normal flow to lock and hide an account,
and review its local edits:

1. Copy vandal username from RC feed.
2. Open or move focus to browser.
3. Navigate to Special:CentralAuth.
4. Set focus in name textbox.
5. Paste vandal username.
6. Press 'Enter'.
7. Wait for page to load.
8. Scroll down page.
9. Click "Account is locked from editing".
10. Click "Account is hidden from public lists".
11. Click "Other reason" menu.
12. Click "crosswiki abuse" option.
13. Click the "Set status" button.
14. CTRL + Click the edit link for every local account that has edits.
15. For each account, make sure their edits have been reverted and page

creations deleted.
The vandal has created five new accounts in the time it took you to do this.
Set focus to RC feed, start over from step 1, and work faster next time!

Apologies, I didn't realise global blocking was so badly integrated. Guess that's a valid use case (although a UI-based user script could probably do the same thing).

Compare this to a semi-automated flow:

1. Copy vandal username.
2. Type "!stabhide " and CTRL + V to paste vandal username.
3. Press 'Enter'.

You're done. The vandal probably hasn't even had time to edit yet, and if he
has the bot will notify you if he has unreverted edits on any wiki. Another bot
will notify #wikimedia-stewards that you locked and hid an account.

1a. accidentially get "Jimbo Wales" on your clipboard somehow :)

(In reply to comment #10)

1a. accidentially get "Jimbo Wales" on your clipboard somehow :)

No steward should hit 'Enter' without checking what they pasted, CentralAuth actions are easily reversible, and they are logged and reported so other stewards will notice even if the locking steward doesn't. It's fairly common for a steward to poke another about an action, and I'm sure locking Jimbo Wales would merit a few raised eyebrows.

The bot actually reduces errors because it's so simple to use and verify before hitting 'Enter'. ("!lock Jimbo Wales" — hmm.) The regular flow I described above is so tortuous that stewards in a hurry occasionally make a mistake, like accidentally unlocking a vandal.

The only CentralAuth action that's irreversible is deleting accounts, which the bot deliberately doesn't support.

matthew.britton wrote:

(In reply to comment #11)

The regular flow I described
above is so tortuous that stewards in a hurry occasionally make a mistake, like
accidentally unlocking a vandal.

Perhaps stewards should have links to the "centralauth" form appearing in the UI where administrators have "block" links. Seems that would skip steps 1-6 at least.

The vandal has created five new accounts in the time it took you to do this.

I thought there were global IP address blocks now? Or are they not used on vandals?

mike.lifeguard+bugs wrote:

(In reply to comment #12)

I thought there were global IP address blocks now? Or are they not used on
vandals?

They are, but it is not always practical or appropriate to do so.

Note that this still requires adding checkuser rights, going to the local wiki, running the checkuser, and coming back to Meta to apply the block.

matthew.britton wrote:

(In reply to comment #13)

(In reply to comment #12)

I thought there were global IP address blocks now? Or are they not used on
vandals?

They are, but it is not always practical or appropriate to do so.

Note that this still requires adding checkuser rights, going to the local wiki,
running the checkuser, and coming back to Meta to apply the block.

Hmm, that seems like a lot of hassle. Perhaps some sort of "global autoblock" functionality should be added?

mike.lifeguard+bugs wrote:

*** Bug 17235 has been marked as a duplicate of this bug. ***

(In reply to comment #4)

4. List of wiki sets, and the wikis in each. (Whatever the stewards see on

Special:EditWikiSets, without the editing)

Sounds reasonable; we would need to confirm that this data can indeed be made
public, and it'd also be nice to just go ahead and expose it in the UI as well.

It was meant to be, but it wasn't made that way (UI wise at least), But afaik that has been fixed and should be in the 1.17 branch.

I don't know what [[Special:EditWikiSets]] is since it's permission only from top to bottom.
But I know Sitematrix seperates sites in sets by language and by project. Although the query can't filter it, the attributes do show it.

(In reply to comment #17)

I don't know what [[Special:EditWikiSets]] is since it's permission only from
top to bottom.

WikiSets are now in a public UI @ [[m:Special:WikiSets]].

I'm marking this as easy. At the least the read parts shouldn't be difficult. I don't think it should be too difficult to implement most of this. There's already a bit of API work inside the extension and a lot of this can be modeled after the core modules.

To recap, as I understand this bug, we're looking for an API equivalent for:

• [[m:Special:GlobalGroupPermissions]];
• [[m:Special:GlobalUsers]]; and
• [[m:Special:WikiSets]].

Let's limit this bug to read-only access to this information. The write parts should be split out into separate bugs, as necessary. This helps with prioritization, honestly. Read access is important for everyone; write access is only important for stewards. Splitting the bugs out a bit will also make things simpler and clearer (saner).

Add a new patch for an api that could used like [[m:Special:GlobalUsers]]: https://gerrit.wikimedia.org/r/#/c/23177/

Add a new patch for an api that could used like [[m:Special:WikiSets]]: https://gerrit.wikimedia.org/r/#/c/23240/

Looks like Jan forgot to mention Gerrit change 25750 for getting a list of global groups

Change 23177 merged by jenkins-bot:
(bug 16860) Add api for getting all global user

https://gerrit.wikimedia.org/r/23177

Looks like this is done now.

I agree that this bug is properly resolved, but I'm not completely sure that everything discussed in comment 19 has been implemented yet. I'll leave this to someone else to figure out, though.

It's been nearly a while since I looked at this bug and I consequently got a little confused.

(In reply to comment #19)

To recap, as I understand this bug, we're looking for an API equivalent for:

• [[m:Special:GlobalGroupPermissions]]; [Gerrit changeset 25750]
• [[m:Special:GlobalUsers]]; and [Gerrit changeset 23177]
• [[m:Special:WikiSets]]. [Gerrit changeset 23240]

I believe all the read API modules are indeed now completely covered.

The write modules (mentioned in comment 3, comment 4, comment 5, comment 6, comment 7, comment 8, comment 9, and comment 10) are outside the scope of this bug, but I have no idea what their status is (they may or may not have Bugzilla bugs, they may or may not have already been implemented).

(In reply to comment #19)

Let's limit this bug to read-only access to this information. The write parts
should be split out into separate bugs, as necessary.

This was the piece (the write modules) that I'm not sure ever got done.

(In reply to MZMcBride from comment #26)

(In reply to comment #19)

Let's limit this bug to read-only access to this information. The write parts
should be split out into separate bugs, as necessary.

This was the piece (the write modules) that I'm not sure ever got done.

I don't think they did. I filed bug 71495 for changing a user's global groups.