Skip to content

Ability to supply callbacks/ overrides for granting and revoking actions #31

@rreinhardt9

Description

@rreinhardt9

Use Cases

The first use case has been that we have caching in the app and because of the way the page is structured, whenever a particular actions is granted or revoked we need to touch all groups in that actors company. This could either work either as a callback that is triggered if the status of that permission has changed or maybe just as a general ability to override the granting/ revoking methods for that action.

Another has been actions that are related to/ depend on other actions. We have a permission that is a "base" level permission that lets you manage some records; but then we have another that gives you enhanced "editing" privileges. But if you have the second, you have to have the first because they don't make sense separately. In this case, if we could override the granting process or supply a callback we could make sure that the "base" permission is granted if "edit" is granted.

More Info

This may or may not work in concert to the changes talked about in #28 . If we had the ability to mark when an action has really changed, that may come in handy when determining when to call the callback (if we went the callback route).

Pseudocode

This could be using methods defined as callbacks

class ApplicationFeaturePolicy < Accessly::Policy::Base

  actions(
    view_dashboard: 1,
    view_super_secret_page: 2,
    view_double_secret_probation_page: 3
  )

  def on_view_dashboard_grant
    # Do some stuff on grant
  end

  def on_view_dashboard_revoke
    # Do some stuff on revoke
  end
end

It would be crazy, but you could copy Rails before/ after actions

class ApplicationFeaturePolicy < Accessly::Policy::Base
  after_grant :do_grant_stuff, only: :view_dashboard
  after_revoke :do_revoke_stuff, only: :view_dashboard

  actions(
    view_dashboard: 1,
    view_super_secret_page: 2,
    view_double_secret_probation_page: 3
  )


  private
  
  def do_grant_stuff
  end

  def do_revoke_stuff
  end
end

Maybe we just find a way to expose the granting/revoking methods

class ApplicationFeaturePolicy < Accessly::Policy::Base

  actions(
    view_dashboard: 1,
    view_super_secret_page: 2,
    view_double_secret_probation_page: 3
  )


  def grant_view_dashboard
    super

    # do something else
  end

  def revoke_view_dashboard
    super

    # do something else
  end
end

The problem with this last case is that we use params supplied to revoke! and grant! methods rather than methods specific to the action like grant_view_dashboard, so it might be involved to find a way to restructure that to have those override-able methods.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions