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
Support methods around field policies #918
Comments
At the moment, field policies are only for reading. We will have to start with making it even possible to use them for creates/updates. Technically that would be a breaking change if we make policies apply to more action types, so we'd need to make something like After that, we could add some helpers around things like |
Okay maybe a discussion for a lot later then :) |
I think it would be relatively straightforward to add this functionality (not necessarily the helpers, but supporting field policies on writes), and doing it before 3.0 would be pretty reasonable. It would essentially just be policies that apply only if the field is being changed. |
Actually, |
I'm not sure that |
What would the defaulting look like? field_policy :field, condition do
...
end There wouldn't be a way that we can let them override I think. The other thing I'm thinking about is that the logic around write policies (like the helpers) will be significantly different, i.e |
Is your feature request related to a problem? Please describe.
I think we discussed this a while ago but I couldn't find a record of an issue I'd created to track it. So here it is!
It would be awesome if there was some support functionality around field policies, to make them really usable within an application.
The scenario I was thinking of was -
eg. I have a resource like
Album
and a user is allowed to edit the album, but not thecover_image_url
field.So ideally I could -
show the form to edit the resource, but wrap individual field rendering in a
can?
check to only show the field if the user is allowed to edit ithave some kind of helper either before/after form submission, that strips fields that the user can't edit if they happen to be present? At the moment, field policies don't seem to do anything here, I did some quick testing with a field policy setup like this -
And my user was still able to submit a form to update the album, including updating the
cover_image_url
field.Alternatively, returning a forbidden error in this scenario would be okay I think.
The text was updated successfully, but these errors were encountered: