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

Can't use :from with any other option #164

Open
lukeredpath opened this issue Sep 16, 2016 · 3 comments
Open

Can't use :from with any other option #164

lukeredpath opened this issue Sep 16, 2016 · 3 comments

Comments

@lukeredpath
Copy link

Trying to use :from with :with raises an error that using any other option with :from doesn't make any sense.

Doesn't it?

I want to authorise my models using Pundit. I want to do this by calling authorize - I don't care how the model was loaded.

An easy way of doing this would be to use decorate:

expose :foo, decorate: ->(foo) { foo.tap { authorize(foo) } }

The pattern is common enough I'd probably want to wrap it up isn an exposure config:

exposure_config :authorization, decorate: ->(obj) { obj.tap { authorize(obj) } }

Now I can just do:

expose :foo, with: :authorization

Great! Now I have a singleton resource I'd like to load as an association from the logged in user:

expose :organisation, from: :current_user

But I want it authorised too:

expose :organisation, from: :current_user, with: :authorization

But this doesn't work as I can't use with and from together.

I can't do this either:

expose :organisation, fetch: -> { current_user.organisation }, with: :authorization

I can only do this:

expose :organisation, fetch: -> { current_user.organisation.tap { |o| authorize(o) } }

But now I'm duplicating my call to authorize, something I'd prefer to keep encapsulated.

Is there a reason to make these options mutually exclusive, just because sometimes they don't make sense to use together? Does the library need to be this restrictive?

@hazah
Copy link

hazah commented Apr 4, 2017

It would seem to me that this can be resolved by calling normalize_with_option before the asserts in the initialize method. Given that :with options are to simply a pointer to some defaults, it makes sense that these defaults be included in the asserts rather than the option pointing to them.

@hazah
Copy link

hazah commented Nov 20, 2017

#175

@lukeredpath
Copy link
Author

🎉🎉🎉

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

No branches or pull requests

2 participants