Authorization

What a policy looks like

A plain Pundit policy. Avo calls these methods to decide what each user sees and can do, and the Scope filters the index query. Each method reverberates through the whole UI, hiding the menu items, links, buttons, fields, and rows a user is not allowed to reach, so the policy you write is what actually keeps your data safe rather than just dimming controls that still work.

class ProjectPolicy < ApplicationPolicy
  def index?  = true
  def show?   = true
  def create? = user.admin?
  def update? = record.owned_by?(user)
  def destroy? = user.admin?

  # Gate the files field on the record
  def upload_files?   = update?
  def download_files? = show?
  def delete_files?   = user.admin?

  # Only load the rows this user may see
  class Scope < ApplicationPolicy::Scope
    def resolve
      user.admin? ? scope.all : scope.where(owner: user)
    end
  end
end

What you get

• Resource policies covering the full lifecycle, from index?, show?, new?, create?, edit?, update?, and destroy? down to your own custom actions
• Per-association control with attach_ASSOCIATION_NAME, detach_ASSOCIATION_NAME, view_ASSOCIATION_NAME, create_ASSOCIATION_NAME, and destroy_ASSOCIATION_NAME methods
• File field authorization through upload_ATTACHMENT_NAME, download_ATTACHMENT_NAME, and delete_ATTACHMENT_NAME checks
• Pundit Scope classes that filter index queries to the records each user may load
• Action, search, reorder, and preview gating with act_on?, search?, reorder?, and preview?
• Adapters for Pundit, Action Policy, and CanCanCan, plus custom authorization clients and configurable method names

Why it pays off

• Built and maintained by the Avo core team. Authorization is part of how Avo works, not a separate layer bolted on top, so it reaches the sidebar, the buttons, the associations, and the index query the same way.
• It reaches every nook and cranny. Resources, actions, associations, file fields, search, reorder, and preview each have their own check, and it is configurable down to the method names and the authorization client, so you can fit it to how your app already does permissions.
• Safe by default. With explicit authorization on, a missing policy or method denies access instead of granting it. You whitelist what each role may do rather than remembering to blacklist everything you forgot, so a policy you never wrote locks a record down instead of leaving it open.
• Data integrity and security are treated as first-class here, not an afterthought. This is the code you cannot afford to get subtly wrong, and it is built for many apps and reviewed by people, not wired up once and left alone.
• Reuse the Pundit policies you already trust instead of writing a second permission model just for the admin.
• Every Avo release makes it better: policies stay enforced across the sidebar, buttons, fields, and index queries as you add resources and upgrade Avo, with fixes shipping to everyone, without you patching the wiring.