gitlab-org--gitlab-foss/app/policies/base_policy.rb
Sean McGivern 5883ce95ef current_application_settings belongs on Gitlab::CurrentSettings
The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.

To fix this:

1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
   `Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
   like that in several places.
3. Change the initializers to use that new form.
2017-08-31 13:38:33 +01:00

18 lines
652 B
Ruby

require_dependency 'declarative_policy'
class BasePolicy < DeclarativePolicy::Base
desc "User is an instance admin"
with_options scope: :user, score: 0
condition(:admin) { @user&.admin? }
with_options scope: :user, score: 0
condition(:external_user) { @user.nil? || @user.external? }
with_options scope: :user, score: 0
condition(:can_create_group) { @user&.can_create_group }
desc "The application is restricted from public visibility"
condition(:restricted_public_level, scope: :global) do
Gitlab::CurrentSettings.current_application_settings.restricted_visibility_levels.include?(Gitlab::VisibilityLevel::PUBLIC)
end
end