Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rreinhardt9 opened this issue Feb 27, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@rreinhardt9
Copy link
Contributor

rreinhardt9 commented Feb 27, 2019

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.

@rreinhardt9 rreinhardt9 added the enhancement New feature or request label Feb 27, 2019
@rreinhardt9
Copy link
Contributor Author

rreinhardt9 commented Apr 2, 2019

Some more thoughts from lessonly/lessonly#6479 https://github.com/lessonly/lessonly/pull/6479/files#r271478801

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant