Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Doc enhance for decorators with Cancancan (Drapper and may be other decorators) #5443
First of all, thanks for ActiveAdmin!
This is not really an ActiveAdmin issue, but a quick clarification note about this behaviour in the documentation could save others a lot of time.
While migrating an AA app that uses draper and cancancan from Rails 4.2 to Rails 5.2, I found that I was getting access denied when trying to show some resources (but not all) despite them being correctly authorized in the ability class. Index was also working as expected.
The difference between working and not working models was that not working ones had assigned a drapper decorator, and with this clue I narrowed down the problem to cancancan.
Since version 1.13 they have changed the way to get the class of the object being authorized. In previous versions when authorizing a decorated object they where taking the real object's class, with the change, they are taking the decorator's class and that raises unauthorized accesses because the decorator class is not authorized in the abilities.
Cancancan saves its back saying that objects should not be decorated on the controllers, but in views. Right now AA decorates objects right on database retrieval and not before rendering views and It seems difficult to change (issue #4243).
I have not tested it but It seems that the very same problem is going to raise with PORO and other decorators since they normally are a different class from the original object.
Fortunately there is a very quick workaround:
Adding this to Gemfile (and bundle install):
And then adding