-
Notifications
You must be signed in to change notification settings - Fork 0
Lineage
Implemented an authorization system at ProfitStreams.
Initially, the cancan gem was integrated and used to make user role-based authorization checks.
However, the product team and business analysts communicated a system where some permissions are authorized from a user's role(s), some permissions are authorized from the products assigned to a business, and some permissions are authorized only when authorized by both the user's role(s) and the business's products.
A code smell began to emerge where presentation checks on view elements, and action checks in controllers, became compound conditionals :
can(:view, MarketingCampaign) && current_business.products.include?(:marketing_campaigns)
The permissify library and specification interfaces where created to address this code smell and provide a mechanism which matched the way upstream collaborators viewed the application.
The then-library remained unchanged through many releases, and
- new abilities introduced with new releases
- associated role, product seeding additions, and other seeding changes
Original implementation : ruby 1.8.7, rails 2.3.5, not a gem : just a subdirectory under /lib
Chose to extract permissify from ProfitStreams code base (I was authorized to do this :) as a means to publish my first gem and get my feet wet with rails 3.2. Extracted/gem-ified code, created generators, made adjustments for rails 2.3.5 --> 3.2.3, other refinements.
Initial, ready-for-some-other-app-to-try-to-use gem implementation : version 0.1.0, MySQL db, ruby 1.8.7, rails 3.2.3, tested with FF 14.0.1
Next : Usage