You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
classApplicationFeaturePolicy < Accessly::Policy::Baseactions(view_dashboard: 1,view_super_secret_page: 2,view_double_secret_probation_page: 3)defon_view_dashboard_grant# Do some stuff on grantenddefon_view_dashboard_revoke# Do some stuff on revokeendend
It would be crazy, but you could copy Rails before/ after actions
Maybe we just find a way to expose the granting/revoking methods
classApplicationFeaturePolicy < Accessly::Policy::Baseactions(view_dashboard: 1,view_super_secret_page: 2,view_double_secret_probation_page: 3)defgrant_view_dashboardsuper# do something elseenddefrevoke_view_dashboardsuper# do something elseendend
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.
The text was updated successfully, but these errors were encountered:
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
It would be crazy, but you could copy Rails before/ after actions
Maybe we just find a way to expose the granting/revoking methods
The problem with this last case is that we use params supplied to
revoke!
andgrant!
methods rather than methods specific to the action likegrant_view_dashboard
, so it might be involved to find a way to restructure that to have those override-able methods.The text was updated successfully, but these errors were encountered: