Changing project visibility from private to internal in a group that is private causes 500 error
Summary
(Locally hosted Gitlab CE 9.5.4)
We have a hierarchy of groups and subgroups as follows:
- Parent Group ABC (visibility: Public)
- Subgroup DEF (visibility: Private)
- Project XYZ (visibility: Private)
- Subgroup DEF (visibility: Private)
As an owner, I attempted to change the visibility of Porject XYZ from private to internal via the projects settings page. It returned an error that said it failed to change the visibility. After this time, the project and ANY of its subpages beneath its path were 100% inaccessible.
Some pages return 500, otheres return 404
- All Overview Pages - 500
- All Repository Pages - 500
- All Issues Pages - 404
- All Merge Requests Pages - 404
- Settings - 500
Example of 500 error in /var/log/gitlab/gitlab-rails/production.log
Started GET "/Parent-Group/Sub-Group/Project" for 10.x.x.x at 2017-09-08 08:56:10 -0500
Processing by ProjectsController#show as HTML
Parameters: {"namespace_id"=>"Parent-Group/Sub-Group/Project", "id"=>"Project"}
Completed 500 Internal Server Error in 47ms (ActiveRecord: 6.7ms)
NoMethodError (undefined method `access_level' for nil:NilClass):
app/policies/project_policy.rb:336:in `feature_available?'
app/policies/project_policy.rb:76:in `block (2 levels) in <class:ProjectPolicy>'
lib/declarative_policy/condition.rb:21:in `instance_eval'
lib/declarative_policy/condition.rb:21:in `compute'
lib/declarative_policy/condition.rb:42:in `block in pass?'
lib/declarative_policy/base.rb:279:in `cache'
lib/declarative_policy/condition.rb:42:in `pass?'
lib/declarative_policy/rule.rb:79:in `pass?'
lib/declarative_policy/step.rb:79:in `pass?'
lib/declarative_policy/runner.rb:97:in `block in run'
lib/declarative_policy/runner.rb:167:in `block in steps_by_score'
lib/declarative_policy/runner.rb:145:in `loop'
lib/declarative_policy/runner.rb:145:in `steps_by_score'
lib/declarative_policy/runner.rb:78:in `run'
lib/declarative_policy/runner.rb:56:in `pass?'
lib/declarative_policy/base.rb:215:in `block in allowed?'
lib/declarative_policy/base.rb:215:in `each'
lib/declarative_policy/base.rb:215:in `all?'
lib/declarative_policy/base.rb:215:in `allowed?'
lib/declarative_policy/base.rb:207:in `can?'
app/models/ability.rb:48:in `allowed?'
app/controllers/application_controller.rb:133:in `can?'
app/controllers/projects_controller.rb:276:in `render_landing_page'
app/controllers/projects_controller.rb:109:in `block (2 levels) in show'
app/controllers/projects_controller.rb:106:in `show'
lib/gitlab/i18n.rb:46:in `with_locale'
lib/gitlab/i18n.rb:52:in `with_user_locale'
app/controllers/application_controller.rb:326:in `set_locale'
lib/gitlab/middleware/multipart.rb:93:in `call'
lib/gitlab/request_profiler/middleware.rb:14:in `call'
lib/gitlab/middleware/go.rb:17:in `call'
lib/gitlab/etag_caching/middleware.rb:11:in `call'
lib/gitlab/request_context.rb:18:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'Steps to reproduce
- Create a Group with visibility Internal
- Create a Subgroup with visibility Private
- Create a Project in Subgroup with default visibility (private)
- Change visibility of project from private to internal (no immediate error is apparent)
- Go back to Subgroup overview page, an error shows "The project could not be updated" (very vague!)
- Go back to Project overview, shows 500 error.
Example Project
(used steps above to reproduce and create this project)
https://gitlab.com/DrewMirandaTestGroup/SubGroup/TestProject/
What is the current bug behavior?
The project doesn't load and is 100% inaccessible to the owner, gitlab admin, etc.
What is the expected correct behavior?
The project be accessible
Relevant logs and/or screenshots
See above for log snippet and also reference example project create on gitlab.com which replicates this issue.
Output of checks
This bug happens on GitLab.com (and gitlab-ce)
Results of GitLab environment info
See gitlab.com