Can't add user to subgroup if they already have inherited permissions

Summary

When a user is a member of a group, their permission is inherited into its subgroups, and it isn't possible to explicitly define on any subgroup a permission that is less than or equal to the inherited one.

This might be because the explicitly-defined subgroup permission would be overridden by the inherited one, so GitLab considers it redundant or unnecessary. However, permissions defined directly on a subgroup are important for certain actions, such as moving groups/projects into that subgroup. They can also be important in cases where we know that the inherited permission will be modified or removed in the future, at which time overridden subgroup permissions will no longer be overridden.

Steps to reproduce

  1. Add user with Owner permission to a group that has subgroups.
  2. Add same user with Owner permission (or lower) to the subgroup.
  3. UI shows success message, but the explicit permission hasn't actually been added to the subgroup.

Also, a related scenario:

  1. Add user with Developer permission to a subgroup where they don't already have inherited permissions.
  2. Add same user with Owner permission to the subgroup's parent group.
  3. Back on the subgroup, use the permission dropdown menu to increase the user's permission to Owner or Maintainer.
  4. Permission dropdown shows the new selected value, but upon refresh, reverts back to the old value.

What is the current bug behavior?

User permissions can't be set explicitly on a subgroup when the user already has inherited permissions from an ancestor group that are greater than or equal to the explicit permission.

What is the expected correct behavior?

User permissions should assignable explicitly on any group, even if the explicit permission will be overridden by an inherited permission that is greater than or equal to the explicit permission.

Relevant logs and/or screenshots

Here's a group where my user has inherited permissions:

group-permission-1

When I try to add an explicit permission equal to the inherited ones:

group-permission-2

The UI shows success:

group-permission-3

But actually the member list is unchanged:

group-permission-4

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info

sudo gitlab-rake gitlab:env:info

System information
System:         Ubuntu 16.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.5.3p105
Gem Version:    2.7.6
Bundler Version:1.16.6
Rake Version:   12.3.2
Redis Version:  3.2.12
Git Version:    2.18.1
Sidekiq Version:5.2.3
Go Version:     unknown
 
GitLab information
Version:        11.7.0-ee
Revision:       c02f0d4
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
DB Version:     10.5
URL:            https://gitlab.vbp.io
HTTP Clone URL: https://gitlab.vbp.io/some-group/some-project.git
SSH Clone URL:  git@gitlab.vbp.io:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: saml
 
GitLab Shell
Version:        8.4.4
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
Hooks:          /opt/gitlab/embedded/service/gitlab-shell/hooks
Git:            /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

sudo gitlab-rake gitlab:check SANITIZE=true

Checking GitLab subtasks ...
 
Checking GitLab Shell ...
 
GitLab Shell: ... GitLab Shell version >= 8.4.4 ? ... OK (8.4.4)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
 
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
 
Checking GitLab Shell ... Finished
 
Checking Gitaly ...
 
Gitaly: ... default ... OK
 
Checking Gitaly ... Finished
 
Checking Sidekiq ...
 
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
 
Checking Sidekiq ... Finished
 
Checking Incoming Email ...
 
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
 
Checking Incoming Email ... Finished
 
Checking LDAP ...
 
LDAP: ... LDAP is disabled in config/gitlab.yml
 
Checking LDAP ... Finished
 
Checking GitLab App ...
 
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
7/4 ... yes
7/6 ... yes
7/7 ... yes
11/8 ... yes
13/9 ... yes
14/10 ... yes
14/11 ... yes
13/12 ... yes
87/13 ... yes
16/14 ... yes
16/15 ... yes
17/16 ... yes
19/17 ... yes
19/18 ... yes
14/19 ... yes
23/21 ... yes
23/22 ... yes
22/24 ... yes
26/25 ... yes
22/27 ... yes
22/28 ... yes
22/29 ... yes
32/30 ... yes
32/31 ... yes
34/32 ... yes
36/33 ... yes
36/34 ... yes
37/35 ... yes
39/36 ... yes
22/37 ... yes
40/38 ... yes
11/39 ... yes
11/40 ... yes
11/41 ... yes
22/42 ... yes
26/46 ... yes
41/47 ... yes
41/48 ... yes
41/49 ... yes
41/50 ... yes
41/51 ... yes
11/52 ... yes
42/53 ... yes
42/54 ... yes
43/55 ... yes
25/56 ... yes
44/57 ... yes
45/58 ... yes
42/59 ... yes
48/60 ... yes
48/61 ... yes
48/62 ... yes
48/63 ... yes
48/64 ... yes
28/65 ... yes
51/67 ... yes
51/68 ... yes
51/69 ... yes
51/70 ... yes
51/71 ... yes
51/72 ... yes
51/73 ... yes
51/74 ... yes
11/75 ... yes
52/76 ... yes
54/77 ... yes
45/78 ... yes
45/79 ... yes
45/80 ... yes
45/81 ... yes
45/82 ... yes
45/83 ... yes
45/84 ... yes
22/85 ... yes
52/86 ... yes
52/87 ... yes
52/88 ... yes
52/89 ... yes
52/90 ... yes
56/91 ... yes
56/101 ... yes
56/102 ... yes
56/103 ... yes
56/104 ... yes
56/105 ... yes
54/106 ... yes
54/108 ... yes
59/110 ... yes
59/111 ... yes
59/112 ... yes
59/113 ... yes
59/114 ... yes
59/115 ... yes
59/116 ... yes
60/117 ... yes
60/118 ... yes
60/119 ... yes
60/120 ... yes
60/121 ... yes
60/122 ... yes
63/135 ... yes
63/136 ... yes
63/137 ... yes
63/138 ... yes
36/139 ... yes
69/140 ... yes
69/141 ... yes
22/149 ... yes
70/150 ... yes
54/151 ... yes
71/152 ... yes
71/153 ... yes
63/154 ... yes
73/155 ... yes
73/156 ... yes
73/157 ... yes
72/158 ... yes
72/159 ... yes
72/160 ... yes
72/161 ... yes
72/162 ... yes
72/163 ... yes
72/164 ... yes
88/166 ... yes
26/167 ... yes
22/169 ... yes
22/170 ... yes
19/175 ... yes
73/176 ... yes
26/177 ... yes
42/178 ... yes
81/179 ... yes
32/180 ... yes
81/183 ... yes
80/184 ... yes
28/185 ... yes
89/186 ... yes
90/187 ... yes
80/188 ... yes
89/191 ... yes
91/195 ... yes
89/196 ... yes
89/197 ... yes
94/198 ... yes
22/199 ... yes
22/200 ... yes
22/203 ... yes
93/204 ... yes
93/205 ... yes
73/206 ... yes
106/209 ... yes
106/210 ... yes
106/211 ... yes
99/212 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.5.3)
Git version >= 2.18.0 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 32
Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)
 
Checking GitLab App ... Finished
 

Checking GitLab subtasks ... Finished

Possible fixes

TO DO

Assignee Loading
Time tracking Loading