enable seat types to restrict themselves, for example, limiting the amount of available roles for a user, third phase: remove the synchronization.
Rather enable seat types to restrict available roles and this should come together with removing synchronisation.
Thanks a lot @lwanko - just to confirm - on the third screenshot you wanted to show the memberships in add-on/project and not in Lukas Wanko/project - correct?
@lwanko got it, thanks. Could we add that field later, if needed?
Hi @grosal, thank you for the clear customer context and questions.
With Restricted access being enabled, new users are still being billed even if they ran out of seats in the subscription.
I believe that with RA enabled, it will not be possible to add new users, if the available billable seats are used. The users already present on the instance, also those that are in overage, won't be blocked or removed though when RA gets enabled. So if the overage is already present, enabling RA won't fix that, but it should disallow to add more users when there's no seats left.
Does the Restricted Access feature (which triggers Minimal Access assignment) work with OIDC-provisioned users, or only with SCIM/LDAP/SAML?
I undestand that this customer is using GitLab as an identity provider (not consumer). I've read https://docs.gitlab.com/administration/auth/oidc/ but don't see there what "OIDC-provisioned users" would mean - can you tell me how are the users created on GitLab?
I can confirm that when Restricted Access is enabled and no subscription seats are available, the Minimal Access fallback applies specifically to users provisioned through SAML, SCIM, or LDAP. OIDC is not supported with this fallback, but also not sure how it could
Does it mean on Self-Managed Premium:
- Users with no groups or projects = billable
- Users with no assigned roles = billable (same thing)
- Users with Minimal Access role only = non-billable (after this issue's fix in 18.9)
That's all correct.
how should we prevent billing overages when users are provisioned via OIDC
Customer could add users to a group with a Minimal Access role.
@paulobarros please review and correct/add if needed.
@grosal hope that helps and happy to talk more or chat with the customer directly.
The text should be the same as in other locations.
OK, so we should have RA warning at SCIM config entry points that @karichards pointed to here.
Sounds good, @lwanko @paulobarros ?
@mdischner thank you for raising this! I'm not working on this part of the Product, so tagging @gabrielengel_gl who's PM for Runners.
@lwanko this field is linked to the state of the Zuora field, correct? It needs to be in ee/lib/gitlab_subscriptions/api/entities/internal/gitlab_subscription.rb, as this is internal endpoint and Jason's question is if it should be exposed also in ee/lib/api/entities/gitlab_subscription.rb, as this is customer facing endpoint - did I get it right?
I think it does add value
What value does it add for user, in your view?
@jagood what problem do you see in adding this field to user facing endpoint?
@lwanko we don't plan to disable RA by default for anyone - only to possibly enable it by default (force enable it) for chosen users/cohorts.
@karichards thank you for videos. I'm two mind about it too @lwanko. I've asked Duo, it said we should consider warning for:
@paulobarros what's your opinion?