Skip to content
Snippets Groups Projects

Users with roles lower than Maintainer should not be listed in the `Allowed to deploy` dropdown.

    • Closed Issue created by Vidhya Hariharan @vidhya.h

    Summary

    In Group-level protected environment , adding users with roles lower than Maintainer to allowed to deploy setting silently fails

    Steps to reproduce

    • Navigate to a group , select settings->CI/CD->Protected environments
    • Click on Protect an environment and select the environment tier
    • Under allowed to deploy, select two users with Maintainer & Developer role and click protect
    • Deployment rules of the protected environment will list only the maintainer & not the developer.

    This is because the code indicates that only owners and maintainers are allowed to deploy in group-level config.

    Example Project

    What is the current bug behavior?

    Users with roles lower than Maintainer are listed in the Allowed to deploy dropdown.

    What is the expected correct behavior?

    Users with roles lower than Maintainer should not be listed in the Allowed to deploy dropdown.

    Relevant logs and/or screenshots

    Output of checks

    Results of GitLab environment info

    Expand for output related to GitLab environment info 
    (For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

    Results of GitLab application Check

    Expand for output related to the GitLab application check 
    (For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
    

    (For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
    

    (we will only investigate if the tests are passing)

    Implementation

    • Modify EnvironmentDropdownService to:
      • Accept the relevant project or group (either as as an argument to #roles_hash, or setting it in an initializer for the service).
      • Exclude Gitlab::Access::DEVELOPER from the returned list if the passed object is a group.
    • Modify the project and group calling locations to pass the project/group to the service.
    Edited by Tiger Watson

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply