I've used cancan in conjunction with rolify (https://github.com/EppO/rolify/wiki/Tutorial) and been very happy at the simplicity and flexibility. I've also worked with several other 'interpreted' based systems (where roles code is essentially cached in db columns) and found them to be very brittle. Most have them have fallen in to disuse now.
Best, Rob On February 12, 2014 at 9:33:21 , Ben Hughes ([email protected]) wrote: Cancan is really there for access control, not permission management or how you ultimately want to structure roles - all of that is left to the user. It sounds like you're looking for a way to define these permissions, perhaps on a role-level, but that doesn't imply moving away from cancan (or "permit" - similar system) per-say. At the end of the day, something has to check for permissions and do certain things conditionally in your controllers and views. But yes, where these are ultimately defined and managed is not something cancan provides or enforces. I worked on a very large application (250+ models) with database-backed permission definitions that ultimately were dynamically read by cancan's Ability.rb and it's worked out extremely well for us. I was always considering releasing a gem or rails engine that made this generic for anyone wanting to define database-backed permissions in a nice admin interface instead of statically in ability.rb; may still do so, but not quickly enough to help you unfortunately. Not sure if there is anything out there already. On Wed, Feb 12, 2014 at 11:23 AM, Etienne de Bruin <[email protected]> wrote: Passing this question along from a friend. Would appreciate your thoughts. Hope all is well. I have a client I am consulting for that has a multi-tenant rails backend and they're looking to move away from cancan for access control to something more flexible so they can create distinct roles for each tenant and assign arbitrary permissions. Etienne -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
