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

README should provide promised "cannot" example. #48

Open
jrochkind opened this issue Jul 5, 2018 · 5 comments
Open

README should provide promised "cannot" example. #48

jrochkind opened this issue Jul 5, 2018 · 5 comments

Comments

@jrochkind
Copy link
Contributor

jrochkind commented Jul 5, 2018

README says:

Note: cannot is still available, but has a very specifc [sic] use. See Usage below.

However, no example is actually given of cannot in Usage or elsewhere. Controller/view method cannot? is described, but not the quite different cannot method in permission definitions.

At first I thought cannot was maybe not actually there, the README reference was wrong or I misunderstood it.

But then I saw it in the specs. Apparently it does exist, hooray!

But the README needs a short explained example as promised. :)

@jrochkind jrochkind changed the title README should provide promissed "cannot" example. README should provide promised "cannot" example. Jul 5, 2018
@pokonski
Copy link
Contributor

pokonski commented Jul 5, 2018

Hey @jrochkind! You are correct, there was an example of cannot but it got mistakenly removed along the way 😱

@jrochkind
Copy link
Contributor Author

Thanks! I actually could really use a cannot example!

I tried looking through README history, this seems to be the last version that still has a cannot in it... but I don't totally understand it.

https://github.com/chaps-io/access-granted/blob/d0079b7648fe60a2341b914727189a9c67d44df9/README.md

@pokonski
Copy link
Contributor

pokonski commented Jul 25, 2018

Okay so I'll try to explain it here, and if it makes sense I'll put it in README:

tldr; Access Granted traverses roles top to bottom, as soon as it finds a matching can/cannot in one of the roles it stops looking at the roles below it.

In the example below let's assume we want to disallow banned members from posting (and only from posting) on our forum:

            role :banned, { is_banned: true } do
              cannot :create, Post
            end

            role :member do
              can :create, Post
              # (some other permissions here)
            end
          end

we put :banned above the regular role so it take can precedence over the regular role below (:member).

Steps of the logic would look as follows:

  1. You execute can?(:create, Post)
  2. AG starts iterating over defined roles.
  3. first we check the role :banned
  4. does it have a permission defined for :create and model Post?
  5. yes it does so we use that and stop looking at roles below it
  6. AG returns result of can?(:create, Post) which is false, because cannot is a negative.

@jrochkind
Copy link
Contributor Author

This is actually quite helpful, yeah. It explains what you mean by about the importance of order too, which I was confused about too. "as soon as it finds a matching can/cannot in one of the roles it stops looking at the roles below it." -- that's the important part. Thanks!

@pokonski
Copy link
Contributor

Glad I could help 👍

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

No branches or pull requests

2 participants