Individual cannot be added as approver after their group is removed from project settings

Summary

When configuring "merge request approvals" in a project's settings, you can specify a group. You can also select "Can override approvers and approvals required per merge request". This is effectively specifying a default group of approvers. When you create a new merge request, the members of that group are explicitly omitted from the approvers input box, because they're already approvers via the group.

What doesn't make sense is they continue to be omitted even if you remove the default group. This means in practice, if you have a default group of approvers, there is no way to override them with individual members of that group.

Steps to reproduce

1. Edit a project's settings
2. Enable merge request approvals
3. Add the project's group as a list of approvers
4. Check "Can override approvers and approvals required per merge request"
5. Save
6. Create a new merge requests
7. Remove the project's group from the approvers
8. Type in the approvers textbox a member of that group

Example Project

gitlab-org-gitlab-ee-issue/gitlab-ee-issue!1

I've added Ashley as a group member of gitlab-org-gitlab-ee-issue, and the gitlab-org-gitlab-ee-issue group to the project's merge request approvers.

What is the current bug behavior?

The member is omitted from the textbox even after the group is removed.

What is the expected correct behavior?

That member should be included in the textbox after the group is removed.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:         Ubuntu 16.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.3.3p222
Gem Version:    2.6.6
Bundler Version:1.13.7
Rake Version:   12.0.0
Redis Version:  3.2.5
Git Version:    2.13.5
Sidekiq Version:5.0.4
Go Version:     unknown
GitLab information
Version:        9.5.4-ee
Revision:       08803f6
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
DB Version:     9.6.3
URL:            https://gitlab.datto.net
HTTP Clone URL: https://gitlab.datto.net/some-group/some-project.git
SSH Clone URL:  git@gitlab.datto.net:some-group/some-project.git
Elasticsearch:  yes
Geo:            no
Using LDAP:     yes
Using Omniauth: no
GitLab Shell
Version:        5.8.0
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

Checking GitLab Shell ...
GitLab Shell version >= 5.8.0 ? ... OK (5.8.0)

Repo base directory exists?

default... yes

Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
5/2 ... ok
8/4 ... ok
9/5 ... ok
12/9 ... ok
8/12 ... ok
28/13 ... ok
36/16 ... ok
20/20 ... ok
20/21 ... ok
12/22 ... ok
11/23 ... ok
22/24 ... ok
29/25 ... ok
43/26 ... ok
14/29 ... ok
32/30 ... ok
54/31 ... ok
11/33 ... ok
5/34 ... ok
5/35 ... ok
29/36 ... ok
13/37 ... ok
5/39 ... ok
16/40 ... ok
60/41 ... ok
19/43 ... ok
16/44 ... ok
74/45 ... ok
27/46 ... ok
25/47 ... repository is empty
81/48 ... ok
12/49 ... ok
68/51 ... ok
8/53 ... ok
18/54 ... ok
18/55 ... ok
54/57 ... ok
88/58 ... ok
76/59 ... ok
83/60 ... ok
37/61 ... ok
3/62 ... ok
20/63 ... ok
34/64 ... ok
34/65 ... ok
93/66 ... ok
94/67 ... ok
59/68 ... ok
99/70 ... ok
93/71 ... ok
37/73 ... ok
65/74 ... ok
3/75 ... ok
100/76 ... ok
9/77 ... ok
9/78 ... ok
9/79 ... ok
9/80 ... ok
9/81 ... ok
9/82 ... ok
9/83 ... ok
9/84 ... ok
9/85 ... ok
9/86 ... ok
9/87 ... ok
9/89 ... ok
9/90 ... ok
9/91 ... ok
9/92 ... ok
9/93 ... ok
9/94 ... ok
9/96 ... ok
9/97 ... ok
9/98 ... ok
9/99 ... ok
9/100 ... ok
9/102 ... ok
9/104 ... ok
9/105 ... ok
9/107 ... ok
9/108 ... ok
9/109 ... ok
9/110 ... ok
9/111 ... ok
9/112 ... ok
9/113 ... ok
9/114 ... ok
9/115 ... ok
9/116 ... ok
9/117 ... ok
90/118 ... ok
34/119 ... ok
47/120 ... ok
96/121 ... ok
113/122 ... ok
95/125 ... ok
114/127 ... ok
114/128 ... ok
114/129 ... ok
114/134 ... ok
114/135 ... ok
114/136 ... ok
114/137 ... ok
114/138 ... ok
114/139 ... ok
114/140 ... ok
114/142 ... ok
34/143 ... ok
34/144 ... ok
34/145 ... ok
2/146 ... ok
34/147 ... ok
37/148 ... ok
2/149 ... ok
98/150 ... repository is empty
37/151 ... repository is empty
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Reply by email ...
Reply by email is disabled in config/gitlab.yml
Checking Reply by email ... Finished
Checking LDAP ...
Server: ldapmain
not verifying SSL hostname of LDAPS server 'SANITIZED'
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
... SANITIZED ...
Checking LDAP ... Finished
Checking GitLab ...
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: ...
5/2 ... yes
8/4 ... yes
9/5 ... yes
12/9 ... yes
8/12 ... yes
28/13 ... yes
36/16 ... yes
20/20 ... yes
20/21 ... yes
12/22 ... yes
11/23 ... yes
22/24 ... yes
29/25 ... yes
43/26 ... yes
14/29 ... yes
32/30 ... yes
54/31 ... yes
11/33 ... yes
5/34 ... yes
5/35 ... yes
29/36 ... yes
13/37 ... yes
5/39 ... yes
16/40 ... yes
60/41 ... yes
19/43 ... yes
16/44 ... yes
74/45 ... yes
27/46 ... yes
25/47 ... yes
81/48 ... yes
12/49 ... yes
68/51 ... yes
8/53 ... yes
18/54 ... yes
18/55 ... yes
54/57 ... yes
88/58 ... yes
76/59 ... yes
83/60 ... yes
37/61 ... yes
3/62 ... yes
20/63 ... yes
34/64 ... yes
34/65 ... yes
93/66 ... yes
94/67 ... yes
59/68 ... yes

99/70 ... yes

93/71 ... yes

37/73 ... yes

65/74 ... yes
3/75 ... yes
100/76 ... yes
9/77 ... yes
9/78 ... yes
9/79 ... yes
9/80 ... yes
9/81 ... yes
9/82 ... yes
9/83 ... yes
9/84 ... yes
9/85 ... yes
9/86 ... yes
9/87 ... yes
9/89 ... yes
9/90 ... yes
9/91 ... yes
9/92 ... yes
9/93 ... yes
9/94 ... yes
9/96 ... yes
9/97 ... yes
9/98 ... yes
9/99 ... yes
9/100 ... yes
9/102 ... yes
9/104 ... yes
9/105 ... yes
9/107 ... yes
9/108 ... yes
9/109 ... yes
9/110 ... yes
9/111 ... yes
9/112 ... yes
9/113 ... yes
9/114 ... yes
9/115 ... yes
9/116 ... yes
9/117 ... yes
90/118 ... yes
34/119 ... yes
47/120 ... yes
96/121 ... yes
113/122 ... yes
95/125 ... yes
114/127 ... yes
114/128 ... yes
114/129 ... yes
114/134 ... yes
114/135 ... yes
114/136 ... yes
114/137 ... yes
114/138 ... yes
114/139 ... yes
114/140 ... yes
114/142 ... yes
34/143 ... yes
34/144 ... yes
34/145 ... yes
2/146 ... yes
34/147 ... yes
37/148 ... yes

2/149 ... yes

98/150 ... yes

37/151 ... yes

Redis version >= 2.8.0? ... yes

Ruby version >= 2.3.3 ? ... yes (2.3.3)

Git version >= 2.7.3 ? ... yes (2.13.5)

Active users: ... 95

Elasticsearch version 5.1 - 5.3? ... no (5.5.2)

For more information see:

doc/integration/elasticsearch.md
Checking GitLab ... Finished

Possible fixes

I believe this is the line responsible for the bug:

https://gitlab.com/gitlab-org/gitlab-ee/blob/fd0482d67c65e33e5174f614d5fa84626572120c/app/views/shared/issuable/_approvals.html.haml#L14

I think the issue is that the list of users that are skipped in the approvers dropdown is prepopulated in the haml. Removing the group doesn't update that list.