Make endpoint `GET /group/{groupId}` accessible through registered service accounts and return emails.

[JamesTLopez]

pcgl-authz/app/src/authz_openapi.yaml

Line 41 in 9f46c36

/group/{group_id}:

• Path: /group/{group_id}
• Method: GET

Description

The /group/{group_id} endpoint currently requires bearer authentication and is restricted to user accounts only.

Issue

• Can we have this endpoint to be accessible to registered services to enable service-to-service communication?
• It seems this endpoint only returns user_id's when queried, can we append the user email as well to the response?

[joneubank]

Adding context:

• DACO service needs to send emails to DAC Members and DAC Chairs to notify about required actions and send other reminders
• The DAC Members and DAC Chairs belong to CoManage groups and this GET /group/{group_id} endpoint is able to provide this user information
• At the moment, only an Admin user can access this endpoint, it requires a user Bearer token. Our intention is to update AuthZ so that the DACO service can use its service token to access this resource, so that it can send emails whenever necessary based on its own internal scheduling logic
• We also discussed with @daisieh that this service could be updated to return emails as well as user IDs in the response. We are able to retrieve emails from userIds already, it just requires an additional request to AuthZ per user ID. This changewould make the required information (list of member user email addresses) available in a single request to AuthZ.

[kcranston]

If I understand the workflow here, the DACO service is collecting the group membership of the DAC Members and DAC chairs when something happens in the DACO service (e.g. a new application is submitted). In this case, the authenticated user (the user submitting the application) doesn't have permission to get group membership, so this has to be done by the service. is this correct?

In addition, you want the response to the group endpoint to change to include the email address(es) without having to call the user/{user_id} endpoint to get email addresses for each person in the groups?

[Buwujiu]

This does not block DACO launch, DAC users can still login to the portal to review applications.

[daisieh]

Note: implementing email addresses in the group endpoint will still likely return multiple registered emails per user, as noted in discussions. There isn't an obvious way to determine the "best" email address to use in that case.