When SSO is enforced, error not shown when inviting a user to a group that will increase the number of seats

I tried to invite a user to a group on GitLab.com, which gave me the message about needing additional seats (e.g. You are about to incur additional charges). If I click the Continue button to proceed, nothing seems to happen.

Going into the developer tools of the browser I can see a POST request being made to https://gitlab.com/api/v4/groups/<group-id>/invitations which returns a 201. The response payload however indicates an error:

{"message":{"<USERNAME>":"The member's email address is not allowed for this group. Check with your administrator."},"status":"error"}

UPD: Test on 28-04-2025 shows 500 error returned as a response.

This error is not shown in the UI and the UI just looks unresponsive. Seems to be a front-end issue.

Steps to reproduce:

  1. Create a new GitLab group.
  2. Purchase a SaaS premium or Ultimate subscription for the group with 2 seats. (Note: If you are purchasing the subscription directly from Zuora UI then ensure that Seat reconciliation field is enabled since it is needed to trigger the overage modal).
  3. Ensure that zsim is running so that the subscription changes are reflected from Zuora -> CustomersDot -> GDK. Open the group billing page (/groups/<group-path>/-/billings) to confirm that the purchased plan is reflecting there. If it does not reflect, run the script below to sync CustomersDot and GDK (ensure zsim has run the callout for this order so that it is present in CustomersDot local).
order = Order.find(id)
Gitlab::Namespaces::UpdatePlanInfoService.new(order, force_sync: true).execute
  1. Go to the group's manage members page - /groups/test-group-37/-/group_members and add 1 member. Member should be successfully added.
  2. Now go to the settings page for the group and under Permissions and group features section find the setting Restrict membership by email domain. Enter domain to restrict as gitlab.com and click Save changes button.

image

  1. Go back to group's manage members page - /groups/test-group-37/-/group_members and add a member through email id as test@gmail.com. Overage popup should appear since we already have 2 members (which is the number of users purchased for the subscription) and we are trying to add 3rd member.
  2. In the overage popup click Continue. No error is shown.

Reason

In !117473 (merged), we added a try-catch to capture and display the error to the user. However, in this scenario i.e. when the domain restriction fails the API does not return an error but rather 201 with status: error attribute (see screenshot below). Since 201 is considered successful status, it doesn't get captured in the catch block.

image

image

Proposal

In the success block when status: error is received, we need to display the error message. This is already being handled by calling showError and setting invalidMembers in that method. If invalidMembers is set then we display the error alert.

However, the problem is that we display 2 slots in the modal - first with the invite members form and the error alert mentioned above and second with the overage message. When invalidMembers is set, we need to show the first slot since that is the slot which has the error alert. Currently we are not showing the first slot when the error occurs which is why the error is not being displayed - basically the error alert is created in the DOM but just not displayed since we are not switching to the correct slot.

To fix this we could pass a new prop hasErrorDuringInvite as a prop to InviteModalBase and it will be passed the value of hasInvalidMembers from InviteMembersModal. Then in showOverageModal computed in InviteModalBase component add a check to return false if hasErrorDuringInvite is true - that is we do not show the overage modal if there are any errors during the invite which will automatically transition us to the first slot to display the invite members form with the error alert.

During implementation we could also revisit why we are returning 201 in the API for such cases. This might be a convention we are using across but would be good to understand the reason for this.

Actual result

Nothing happens

UPD: The user is added without showing the notification for overages

Expected result

Error from the API response is shown

Possible fix

Related MRs:

Edited by 🤖 GitLab Bot 🤖