GitLab EE

https://docs.gitlab.com/ee/
Admin
GitLab EE is a comprehensive platform for the complete DevOps lifecycle, providing source code...
Tokens:2,334
Snippets:31
Trust Score:10
Update:5 months ago
Show doc for...
Tokens:
Raw
### Specify Custom Policy Class

Source: https://docs.gitlab.com/ee/development/policies.html

Shows how to specify a custom policy class for a given subject. This allows you to use and check permissions against a different policy class than the one automatically determined.

```ruby
class Foo

  def self.declarative_policy_class
    'SomeOtherPolicy'
  end
end
```

--------------------------------

### Define Parent Policy with Rules

Source: https://docs.gitlab.com/ee/development/policies.html

Defines a parent policy with various conditions and rules for enabling and preventing abilities. Use this as a base for delegation.

```ruby
class ParentPolicy < BasePolicy
  condition(:speaks_spanish) { @subject.spoken_languages.include?(:es) }
  condition(:has_license) { @subject.driving_license.present? }
  condition(:is_employed) { @subject.is_employed? }

  rule { speaks_spanish }.enable :read_spanish
  rule { has_license }.enable :drive_car
  rule { is_employed }.enable :earn_money
  rule { ~is_employed }.prevent :earn_money
end
```

--------------------------------

### Configure Rules with Conditions in DeclarativePolicy

Source: https://docs.gitlab.com/ee/development/policies.html

Configure rules using conditions to enable or prevent abilities. Rules are static and cannot access the database or subject directly. Use operators like `~`, `&`, `|`, and `can?` for complex logic.

```ruby
class FooPolicy < BasePolicy
  # ...

  rule { is_public }.enable :read
  rule { ~thing }.prevent :read

  # equivalently,
  rule { is_public }.policy do
    enable :read
  end

  rule { ~thing }.policy do
    prevent :read
  end
end
```

--------------------------------

### Debug Policy Evaluation

Source: https://docs.gitlab.com/ee/development/policies.html

Use this to inspect the order and outcome of policy rule evaluations for a specific ability. It helps understand why a policy decision was made.

```ruby
user = User.find_by(username: 'sidneyjones')
issue = Issue.first
policy = IssuePolicy.new(user, issue)
policy.debug(:read_issue)
```

```ruby
- [0] prevent when all?(confidential, ~can_read_confidential) ((@sidneyjones : Issue/1))
- [0] prevent when archived ((@sidneyjones : Project/4))
- [0] prevent when issues_disabled ((@sidneyjones : Project/4))
- [0] prevent when all?(anonymous, ~public_project) ((@sidneyjones : Project/4))
+ [32] enable when can?(:reporter_access) ((@sidneyjones : Project/4))
```

--------------------------------

### Delegate Rules from Another Policy

Source: https://docs.gitlab.com/ee/development/policies.html

Include all rules from another policy (e.g., ProjectPolicy) into the current policy. The delegated conditions are evaluated with the correct delegated subject and sorted with the regular rules.

```ruby
class FooPolicy < BasePolicy
  delegate { @subject.project }
end
```

--------------------------------

### Define Policy Condition with Global Scope

Source: https://docs.gitlab.com/ee/development/policies.html

Use the :global scope for conditions that are universally true or false, ensuring the result is cached across all users and subjects.

```ruby
condition(:earth_exists, scope: :global) { Planet::Earth.exists? }
```

--------------------------------

### Set Preferred Scope for User Selection

Source: https://docs.gitlab.com/ee/development/policies.html

Prefer caching rules based on the user parameter when checking permissions for many users against a single subject. This optimizes performance by leveraging user-specific caching.

```ruby
def users_that_can_read_project(users, project)
  DeclarativePolicy.subject_scope do
    users.select { |u| allowed?(u, :read_project, project) }
  end
end
```

--------------------------------

### Define Conditions in DeclarativePolicy

Source: https://docs.gitlab.com/ee/development/policies.html

Define boolean conditions that can access the policy's `@user` and `@subject`. Predicate methods are automatically generated for each condition.

```ruby
class FooPolicy < BasePolicy
  condition(:is_public) do
    # @subject guaranteed to be an instance of Foo
    @subject.public?
  end

  # instance methods can be called from the condition as well
  condition(:thing) { check_thing }

  def check_thing
    # ...
  end
end
```

--------------------------------

### Child Policy Overriding an Ability

Source: https://docs.gitlab.com/ee/development/policies.html

Demonstrates how a child policy can override a specific ability defined in its parent policy. Use this when the child needs a different definition for an ability that the parent has already defined or prevented.

```ruby
class ChildPolicy < BasePolicy
  delegate { @subject.parent }

  overrides :earn_money

  condition(:has_allowance) { @subject.has_allowance? }

  rule { has_allowance }.enable :earn_money
end
```

--------------------------------

### Child Policy Preventing an Ability

Source: https://docs.gitlab.com/ee/development/policies.html

A child policy that delegates to a parent policy but explicitly prevents a specific ability. This is useful when a delegated ability doesn't make sense for the child.

```ruby
class ChildPolicy < BasePolicy
  delegate { @subject.parent }

  rule { default }.prevent :drive_car
end
```

--------------------------------

### Define Policy Condition with Subject Scope

Source: https://docs.gitlab.com/ee/development/policies.html

Cache policy condition results based on the subject when the condition's evaluation only depends on the subject's data. This prevents recalculation for different users accessing the same subject.

```ruby
class FooPolicy < BasePolicy
  condition(:expensive_condition) { @subject.expensive_query? }

  rule { expensive_condition }.enable :some_ability
end
```

```ruby
condition(:expensive_condition, scope: :subject) { @subject.expensive_query? }
```
Tokens:
Raw