While we wait for 1.6.11...

[bryanrite]

I've taken a number of the pull requests that address rails 4 issues, but also just general query bugs and rolled them up into single PR... the idea being if people want to use a more up to date version of CanCan.

In a nutshell:

• It moves up to 1.9.3 (but still supports 1.8.7)
• Fixes several bugs (shallow routing, nested conditions, class level scoping, multiple rule issues with associations)
• Fixes several Rails 4 incompatibilities (scoping, deprecation warnings)
• Adds strong_parameters support
• Uses .ruby-version instead of .rvmrc
• jRuby support.

This PR combines:

https://github.com/ryanb/cancan/pull/726 https://github.com/ryanb/cancan/pull/864 https://github.com/ryanb/cancan/pull/871 https://github.com/ryanb/cancan/pull/906 https://github.com/ryanb/cancan/pull/935 https://github.com/ryanb/cancan/pull/966 https://github.com/ryanb/cancan/pull/971 https://github.com/ryanb/cancan/pull/974 https://github.com/ryanb/cancan/pull/977 https://github.com/ryanb/cancan/pull/980 https://github.com/ryanb/cancan/pull/988

Thank you to all the other contributors!

[bryanrite]

I've already been asked to keep 1.8.7, so i'll submit a patch in a few to keep it going.

[JustinAiken]

:+1:

[lpradovera]

:+1: , this really needed to be done!

[zdavis]

Yeah, this is awesome. Thanks.

[MattRogish]

:+1:

[bryanrite]

Thanks guys... this will be a living pull request, i'll keep adding other PRs as needed.

[vendethiel]

Great piece of work. Thanks!

[bryanrite]

@lephyrius Done.

[bryanrite]

Whoot, all green = jRuby support.

[lephyrius]

Yay! I :heart: jRuby!

[ricardodovalle]

:+1:

[willkoehler]

Brilliant @bryanrite, thanks for this!

In case it helps anyone else, you can reference @bryanrite's fork in your gemfile like this

gem 'cancan', :git => '[email protected]:bryanrite/cancan.git'

I am locking on a specific commit so my deploys are consistent.

gem 'cancan', :git => '[email protected]:bryanrite/cancan.git', :ref => '014f51307fa34d42602e71fa86724f532504f6a2'

[pokonski]

I've been working on a complete CanCan replacement since this one is long dead =>

https://github.com/pokonski/access-granted

I successfully use it in production where I replaced CanCan completely in just one day.

• Works on Rubies 1.9.3, 2.0.0 and 2.1.0 (will also work with JRuby and Rubinius ~ 2.0)
• Has ZERO external dependencies (pure Ruby)
• introduces roles for users to make permission defining readable and easy to maintain

This is actively maintained, so any suggestions from you are welcome and will be considered!

[bryanrite]

@pokonski Your library looks great!

Your point is valid, we haven't really heard from Ryan in almost a year now and this project hasn't seen any movement in a while.

I love cancan and it solves a lot of problems for me. My goal was to try and help maintain this repo as CanCan is still very relevant and, imho, the best authz lib for rails out there. If we don't see any movement on the repo soon, hopefully with @ryanb blessing, I'll start a successor gem with this fork and continue development there.

Thoughts?

[pokonski]

@bryanrite Sure, can't force anyone to use it :) CanCan served me well for years, but I just really needed something up-to-date and fixed so I decided to take the best stuff from CanCan and do it again from scratch tailor-made to my needs.

I tried to explain every difference compared to CanCan in readme to make it clear for people wanting to switch :)

@kuraga / @bryanrite I'm glad you like it!

[willkoehler]

@bryanrite I agree the best solution would be for @ryanb to give a few core contributors push rights to this project so we can help maintain the existing gem. The alternative would be to create a successor gem with your fork. Either way I'll will help out as a core contributor if you need it, reviewing issues and pull requests and updating documentation.

CanCan has been a perfect authorization solution for my projects. I think it's still relevant and I am willing to do what it takes to keep it going.

@pokonski AccessGranted looks great. I appreciate your pure approach, keeping things simple. However I make extensive use of accessible_by and the scopes that CanCan provides. This is a must-have feature for me.

[pokonski]

@willkoehler yeah that is the biggest part of CanCan I do not want to have right now, because it's really complex compared to the rest of the code. Maybe as an extension to access-granted if it turns out it's heavily used by you guys (opinions welcome!)

[bryanrite]

@willkoehler I'm in the same boat as you, the scoping and accessible_by are the parts of CanCan that I really like. I'll definitely keep you (and this thread) up to date as we progress.

[kuraga]

Note we talk about three things:

1. what to do about CanCan 1.6.x,
2. what to do about CanCan 2.x,
3. do we need successors of CanCan?

The most important question I think is the first. And the correct answer is obvious: bug fixes should be and they should be in this repository. The really question is where is @ryanb .

The second and the third questions is about nomenclature only I think... If there are people like @pokonski they do it. We can talk about a name of their work only. But why?

So we need @ryanb five months already...

[xhoy]

Why don't just start a fork? maby it's just a social experiment from @ryanb to see if open source really works :)

And if @ryanb comesback he can always merge the changes to the original cancan.

I would call the it re-cancan ? or cancan SE? :)

[kuraga]

So, can't we find @ryanb ? Absolutely?

[xhoy]

@kuraga Afaik he is still alive, at least when i read this thread yesterday, since i had some rails 4 cancan issues.I did some research and he does login to his stackoverflow account sometimes and even comments ( http://stackoverflow.com/users/148722/ryanb ) and he made changed a gist 18 days ago ( https://gist.github.com/ryanb/4172391 ). Other then that i don't know where he is or what he does, i only watch his railscasts, and use his awesome gems but other then that i don't know him :)

Is there anyone that can confirm he/she send him an email at all? or is everyone waiting for somebody else to do that.

[willkoehler]

I exchanged emails with @nashby who is a collaborator on CanCan. His only contact with Ryan was through [email protected]. I tried sending an email to Ryan at that address and also sent him a tweet https://twitter.com/wckoehler/status/432529759797387264.

[elthariel]

@bryanrite Maintainance work on CanCan would surely be a good thing for the community. Although i've started switching my project to Authority gem, It's still a blocker on many people's upgrade path to rails 4 who really enjoy this tool and doesn't want to replace it.

Is there a known list of hackers except you that would be willing to contribute some time on it ?

[willkoehler]

@elthariel @bryanrite I don't think we're going to hear from @ryanb. It seems like he wants to keep a low profile and we should respect that. I think it's time to move forward with a fork. I'll will help out as a core contributor, reviewing issues and pull requests and updating documentation.

Do you think there's a chance rubygems.org will allow us to continue publishing under the cancan name until @ryanb returns? Otherwise any ideas for a new name?

[lpradovera]

Count me in, I am using this fork in at least a couple large projects.

If we are going with a pun name, we should name the fork “couldcan” :)

Luca Pradovera [email protected]

On Feb 19, 2014, at 5:49 PM, Will Koehler [email protected] wrote:

@elthariel @bryanrite I don't think we're going to hear from @ryanb. It seems like he wants to keep a low profile and we should respect that. I think it's time to move forward with a fork. I'll will help out as a core contributor, reviewing issues and pull requests and updating documentation.

Do you think there's a chance rubygems.org will allow us to continue publishing under the cancan name until @ryanb returns? Otherwise any ideas for a new name?

— Reply to this email directly or view it on GitHub.

[JustinAiken]

• chahut (original name of the can can)
• cancancant
• bryanritecan
• cancan_fork_thats_actually_maintained
• cancan2

I'll help with the fork too, I don't want to learn a new framework :p

[elthariel]

• railswecan :)

On Wed, Feb 19, 2014 at 6:31 PM, JustinAiken [email protected]:

• chahut (original name of the can can)
• cancancant
• bryanritecan
• cancan_fork_thats_actually_maintained
• cancan2

I'll help with the fork too, I don't want to learn a new framework :p

Reply to this email directly or view it on GitHubhttps://github.com/ryanb/cancan/pull/989#issuecomment-35524760 .

[bryanrite]

I was just testing out the branch on a couple of my bigger clients stuck on 1.6.9. Everything seems to be good and so far it's a viable drop in replacement for the 1.x line.

I'm going to cut a new gem, and start it at version 1.7.0 (following SemVer) so it's a simple and intuitive upgrade path.

I am stuck on a name, I want it to be obvious that it's a continuation of Ryan's work, so sticking to a variant of cancan:

cancant cancancan cancannot cancan_2_revenge_of_the_can (:smile:)

Thoughts?

Bryan Rite

Sent from my mobile device so I apologize for any errors.

On Feb 19, 2014, at 8:49 AM, Will Koehler [email protected] wrote:

@elthariel @bryanrite I don't think we're going to hear from @ryanb. It seems like he wants to keep a low profile and we should respect that. I think it's time to move forward with a fork. I'll will help out as a core contributor, reviewing issues and pull requests and updating documentation.

Do you think there's a chance rubygems.org will allow us to continue publishing under the cancan name until @ryanb returns? Otherwise any ideas for a new name?

— Reply to this email directly or view it on GitHub.

[lpradovera]

If you would like to go with the “continuation” name I would rather not have a negative in it. “cancancan” is different enough and is a clever pun on “putting cancan in the can” :)

Luca Pradovera [email protected]

On Feb 19, 2014, at 6:42 PM, Bryan Rite [email protected] wrote:

I was just testing out the branch on a couple of my bigger clients stuck on 1.6.9. Everything seems to be good and so far it's a viable drop in replacement for the 1.x line.

I'm going to cut a new gem, and start it at version 1.7.0 (following SemVer) so it's a simple and intuitive upgrade path.

I am stuck on a name, I want it to be obvious that it's a continuation of Ryan's work, so sticking to a variant of cancan:

cancant cancancan cancannot cancan_2_revenge_of_the_can (:smile:)

Thought?

Bryan Rite

Sent from my mobile device so I apologize for any errors.

On Feb 19, 2014, at 8:49 AM, Will Koehler [email protected] wrote:

@elthariel @bryanrite I don't think we're going to hear from @ryanb. It seems like he wants to keep a low profile and we should respect that. I think it's time to move forward with a fork. I'll will help out as a core contributor, reviewing issues and pull requests and updating documentation.

Do you think there's a chance rubygems.org will allow us to continue publishing under the cancan name until @ryanb returns? Otherwise any ideas for a new name?

— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.

[willkoehler]

@bryanrite Sounds great. @polysics I was also thinking "cancancan". Simple extension of the name with no negatives.

[scaryguy]

What about canable? :)

[bryanrite]

Thats 3 for cancancan...sold!

I'll cut it ASAP.

[elthariel]

OpenSource at work, my favorite web show

On Wed, Feb 19, 2014 at 6:58 PM, Bryan Rite [email protected]:

Thats 3 for cancancan...sold!

I'll cut it ASAP.

Reply to this email directly or view it on GitHubhttps://github.com/ryanb/cancan/pull/989#issuecomment-35527722 .

[vendethiel]

High-fiving you at next parisRB too ;)

[bryanrite]

Alright! This branch as it is now has been released as cancancan 1.7.0:

https://rubygems.org/gems/cancancan

Please let me know if anyone has any issues with it. It should just drop in, with no code changes.

I'm going to keep this issue open, so people can see we've moved on, but please start posting any issues etc. in the new repo:

https://github.com/bryanrite/cancancan

[willkoehler]

Awesome! Thanks @bryanrite. I'll switch my apps over to cancancan and make sure everything still works. I was using your branch before so it should go smoothly.

Please reach out to me and let me know what I can do to help as issues come up.

[gamov]

Good to see things moving for cancan! What about people (like me) that use cc2.0?

@pokonski I'm also a lover of accessible_by and scopes that cancan provides.

[bryanrite]

@gamov I'm focusing on the 1.x branch for the short term, making sure it is up to date and compatible going forward. I'd also like to spend a bit more time on the test suite and refactoring the code base a little to clean it up. Then I was going to take a look at the 2.x branch. I never used it since it was never actually released and I need to understand what improvements and refinements Ryan was attempting and how, before I feel comfortable moving forward with it.

Pull requests are welcome anytime if there is anyone knowledgable about the 2.x branch.

[pokonski]

@gamov just as an update. I realized thanks to comments in this thread that people still want features like AR integration.

So I'm working on scopes and accessible_by? for my AccessGranted gem to match the functionality of CanCan. Stay tuned :)

[codyolsen]

@bryanrite Thanks for spearheading this reboot. Onward and upward! Quick question: Once the new fork gains traction are you planning on giving merge privileges to additional contributors so that we can help you avoid burn out as well? Excited for the momentum!

[codyolsen]

@pokonski Do you have an estimated timeline or goal date on when you would like to have AR Integration added to AccessGranted?

[bryanrite]

@codyolsen Absolutely, I was gonna setup an open source organization on GitHub and transfer cancancan into it with other maintainers if it catches on and there is some interest.

[codyolsen]

@bryanrite that sounds great! I just added an issue detailing the transition and linking to the new repository. Hopefully that will catch peoples eye and help drive traffic towards the new repo.

[pokonski]

@codyolsen this is what I'm working right now @ https://github.com/pokonski/access-granted-rails I want to have a working version of accessible_by? and scopes for AR and Mongoid/Mongo_Mapper in the next two weeks.

[willkoehler]

@bryanrite I dropped cancancan into two apps that were previously using cancan. The transition has been seamless. All specs pass and it's been live in production now for a few days.

[bryanrite]

:smile:

[elthariel]

Great news ! Good job :D

On Tue, Feb 25, 2014 at 8:01 PM, Bryan Rite [email protected]:

[image: :smile:]

Reply to this email directly or view it on GitHubhttps://github.com/ryanb/cancan/pull/989#issuecomment-36044410 .

[hail2skins]

Just checking here to see if CanCan is still a solution anymore and am happy to see you moving this Bryan. I don't know you, but I'll support your effort and try to use your work and one day maybe help. Appreciate it.

[gamov]

@bryanrite I use cc2 in production for a very long time already. I like it much better than 1.x. There is a few bugs (see open issues) but I could easily work around them.

The only part that I find unfinished (thus unusable) is regarding the resource attributes authorisation. It's not flexible enough as it is (see https://github.com/ryanb/cancan/issues/513).

I'm keen to test and feedback any work on this branch.

PS: Because of some dependencies, I'm stuck on Rails 3.0.20 for now