This will allow an explicitly-disabled feature flag to override a
feature being available for a project.
As an extreme example, we could quickly disable issues across all
projects at runtime by running `Feature.disable(:issues)`.
We started syncing all the wiki regardless of the fact it's disabled or
not. We couldn't do that in one stage because of needing of smoth update
and deprecating things. This is the second stage that finally removes
unused columns in the geo_node_status table.
In CE only the admin has access to all private groups & projects. In EE also an
auditor can have full private access.
To overcome merge conflicts, or accidental incorrect access rights, abstract
this out in `User#full_private_access?`.
`User#admin?` now only should be used for admin-only features. For private
access-related features `User#full_private_access?` should be used.
Backported from gitlab-org/gitlab-ee!2199
This method used to use a UNION, which would lead to it performing the
same query twice; producing less than ideal performance. Further, in
certain cases ActiveRecord could get confused and mess up the variable
bindings, though it's not clear how/why exactly this happens.
Fortunately we can work around all of this by building some of the WHERE
conditions manually, allowing us to use a simple OR statement to get all
the data we want without any of the above problems.
This commit includes a couple of thing:
- A chatops controller
- Mattermost::CommandService
- Mattermost::Commands::(IssueService|MergeRequestService)
The controller is the point where mattermost, and later slack will have
to fire their payload to. This in turn will execute the CommandService.
Thats where the authentication and authorization should happen. So far
this is not yet implemented. This should happen in later commits.
Per subcommand, in case of `/gitlab issue show 123` issue whould be the
subcommand, there is a service to parse the data, and fetch the
resource. The resource is passed back to the CommandService which
structures the data.
The library we're using, default_value_for, is configured to interpret nil
as the default value, being ENABLED. Given the property can't be nil
this check is unneeded.
Honour issue and merge request visibility in their respective finders
This MR fixes a security issue with the IssuesFinder and MergeRequestFinder where they would return items the user did not have permission to see. This was most visible on the issue and merge requests page for a group containing projects that had set their issues or merge requests to "private".
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/22481
See merge request !2000
Projects that are destroyed are put in the pending_delete state.
The ProjectDestroyWorker checks whether the current user has
access, but since the ProjectFeature class uses the default scope
of the Project, it will not be able to find the right project.
This was a regression in 8.12 that caused the following stack trace:
```
NoMethodError: undefined method `team' for nil:NilClass
from app/models/project_feature.rb:62:in `get_permission'
from app/models/project_feature.rb:34:in `feature_available?'
from app/models/project.rb:21:in `feature_available?'
from app/policies/project_policy.rb:170:in `disabled_features!'
from app/policies/project_policy.rb:29:in `rules'
from app/policies/base_policy.rb:82:in `block in abilities'
from app/policies/base_policy.rb:113:in `collect_rules'
from app/policies/base_policy.rb:82:in `abilities'
from app/policies/base_policy.rb:50:in `abilities'
from app/models/ability.rb:64:in `uncached_allowed'
from app/models/ability.rb:58:in `allowed'
from app/models/ability.rb:49:in `allowed?'
from app/services/base_service.rb:11:in `can?'
from lib/gitlab/metrics/instrumentation.rb:155:in `block in can?'
from lib/gitlab/metrics/method_call.rb:23:in `measure'
from lib/gitlab/metrics/instrumentation.rb:155:in `can?'
from app/services/projects/destroy_service.rb:18:in `execute'
```
Closes#22948
Tuomo Ala-Vannesluoma