Future of this gem

[nguyenchiencong]

Is this gem dead?

[bhh]

hope not. i really love the approach.

[nagyt234]

Hope not, too.

[neilbilly]

Same here; when permissions get complex the RBAC model is a good why to go. As far as I'm aware this gem works pretty much just fine. Is there any major/priority work that needs doing here? If so I think we should jump on it and keep this gem evolving.

[sneakernets]

I'd appreciate some work on it since projects I'm working on have had custom implementations - which means everyone is reinventing the wheel here...

[stffn]

It is good that you bring up this point. I'm currently not actively developing and struggle to even keep up with the pull requests. The main challenge to tackle is Rails 4, which I can contribute little on since I don't have a Rails-4 project. Thus, I'd be more than happy to grant contributor status or even transfer ownership in the long term.

[neilbilly]

Hi Steffen, First of all thanks for setting up this project, it must have taken some serious effort and I suspect it's helped many of us. Could you say how much time it's taken to keep something like this running? Like maybe how many hours a week would one be looking at just to keep it ticking over?

[daniel-rikowski]

I'm using decl_auth in both a 4.0 and a 4.1 Rails project without problems, but I'm only using filter_access_to: all with relatively simple rules and not the advanced resource loading features.

I also tried cancan, but as soon as the rules became more complex, I ended up re-implementing a lot of stuff already available in decl_auth.

[stffn]

There is not much day-to-day effort required for maintenance. Testing one pull request per week is probably it. I'd also consider it feature-complete at this point. Thus, development effort is limited to keeping up with Rails and Ruby development. Bringing decl_auth_demo_app to new versions, testing all decl_auth functions against new versions. This is manageable of course, but difficult if one is too distant from Rails/Ruby progress (like I am).

[neilbilly]

Do these ruby/rails combinations sound about right for testing against? Anyone got any other combinations in mind?

@stffn Do you have any views on us rigging up Travis-CI to deal with this?

@daniel-rikowski I'm not sure about Rails 4.1 - is testing needed for it right now? Also any idea which version of ruby it's intended to work with?

MRI 2.1.0

• Rails ~> 4.0
• Rails ~> 3.2

MRI 2.0.0

• Rails ~> 4.0
• Rails ~> 3.2

MRI 1.9.3

• Rails ~> 4.0
• Rails ~> 3.2
• Rails ~> 3.1
• Rails ~> 3.0

MRI 1.9.2

• Rails ~> 3.2
• Rails ~> 3.1
• Rails ~> 3.0

MRI 1.8.7

• Rails ~> 3.2
• Rails ~> 3.1
• Rails ~> 3.0
• Rails ~> 2.3

[daniel-rikowski]

The official Ruby requirement for Rails 4.1 is MRI 1.9.2+, but 2.1 is recommended. (Source: http://rubyonrails.org/download)

If it isn't too much work, I'd test Rails 4.1, too, and make a visible note on the Github page, that the latest Rails version is supported. That would reassure that decl_auth is still on the bleeding edge and not dead at all :)

[neilbilly]

@daniel-rikowski that's a good point, let's give 4.1 a go too. I had checked the rails 4.0 release notes (http://edgeguides.rubyonrails.org/4_0_release_notes.html) and it says ruby 1.9.3+ is required (2.0 preferred) so I assumed the same for rails 4.1. Any thoughts?

[stffn]

Having the CI would be great @neilbilly!

I could imaging that we should deactivate/factor out the development_support tests, since it is non-core functionality.

[neilbilly]

@stffn great, that's good to know; looks like it'll save abit of work, thanks :)

[lukassfranklin]

For the Travis-CI configuration I would appreciate adding Rails 3.1 and 3.0 to the MRI 2.0. Thanks!

[zeiv]

I been working on "porting" this gem to Rails 4 with full support for strong parameters, filter_resource_access, etc. It's been a couple months since I've worked on it but I intend to do some more with it.

If I recall correctly, everything in my fork is working in Rails 4 with backwards compatibility through Rails 2. The problem I have right now is with the tests and making sure everything is behaving as intended (my test-unit isn't as strong as my rspec). If anyone would like to help out with the tests(or the rest of what I've done, for that matter) I'm sure we could get it worked out in no time. See my comments in #183 for more info. I feel like I'm pretty close with what I've done so far, and I would be happy to walk anyone through my changes if it will help someone.

[praser]

@zeiv do you have some news about the work in progress to make this gem compatible with Rails 4? Still needing help with unit test? I'm not that good with them, but I believe I can help some way...

[zeiv]

Hi @praser, Rails 4 support was actually pulled in a few weeks ago (see #196). As far as I know, the changes haven't been pushed to rubygems yet though, so you'll have to install it from GitHub.

[praser]

Nice @zeiv and thanks a lot.

[zekefast]

It is nice to see people started cooperating! Big thanks to all who make the job to update the gem to Rails 4!

It seems to me that you could close that issue now, isn't it?

[klyonrad]

So will the current state of the gem published to rubygems.org?

[zeiv]

Hello friends,

With the advent of Rails 5 and the current state of this gem, I believe it may be time to move on to a new solution for Rails authorization. I and a few others spent a good deal of work refactoring Declarative Authorization for Rails 4 a couple years ago, and I think another major refactor may not be worth the effort given the age and style of the codebase.

However, I am very much a fan of this gem's declarative approach and I think this is probably the best authorization gem out there (many thanks stffn!). Therefore, I have decided rather than to refactor this gem to write a new gem from the ground up based on Declarative Authorization. That way, rather than having to pore through the code on the current gem and change what is necessary, we can write the new gem mirroring Declarative Authorization's functionality but in clean, modern code.

Towards this end, I have started a new project based on Declarative Authorization called Authoreyes (pronounced like "authorize"), which can be found here: https://github.com/tektite-software/authoreyes.

I will definitely need help on this! And to prevent Authoreyes from becoming a a rarely-updated gem like this in 5 years, I think it would be a good idea to have several maintainers. If it is something you are interested in, let me know!

tektite-software/authoreyes

Check out the early development guide.