### Summary In a situation where a group is invited to another group, and given the permissions of a custom role with minimal access as the 'base role', the following error will be returned to the UI: `group_access does not have a valid value`. Example:  ### Steps to reproduce 1. Create a structure such as: group: `customer`, group: `customer/policies/team1`. 2. At the instance or group level, create a custom role with Minimal Access as the base role. Enable applicable additional permissions, such as being able to view and manage compliance frameworks. 3. At the top-level group, `customer`, try to invite `customer/policies/team1` with the minimal access custom role you defined. The error will be returned. ### What is the current *bug* behavior? As noted, while we provide the option of using minimal access as a base role, there are parts of the code that do not handle this correctly. The call the UI makes is within our API. Here's an example POST request that gets made: ```json "params": [ { "key": "group_access", "value": 5 // minimal access = 5 in the code }, { "key": "group_id", "value": 104 }, { "key": "member_role_id", "value": 4 } ], "path": "/api/v4/groups/102/share", ``` Based on the [`lib/api/groups.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/api/groups.rb?ref_type=heads#L664), file, there is a limit on what values are accepted, here: ```rb values: Gitlab::Access.all_values ``` On a regular GitLab instance, this does NOT include minimal access: ```rb [1] pry(main)> Gitlab::Access.all_values => [10, 15, 20, 30, 40, 50] ``` ### What is the expected *correct* behavior? As minimal access is available as a base role, we should ensure this can be used in all forms, including via group sharing. ### Relevant logs and/or screenshots |Before|After, with a 'fix'| |--|--| ||| In my example, I can confirm that a user with minimal access can perform the tasks with the permissions assigned with my quick workaround (such as viewing and managing compliance frameworks), but all other minimal access visibility will apply: |Image|Description| |--|--| ||(As `root` user): As seen by the group owner, there is a "super secret project", we only want select team members to know about| ||(As `team member` user): A team member, part of `customer/policies/team1`, has this custom role permissions on the top-level group. They cannot see the secret project| ||(As `team member` user): The user has the ability to view and manage compliance frameworks on the top-level group| ### Possible fixes As a very basic proof-of-concept test, I modified the following two files: ```diff diff --git a/app/models/group_group_link.rb b/app/models/group_group_link.rb index eb956872be70..240dbdeafb26 100644 --- a/app/models/group_group_link.rb +++ b/app/models/group_group_link.rb @@ -10,7 +10,7 @@ class GroupGroupLink < ApplicationRecord validates :shared_group_id, uniqueness: { scope: [:shared_with_group_id], message: N_('The group has already been shared with this group') } validates :shared_with_group, presence: true - validates :group_access, inclusion: { in: Gitlab::Access.all_values }, presence: true + validates :group_access, inclusion: { in: Gitlab::Access.values_with_minimal_access }, presence: true scope :guests, -> { where(group_access: Gitlab::Access::GUEST) } scope :non_guests, -> { where('group_group_links.group_access > ?', Gitlab::Access::GUEST) } diff --git a/lib/api/groups.rb b/lib/api/groups.rb index b96df3c60e79..cbada10004b9 100644 --- a/lib/api/groups.rb +++ b/lib/api/groups.rb @@ -661,7 +661,7 @@ def check_query_limit; end end params do requires :group_id, type: Integer, desc: 'The ID of the group to share' - requires :group_access, type: Integer, values: Gitlab::Access.all_values, desc: 'The group access level' + requires :group_access, type: Integer, values: Gitlab::Access.values_with_minimal_access, desc: 'The group access level' optional :expires_at, type: Date, desc: 'Share expiration date' optional :member_role_id, type: Integer, desc: 'The ID of the Member Role to be assigned to the group' end ``` By allowing the minimal access value of `5` to be permitted in the array, this has worked. The actual fix will likely need to be implemented and done via an override as minimal access is an `EE` feature. <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->