API method to fetch single group

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Context

The "Provisioning API" has routes that get information about groups:

• GET /ocs/v1.php/cloud/groups gets a list of group ids. Either all, or filtered by search term.
• GET /ocs/v1.php/cloud/groups/details gets a list of groups with details. Either all, or filtered by search term.
• GET /ocs/v1.php/cloud/groups/{groupId} gets a list of usernames in the group.
• GET /ocs/v1.php/cloud/groups/{groupId}/users gets a list of usernames in the group.
• GET /ocs/v1.php/cloud/groups/{groupId}/users/details gets a list of users with details in the group.

Routes that get details provide "id","displayname","usercount","disabled","canAdd","canRemove".
(I am not really sure what half of these do)

Problem

There is no API route that reliably gets one single group.

One could use the search term, but this can always return more results than expected. E.g. searching for "xyz" will find a group "xyz" but it will also find a group "a xyz b".

Also, there is no possibility to only get the id and displayname.
(I checked the database, and id + displayname are the only parts that are stored in the groups table itself.)

Bonus problem

The system allows a group to be named 'details'.
When doing this, /groups/details gets details for all groups, but /groups/details/users gets usernames for the "details" group.

Solution

The natural fit would be to get a single group for GET /ocs/v1.php/cloud/groups/{groupId}.
However, doing this now would be BC-breaking, because this route already delivers usernames.

So the next best thing would be GET /ocs/v1.php/cloud/groups/{groupId}/details.

Also, we could add GET /ocs/v1.php/cloud/groups/{groupId}/displayname to get only the display name.

Start with apps/provisioning_api/appinfo/routes.php and review the existing group routes, especially the /groups/{groupId} and /groups/details paths. Determine the non-breaking endpoint behavior for fetching one group's details or display name, including the conflict with a group named "details". Done means the selected route reliably returns the requested group information without changing the existing usernames route.