README.md in protector-cancan-0.1.0 vs README.md in protector-cancan-0.1.1
- old
+ new
@@ -1,7 +1,11 @@
# Protector::Cancan
+[](http://badge.fury.io/rb/protector-cancan)
+[](https://travis-ci.org/inossidabile/protector-cancan)
+[](https://codeclimate.com/github/inossidabile/protector-cancan)
+
Integrates [Protector](https://github.com/inossidabile/protector) and [CanCan](https://github.com/ryanb/cancan).
Protector and CanCan are all about the same thing: access control. They however act on different fronts: Protector works on a model level and CanCan is all about controllers defense. With this gem you don't have to choose anymore: make them work together for the best result.
The integration makes CanCan aware of Protector restrictions. You still can have separate `Ability` instance and even extend (or override) what comes from Protector.
@@ -42,10 +46,10 @@
can :read if user
end
end
```
-If you call `can? :read, Dummy`, the gem will evaluate `Dummy` protection block against value passed to `import_protector` (by default it's `current_user`) and expand CanCan rules with resulting meta.
+If you call `can? :view, Dummy`, the gem will evaluate `Dummy` protection block against value passed to `import_protector` (by default it's `current_user`) and expand CanCan rules with resulting meta. Note that gem automatically converts `:read` to `:view` so you should use CanCan naming conventions when working with CanCan.
So in this particular case we will get `true` if `current_user` is set and `false` otherwise.
And that's how controller is going to work:
\ No newline at end of file