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

Support methods around field policies #918

Open
sevenseacat opened this issue Mar 1, 2024 · 6 comments
Open

Support methods around field policies #918

sevenseacat opened this issue Mar 1, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@sevenseacat
Copy link
Contributor

sevenseacat commented Mar 1, 2024

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 the cover_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 it

  • have 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 -

  field_policies do
    field_policy :* do
      authorize_if always()
    end

    field_policy :cover_image_url do
      authorize_unless action_type(:update)
    end
  end

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.

@sevenseacat sevenseacat added enhancement New feature or request needs review labels Mar 1, 2024
@zachdaniel
Copy link
Contributor

zachdaniel commented Mar 1, 2024

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 write_policy to do that.

After that, we could add some helpers around things like can_write_field or something along those lines.

@sevenseacat
Copy link
Contributor Author

Okay maybe a discussion for a lot later then :)

@zachdaniel
Copy link
Contributor

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.

@zachdaniel
Copy link
Contributor

Actually, write_policy makes more sense than overloading the field_policy DSL. So before/after 3.0 won't make much difference.

@jimsynz
Copy link
Contributor

jimsynz commented Mar 1, 2024

I'm not sure that write_policy makes much sense since policies (not field policies) are read/write agnostic and take the applicability from filters such as action_type. What if we made field policies support action_type and action and just defaulted them to action_type(:read)?

@zachdaniel
Copy link
Contributor

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 "can_edit_field". We'll have to spec it out though. I'll keep this for a "later" thing and we can revisit after 3.0.

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

3 participants