Deprecate use of members API for invite modal in favor of invitations API
Problem
Currently when inviting someone to be a member in the invite modal, we make 2 calls to the API
-
/members
with invites that are to current users. -
/invitations
with invites that are to emails(not current users).
Each endpoint responds differently when encountering an error.
This causes downstream issues in response codes and how errors are handled in the response.
-
invitations
endpoint provides a json object with eachemail
being a key in a hash. -
members
endpoint provides a json object with eachuser
being an element of an array.
This isn't sustainable and will only cause more issues when trying to deal with errors in the display and also extending.
Solution
-
Ensure the error responses and status codes are the same when submitting emails or users from the invite modal. - extend the
/invitations
API to handle bothusers
andemails
, deprecating the use of/members
from the invite modal. - see #353008 in case we deprecate a parameter here.
- resolve with !80733 (merged)
- extend the
-
Remove the specific parsing of the members
API from the invite modal error parser- this will need to be a separate MR from the one above due to possible mixed deployments where FE and BE code can be out of sync.
- resolve with !80733 (merged)
-
Improve messaging when attempting to lower an inherited user's access level - see https://gitlab.com/gitlab-org/gitlab/-/issues/247208#note_843335734 - resolve with !80733 (merged)
-
Allow inherited users to be re-invited at a higher role than their current inherited role - will resolve https://gitlab.com/gitlab-org/gitlab/-/issues/247208#note_835103747 - resolve with !80733 (merged)
-
Investigate the possibility of combining the invites from the invite modal into one submission to the /invitations
API.- if it does seem achievable, open a new issue to implement as the final step of completing this issue.
- resolve with !80733 (merged)
Edited by Doug Stull