cream 0.8.6 → 0.8.7

data/wiki/CONFIG_GENERATOR.txt

@@ -1,21 +0,0 @@
-The *config* generator generates a configuration initializer file for setting up `cream` to use a particular role strategy.
-
-<pre>$ rails g cream:config --strategy NAME</pre>
-
-NAME is the name of a role strategy. 
-
-Strategies with a single role for each user
-* admin_field
-* role_string
-* one_role
-
-Strategies with multiple roles for each user
-* roles_mask
-* many_roles
-
-Currently role groups are not supported. Feel free to provide an add-on to support this or integrate with an existing 'role group' solution.  
-
-Example usage:
-
-<pre>$ rails g cream:config --strategy admin_field</pre>
-

data/wiki/DESIGN.txt

@@ -1,21 +0,0 @@
-# Design and plans for the future...
-
-1) Specs for generators
-Currently there are a few generators. I have found some good examples of how to write generator tests (using test_unit) in the rails3-generators project.
-I am porting this to RSpec 2 and will then write generator specs next.
-
-2) New hook-in approach for controller and view methods
-I will change how the methods are added to Rails controllers and views using a new approach I found and used in the Netzke project.
-
-3) Create specs for the custom methods
-4) Create cucumber features for various Role scenarios
-5) Add Mongoid and Mongo Mapper ORM support
-Mongoid currently supported by Devise, and Mongo Mapper will be supported after Rails 3 release I think (have heard?)
-
-6) Add Data Mapper support
-dm-devise project almost done by jm81 as per. July 9, 2010
-
-7) Add support for Canable (jnunemaker), an even simpler permission system alternative to CanCan.
-I already added generators and specs to this gem.
-
-Feel free to suggest other improvements etc ;)

data/wiki/INSTALLATION.txt

@@ -1,6 +0,0 @@
-This gem has been designed for Rails 3 only. Any back port to Rails 2 is most welcome ;)
-
-Insert <pre>gem 'auth-assistant'</pre> in your Rails 3 Gemfile
-
-<pre>$ bundle install</pre>
-

data/wiki/PERMITS.txt

@@ -1,32 +0,0 @@
-Authorization is setup by designing permits for each can of role to do certain actions.
-The config generator generates a default permits.rb file in /lib
-
-Please see "cancan 1.3 wiki":http://wiki.github.com/ryanb/cancan/upgrading-to-13 for more options 
-you can use in designing your Permits. The 'owns' convenience method provided, now uses the new hash option so it
-is also available in the controller using fx:
-
-<pre>Book.accessible_by(current_ability)</pre>
-
-The user can manage any Comment instance if 'user' field on instance points to the user, marking ownership
-<pre>user.owns(Comment)</pre>
-
-Override default 'user_id' field used by owns, to instead use 'author' as ownership key (foreign key) pointing to the user (user.id).  
-<pre>user.owns(Book, :author)</pre>
-
-Example:
-<pre>module RolePermit
-  class Moderator
-    def initialize(ability)
-      super
-    end
-
-    def permit?(user)
-      super
-      return if !user.role?(:moderator)
-      can :read, :all    
-      
-      user.owns(Comment) 
-      user.owns(Book, :author)       
-    end  
-  end
-end</pre>

data/wiki/ROLE_STRATEGIES.txt

@@ -1,40 +0,0 @@
-*Cream* supports single and multiple role strategies. Currently groups are not supported. 
-
-Note: Maybe roles support could be integrated in the future using an existing solution for roles and groups? 
-
-h2. Single role per user
-
-* admin_field 
-* role_field (role : string in users table)
-* role_assignment (role_id -> role.id)
-
-h3. admin_field
-Uses the field *admin : boolean* in the _users_ table
-
-h3. role_field
-Uses the field *role : string* in the _users_ table
-
-h3. role_assignment
-Uses the field *role_id :integer* in the _users_ table. 
-A _roles_ table has id and name fields, where name is the name of the role.
-`users.role_id` points to `role.id` in a 1-M relation. 
-
-Many (M) users can have the same (1) role. Any user can however only have a single role.
-
-h2. Multiple roles per user
-* roles mask
-* roles_field 
-* multi_role_assignment
-
-h3. roles mask
-Uses the field *role_masks : integer* in the _users_ table.
-Each bit of the integer matches a given role.
-
-h3. roles_field
-Uses the field *roles : string* in the _users_ table.
-Currently "experimental".
-
-h3. multi_role_assignment
-Uses the field *role_assignment_id : integer* in the _users_ table.
-A _roles_ table has id and name fields, where name is the name of the role.
-A _role_assignments_ table has _role_id_ and _user_id_ fields, linking the assignment to a user in the users table and a role in the roles table.

data/wiki/SPEC_NOTES.txt

@@ -1,6 +0,0 @@
-# Notes and Status
-
-Currently these specs are a work in progress. 
-I am first building up a skeleton structure for the specs and then plan to gradually implement them as described in the DESIGN.txt document :)
-
-You are most welcome to help in the effort!

data/wiki/VIEWS_GENERATOR.txt

@@ -1,35 +0,0 @@
-The `views` generator generates views (partials) for use with menus.
-
-It is sometimes the case that you want to have menu items in a main navigation menu that enable the user to log in/out, register a new user account or edit an existing user account. The menu items partials ensure that these menuitems are only shown as appropriate in relation to the current user login status, so that log out and edit account is only shown if the user is currently logged in and vice-versa.   
-
-<pre>$ rails g cream:views</pre>
-
-Create HAML views
-
-<pre>$ rails g cream:views --template_engine haml</pre>
-
-Example usage:
-<pre>ul.menu
-    render 'cream/login_items'                              
-    render 'cream/registration_items'
-
-  ul.admin_menu_
-    render 'cream/admin_login_items'</pre>
-    
-    
-<pre>module RolePermit
-  class Moderator
-    def initialize(ability)
-      super
-    end
-
-
-    def permit?(user)
-      super
-      return if !user.role?(:moderator)
-      can :read, :all
-      user.owns(Comment)
-      user.owns(Book, :author)
-    end
-  end
-end</pre>

data/wiki/VIEW_HELPERS.txt

@@ -1,162 +0,0 @@
-## View helpers ##
-
-Currently the view helpers only target use with devise and cancan.
-The default labels are always loaded from the `cream` locale file, which is generated by the `config` generator.
-
-### Rest link helpers ###
-
-Display a link (anchor tag) for a given object only if the current user has permission to execute that action.
-
-* show_link or read_link
-* edit_link or update_link
-* create_link or new_link
-* destroy_link or delete_link
-
-Each Rest helper method takes an object for which to create the link. Optionally provide a label as the second argument. 
-
-Example usage:
-
-<%= create_link project %>
-<%= create_link project, 'Create new project' %>
-
-### Session link helpers ###
-
-Show links for performing user authentication and registration actions 
-
-* log_out_link or sign_out_link
-* log_in_link or sign_in_link  
-
-Each of these methods take an optional options hash. 
-If no role option given, they default to create link for basic 'user' role.
-
-Example usage:
-
-<%= log_out_link %> 
-<%= log_out_link :label => 'Log me out' %>
-<%= log_out_link :role => 'admin', :label => 'Log me out' %>
-
-
-### Registration link helpers ###
-
-Show links for performing user authentication and registration actions 
-
-* register_link or sign_up_link    
-* edit_profile_link or edit_registration_link   
-
-Each of these methods take an optional options hash. 
-If no role option given, they default to create link for basic 'user' role.
-
-Example usage:
-
-<%= register_link %> 
-<%= register_link :label => 'Register me' %>
-<%= register_link :role => 'admin', :label => 'Register me' %>
-
-### Registration Menu item helpers ###
-
-Show menu links for registration conditionally
-
-* edit_user_menu_item or edit_registration_menu_item   
-* register_menu_item or sign_up_menu_item
-
-1) only shown if user is currently logged in
-2) only shown if user is NOT currently logged in (and hence already registered)
-
-Example usage:
-
-ul.menu
-  <%= register_menu_item %> 
-
-### Session Menu item helpers ###
-
-Show menu links for session operations conditionally
-
-* logout_menu_item or sign_out_menu_item 
-* login_menu_item or sign_in_menu_item 
-                                      
-1) only shown if user is currently logged in
-2) only shown if user is NOT currently logged in
-
-ul.menu
-  <%= login_menu_item %> 
-  <%= logout_menu_item %> 
-
-
-## Block helpers ##
-
-Execute block if user is logged in (or not logged in)
-* user_block
-* not_user_block
-
-Execute block if user is logged and is admin (or not admin)
-* admin_block
-* not_admin_block
-
-Execute block if ip is localhost (or not localhost)
-* localhost_block
-* not_localhost_block
-  
-Execute block if role is included in list of roles (or not)
-* roles_block
-* not_roles_block
-
-## Block area helpers ##
-
-Create div.user 'area' and execute block if user is logged in as a user (or not) 
-
-* user_area
-* not_user_area
-
-Create div.admin 'area' and execute block if user is admin (or not admin)
-
-* admin_area
-* not_admin_area
-
-Example:
-<pre>
-<% admin_area do %> 
-  ul.admin_menu
-  ...
-
-If logged in as admin, results in:
-
-div.admin
-  ul.admin_menu  
-   ...
-</pre>
-
-## Roles block area helpers ##
-
-Creates are if role is one included in list of roles (or not)
-
-* roles_area
-* not_roles_area
-
-Example:
-<pre>
-<% roles_area 'admin, 'editor', :class => 'special' do %> 
-  ul.admin_menu
-  ...
-  
-If logged in as either 'editor' or 'admin', results in:
-
-div.special
-  ul.admin_menu  
-   ...
-    
-</pre>
-
-## Misc helpers ##
-
-* user? - 
-* admin?
-* role?
-* localhost?
-
-Examples
-<pre>     
-<%= current_user.username if user? %>
-<%= "Admin: #{current_user.username}" if admin? %>  
-<%= "Special user!" if role?('admin', 'reviewer') %>  
-<%= "Running on localhost!" if localhost? %>  
-</pre>