Dictator v1.1.0 Dictator.Policies.BelongsTo View Source

Policy definition commonly used in typical belongs_to associations.

This policy assumes the users can read (:show, :index, :new, :create) any information but only write (:edit, :update, :delete) their own.

As an example, in a typical Twitter-like application, a user has_many posts and a post belongs_to a user. You can define a policy to let users manage their own posts but read all others by doing the following:

defmodule MyAppWeb.Policies.Post do
  alias MyApp.{Post, User}

  use Dictator.Policies.EctoSchema, for: Post

  def can?(_, action, _) when action in [:index, :show, :new, :create], do: true

  def can?(%User{id: id}, action, %{resource: %Post{user_id: id}})
      when action in [:edit, :update, :delete],
      do: true

  def can?(_, _, _), do: false
end

This scenario is so common, it is abstracted completely through this module and you can simply use Dictator.Policies.BelongsTo, for: Post to make use of it. The following example is equivalent to the previous one:

defmodule MyAppWeb.Policies.Post do
  use Dictator.Policies.BelongsTo, for: MyApp.Post
end

Allowed Options

All options available in Dictator.Policies.EctoSchema plus the following:

• foreign_key: foreign key of the current user in the resource being accessed. If a Post belongs to a User, this option would typically be :user_id. Defaults to :user_id.
• owner_key: primary key of the current user. Defaults to :id

Examples

Assuming a typical User schema, with an :id primary key, and a typical Post schema, with a belongs_to association to a User:

# lib/my_app_web/policies/post.ex
defmodule MyAppWeb.Policies.Post do
  use Dictator.Policies.BelongsTo, for: MyApp.Post
end

If, however, the user has a uuid primary key and the post has an admin_id key instead of the typical uer_id, you should do the following:

# lib/my_app_web/policies/post.ex
defmodule MyAppWeb.Policies.Post do
  use Dictator.Policies.BelongsTo, for: MyApp.Post, owner_key: :uuid,
    foreign_key: :admin_id
end