I think the "actions": [] in the response is correct. The API request is made by an authclient, not by a user. And authclients can't take any further actions against the memberships they created: for example they can't delete or edit the memberships. For example this:

$ httpx http://localhost:5000/api/groups/{groupid}/members/acct:devdata_user@localhost --method DELETE --auth {client_id} {client_secret}

...will get a 404 Not Found response. As will this:

$ httpx http://localhost:5000/api/groups/{groupid}/members/acct:devdata_user@localhost --method PATCH --json '{"roles": ["member"]}' --auth {client_id} {client_secret}

...but both requests would succeed if they were authenticated with devdata_admin's API key rather than with an authclient.

The reason is that the MEMBER_ADD permission just requires an authclient whose authority matches the group's (implementation of predicate function). Whereas MEMBER_REMOVE and MEMBER_EDIT require an authenticated user who has permission (group_member_remove() predicate, group_member_edit() predicate).

This is in the API docs too. Add member is documented as requiring authclient authentication. Whereas delete member is documented as requiring an API key. (Edit-member isn't documented yet.)

The API for getting a list of the group's members will do the same thing if you call it with an authclient:

$ httpx http://localhost:5000/api/groups/{groupid}/members --method GET --auth {client_id} {client_secret}

...this will return "actions": [] for every membership in the group because the authclient isn't permitted to take any of the actions against any of the memberships.

Maybe we'll want to do something about this one day--the fact that the add-member API only works for authclients not for users, get-group-members works with either, and edit-member and remove-member only work for users.

Removed the docs changes from this PR, gonna do them in #9210 instead.