0
@@ -4,82 +4,134 @@ http://www.writertopia.com/developers/authorization
0
This plugin provides a flexible way to add authorization to Rails.
0
-The authorization process decides whether a user is allowed access to some feature.
0
-It is distinct from the authentication process, which tries to confirm a user is
0
-authentic, not an imposter. There are many authentication systems available for Rails,
0
-e.g., acts_as_authenticated and LoginEngine. This authorization system
0
-will play nicely with them as long as some simple requirements are met:
0
+The authorization process decides whether a user is allowed access to some
0
+feature. It is distinct from the authentication process, which tries to
0
+confirm a user is authentic, not an imposter. There are many authentication
0
+systems available for Rails, e.g., acts_as_authenticated and LoginEngine. This
0
+authorization system will play nicely with them as long as some simple
0
+1. User objects are available that implement a <tt>has_role?(role,
0
+ authorizable_object = nil)</tt> method. This requirement can be easily
0
+ handled by using <tt>acts_as_authorized_user</tt> in the User-like class.
0
+2. If you want to use "role of model" authorization expressions, like "owner of
0
+ resource" or "eligible for :award", then your models with roles must
0
+ implement an <tt>accepts_role?(role, user)</tt> method. This requirement can
0
+ be handled by using <tt>acts_as_authorizable</tt> in the model class.
0
-
1. User objects are available that implement a <tt>has_role?(role, authorizable_object = nil)</tt> method. This requirement can be easily handled by using <tt>acts_as_authorized_user</tt> in the User-like class.0
+
The authorization plugin provides the following:0
-2. If you want to use "role of model" authorization expressions, like "owner of resource" or "eligible for :award", then your models with roles must implement an <tt>accepts_role?(role, user)</tt> method. This requirement can be handled by using <tt>acts_as_authorizable</tt> in the model class.
0
+* A simple way of checking authorization at either the class or instance method
0
+ level using #permit and #permit?
0
-The authorization plugin provides the following:
0
-* A simple way of checking authorization at either the class or instance method level using #permit and #permit?
0
-* Authorization using roles for the entire application, a model class, or an instance of a model (i.e., a particular object).
0
-* Some english-like dynamic methods that draw on the defined roles. You will be able to use methods like "user.is_fan_of angelina" or "angelina.has_fans?", where a 'fan' is only defined in the roles table.
0
-* Pick-and-choose a mixin for your desired level of database complexity. For all the features, you will want to use "object roles table" (see below)
0
+* Authorization using roles for the entire application, a model class, or an
0
+ instance of a model (i.e., a particular object).
0
+* Some english-like dynamic methods that draw on the defined roles. You will be
0
+ able to use methods like "user.is_fan_of angelina" or "angelina.has_fans?",
0
+ where a 'fan' is only defined in the roles table.
0
+* Pick-and-choose a mixin for your desired level of database complexity. For
0
+ all the features, you will want to use "object roles table" (see below)
0
-There are currently two recommended ways of installing the plugin into your Rails application, via Git (Recommended) and a manual install from a .zip file.
0
+There are currently two recommended ways of installing the plugin into your
0
+Rails application, via Git (Recommended) and a manual install from a .zip file.
0
-The source code for this plugin is maintained in a Git SCM repository. This will always have the latest version of the code and is the recommended source for installation. You can install the plugin using Git sub-modules (which are akin to using SVN externals). Installing this way allows you to update the plugin code later if needed (but note that it will not update any generated code created earlier by this plugin, you would need to do that manually).
0
+The source code for this plugin is maintained in a Git SCM repository. This
0
+will always have the latest version of the code and is the recommended source
0
+for installation. You can install the plugin using Git sub-modules (which are
0
+akin to using SVN externals). Installing this way allows you to update the
0
+plugin code later if needed (but note that it will not update any generated
0
+code created earlier by this plugin, you would need to do that manually).
0
From your RAILS_ROOT directory run:
0
git-submodule add git://github.com/DocSavage/rails-authorization-plugin.git vendor/plugins/authorization
0
-You should be able to update this plugin in the future with a simple 'git submodule update' from your rails root.
0
+You should be able to update this plugin in the future with a simple 'git
0
+submodule update' from your rails root.
0
-- Download the latest .zip file of the plugin from RubyForge ( http://rubyforge.org/frs/?group_id=1797 ) and save it to your RAILS_ROOT/vendor/plugins folder.
0
-- Unpack the zip file which should create the directory vendor/plugins/authorization
0
-- Remove the original .zip file.
0
+* Download the latest .zip file of the plugin from RubyForge (
0
+ http://rubyforge.org/frs/?group_id=1797 ) and save it to your
0
+ RAILS_ROOT/vendor/plugins folder.
0
+* Unpack the zip file which should create the directory
0
+ vendor/plugins/authorization
0
+* Remove the original .zip file.
0
== Steps in using the plugin
0
-1. At the top of your config/environment.rb create an AUTHORIZATION_MIXIN constant and set it to "object roles" or "hardwired". (See init.rb in this plugin for how the role support is mixed in.)
0
-2. Make sure your application provides a current_user method or something that returns the current user object. Add the constants in environment.rb to set your authentication system's login page (LOGIN_REQUIRED_REDIRECTION), permission denied page (PERMISSION_DENIED_REDIRECTION) and method for storing the current URL for return after authentication (STORE_LOCATION_METHOD). (See authorization.rb in the plugin's /lib directory for the default values of LOGIN_REQUIRED_REDIRECTION, PERMISSION_DENIED_REDIRECTION and STORE_LOCATION_METHOD.)
0
-3. If you use the "hardwired" mixin, no database use is required. Otherwise, you'll have to generate a role.rb model (and its associated join table with User) by running "script/generate role_model Role" and doing "rake migrate".
0
+1. At the top of your config/environment.rb create an AUTHORIZATION_MIXIN
0
+ constant and set it to "object roles" or "hardwired". (See init.rb in this
0
+ plugin for how the role support is mixed in.)
0
+2. Make sure your application provides a current_user method or something that
0
+ returns the current user object. Add the constants in environment.rb to set
0
+ your authentication system's login page (LOGIN_REQUIRED_REDIRECTION),
0
+ permission denied page (PERMISSION_DENIED_REDIRECTION) and method for
0
+ storing the current URL for return after authentication
0
+ (STORE_LOCATION_METHOD). (See authorization.rb in the plugin's /lib
0
+ directory for the default values of LOGIN_REQUIRED_REDIRECTION,
0
+ PERMISSION_DENIED_REDIRECTION and STORE_LOCATION_METHOD.)
0
+3. If you use the "hardwired" mixin, no database use is required. Otherwise,
0
+ you'll have to generate a role.rb model (and its associated join table with
0
+ User) by running "script/generate role_model Role" and doing "rake migrate".
0
4. Add <tt>acts_as_authorized_user</tt> to your user class.
0
5. Add <tt>acts_as_authorizable</tt> to the models you want to query for roles.
0
== Jumpstarting with a mixin
0
-The Authorization plugin comes with two modules that provide different levels of database support.
0
-Each of the mixins provide the <tt>acts_as_authorized_user</tt> and <tt>acts_as_authorizable</tt>
0
-class methods for your models. If you use one of those declarations, you get methods that handle
0
-authorization with different database schemes. A full test web application is provided for each
0
-of the modules so you can see how they work. The "Object Roles Table" version is recommended for
0
-normal use and is the default.
0
+The Authorization plugin comes with two modules that provide different levels
0
+of database support. Each of the mixins provide the
0
+<tt>acts_as_authorized_user</tt> and <tt>acts_as_authorizable</tt> class
0
+methods for your models. If you use one of those declarations, you get methods
0
+that handle authorization with different database schemes. A full test web
0
+application is provided for each of the modules so you can see how they
0
+work. The "Object Roles Table" version is recommended for normal use and is the
0
-This is the simplest and requires no database. Roles are assumed to be coded into the Model classes
0
-using the <tt>has_role?(role, obj = nil)</tt> method.
0
+This is the simplest and requires no database. Roles are assumed to be coded
0
+into the Model classes using the <tt>has_role?(role, obj = nil)</tt> method.
0
=== 2) Object Roles Table
0
-The Object Roles Table mixin provides full support for authorization expressions within a database by
0
-add a polymorphic field to the Role table. Because roles have polymorphic associations to an
0
-authorizable object, we can assign a user to a role for any model instance. So you could declare user X
0
-to be a moderator for workshop Y, or you could make user A be the owner of resource B.
0
-The identity module adds a number of dynamic methods that use defined roles. The user-like model
0
-gets methods like <tt>user.is_moderator_of group</tt> (sets user to "moderator" of <tt>group</tt>),
0
-<tt>user.is_moderator?</tt> (returns true/false if user has some role "moderator"), and
0
-<tt>group.has_moderators</tt> (returns an array of users that have role "moderator" for the group).
0
-If you prefer not to have these dynamic methods available, you can simply comment out the inclusion
0
-of the identity module within object_roles_table.rb.
0
+The Object Roles Table mixin provides full support for authorization
0
+expressions within a database by add a polymorphic field to the Role
0
+table. Because roles have polymorphic associations to an authorizable object,
0
+we can assign a user to a role for any model instance. So you could declare
0
+user X to be a moderator for workshop Y, or you could make user A be the owner
0
+The identity module adds a number of dynamic methods that use defined
0
+roles. The user-like model gets methods like <tt>user.is_moderator_of
0
+group</tt> (sets user to "moderator" of <tt>group</tt>),
0
+<tt>user.is_moderator?</tt> (returns true/false if user has some role
0
+"moderator"), and <tt>group.has_moderators</tt> (returns an array of users that
0
+have role "moderator" for the group). If you prefer not to have these dynamic
0
+methods available, you can simply comment out the inclusion of the identity
0
+module within object_roles_table.rb.
0
=== Migrations and Testing
0
-Each mixin's test web application comes with migrations to set up the database for the associated mixin.
0
-After reading the Rails Recipe on domain specific languages (DSLs) for testing, I added integration tests
0
-for each mixin test app that use a simple vocabulary for testing authorization. The object_roles_test
0
+Each mixin's test web application comes with migrations to set up the database
0
+for the associated mixin. After reading the Rails Recipe on domain specific
0
+languages (DSLs) for testing, I added integration tests for each mixin test app
0
+that use a simple vocabulary for testing authorization. The object_roles_test
0
application has the most tests. Please contribute tests to improve coverage.
0
@@ -87,90 +139,115 @@ application has the most tests. Please contribute tests to improve coverage.
0
-permit and permit? take an authorization expression and a hash of options
0
-that typically includes any objects that need to be queried:
0
+permit and permit? take an authorization expression and a hash of options that
0
+typically includes any objects that need to be queried:
0
permit <authorization expression> [, options hash ]
0
permit? <authorization expression> [, options hash ]
0
-The difference between permit and permit? is redirection. permit is a declarative
0
-statement and redirects by default. It can also be used as a class or an
0
-instance method, gating the access to an entire controller in a before_filter fashion.
0
+The difference between permit and permit? is redirection. permit is a
0
+declarative statement and redirects by default. It can also be used as a class
0
+or an instance method, gating the access to an entire controller in a
0
-permit? is only an instance method, can be used within expressions, does not redirect by default.
0
+permit? is only an instance method, can be used within expressions, does not
0
-The authorization expression is a boolean expression made up of permitted roles, prepositions,
0
-and authorizable models. Examples include "admin" (User model assumed), "moderator of :workshop"
0
-(looks at options hash and then @workshop), "'top salesman' at :company" (multiword roles delimited
0
-by single quotes), or "scheduled for Exam" (queries class method of Exam).
0
+The authorization expression is a boolean expression made up of permitted
0
+roles, prepositions, and authorizable models. Examples include "admin" (User
0
+model assumed), "moderator of :workshop" (looks at options hash and then
0
+@workshop), "'top salesman' at :company" (multiword roles delimited by single
0
+quotes), or "scheduled for Exam" (queries class method of Exam).
0
-Note that we can use several permitted prepositions ('of', 'for', 'in', 'on', 'to', 'at', 'by'). In the discussion below,
0
-we assume you use the "of" preposition. You can modify the permitted prepositions by changing the constant
0
+Note that we can use several permitted prepositions ('of', 'for', 'in', 'on',
0
+'to', 'at', 'by'). In the discussion below, we assume you use the "of"
0
+preposition. You can modify the permitted prepositions by changing the constant
0
in Authorization::Base::Parser.
0
-* If a specified role has no "of <model>" designation, we assume it is a user role (i.e., the model is the user-like object).
0
-* If an "of model" designation is given but no "model" key/value is supplied in the hash, we check if an instance variable @model if it's available.
0
-* If the model is capitalized, we assume it's a class and query <tt>Model#self.accepts_role?</tt> (the class method) for the permission. (Currently only available in ObjectRolesTable mixin.)
0
+* If a specified role has no "of <model>" designation, we assume it is a user
0
+ role (i.e., the model is the user-like object).
0
+* If an "of model" designation is given but no "model" key/value is supplied in
0
+ the hash, we check if an instance variable @model if it's available.
0
+* If the model is capitalized, we assume it's a class and query
0
+ <tt>Model#self.accepts_role?</tt> (the class method) for the
0
+ permission. (Currently only available in ObjectRolesTable mixin.)
0
For each role, a query is sent to the appropriate model object.
0
The grammar for the authorization expression is:
0
- <expr> ::= (<expr>) | not <expr> | <term> or <expr> | <term> and <expr> | <term>
0
- <term> ::= <role> | <role> <preposition> <model>
0
- <preposition> ::= of | for | in | on | to | at | by
0
- <role> ::= /\w+/ | /'.*'/
0
+ <expr> ::= (<expr>) | not <expr> | <term> or <expr> | <term> and <expr> | <term>
0
+ <term> ::= <role> | <role> <preposition> <model>
0
+ <preposition> ::= of | for | in | on | to | at | by
0
+ <role> ::= /\w+/ | /'.*'/
0
-Parentheses should be used to clarify permissions. Note that you may prefix the model with an optional ":" -- the first versions of Authorization plugin made this mandatory but it's now optional since the mandatory preposition makes models unambiguous.
0
+Parentheses should be used to clarify permissions. Note that you may prefix the
0
+model with an optional ":" -- the first versions of Authorization plugin made
0
+this mandatory but it's now optional since the mandatory preposition makes
0
-<tt>:allow_guests => false</tt>. We can allow permission processing without a current user object. The default is <tt>false</tt>.
0
+<tt>:allow_guests => false</tt>. We can allow permission processing without a
0
+current user object. The default is <tt>false</tt>.
0
<tt>:user</tt> => A <tt>user</tt> object.
0
-<tt>:get_user_method => method</tt> that will return a <tt>user</tt> object. Default is <tt>#current_user</tt>, which is the how <tt>acts_as_authenticated</tt> works.
0
+<tt>:get_user_method => method</tt> that will return a <tt>user</tt>
0
+object. Default is <tt>#current_user</tt>, which is the how
0
+<tt>acts_as_authenticated</tt> works.
0
-<tt>:only => [ :method1, :method2 ]</tt>. Array of methods to apply permit (not valid when used in instance methods)
0
+<tt>:only => [ :method1, :method2 ]</tt>. Array of methods to apply permit (not
0
+valid when used in instance methods)
0
-<tt>:except => [ :method1, :method2 ]</tt>. Array of methods that won't have permission checking (not valid when used in instance methods)
0
+<tt>:except => [ :method1, :method2 ]</tt>. Array of methods that won't have
0
+permission checking (not valid when used in instance methods)
0
-<tt>:redirect => bool</tt>. default is <tt>true</tt>. If <tt>false</tt>, permit will not redirect to denied page.
0
+<tt>:redirect => bool</tt>. default is <tt>true</tt>. If <tt>false</tt>, permit
0
+will not redirect to denied page.
0
-<tt>:login_required_redirection => path or hash</tt> where user will be redirected if not logged in (default is "{ :controller => 'session', :action => 'new' }")
0
+<tt>:login_required_redirection => path or hash</tt> where user will be
0
+redirected if not logged in (default is "{ :controller => 'session', :action =>
0
-<tt>:login_required_message => 'my message'</tt> (default is 'Login is required to access the requested page.')
0
+<tt>:login_required_message => 'my message'</tt> (default is 'Login is required
0
+to access the requested page.')
0
-<tt>:permission_denied_redirection => path or hash</tt> where user will be redirected if logged in but not authorized (default is '')
0
+<tt>:permission_denied_redirection => path or hash</tt> where user will be
0
+redirected if logged in but not authorized (default is '')
0
-<tt>:permission_denied_message => 'my message</tt> (default is 'Permission denied. You cannot access the requested page.')
0
+<tt>:permission_denied_message => 'my message</tt> (default is 'Permission
0
+denied. You cannot access the requested page.')
0
=== Setting and getting the roles
0
-Roles are set by #has_role and #accepts_role methods that are mixed into the User-like object
0
-and the authorizable models. User objects can set roles and optionally an object scope for
0
+Roles are set by #has_role and #accepts_role methods that are mixed into the
0
+User-like object and the authorizable models. User objects can set roles and
0
+optionally an object scope for that role:
0
- user.has_role 'site_admin'
0
- user.has_role 'moderator', group
0
- user.has_no_role 'site_admin'
0
- user.has_no_role 'moderator', group
0
- user.has_role 'member', Group
0
+ user.has_role 'site_admin'
0
+ user.has_role 'moderator', group
0
+ user.has_no_role 'site_admin'
0
+ user.has_no_role 'moderator', group
0
+ user.has_role 'member', Group
0
-Note that the last method sets role "member" on a class "Group". Roles can be set with three
0
-scopes: entire application (no class or object specified), a model class, or an instance of a
0
-model (i.e., a model object).
0
+Note that the last method sets role "member" on a class "Group". Roles can be
0
+set with three scopes: entire application (no class or object specified), a
0
+model class, or an instance of a model (i.e., a model object).
0
Models set roles for specific users:
0
- a_model.accepts_role 'moderator', user
0
- a_model.accepts_no_role 'moderator', user
0
- Model.accepts_role 'class moderator', user
0
+ a_model.accepts_role 'moderator', user
0
+ a_model.accepts_no_role 'moderator', user
0
+ Model.accepts_role 'class moderator', user
0
-The method language has been chosen to aid memory of the argument order. A user has a role "foo",
0
-so the role string immediately follows has_role. Similarly, a model accepts a role "foo", so
0
-the role string immediately follows accepts_role. Then we append the scope.
0
+The method language has been chosen to aid memory of the argument order. A user
0
+has a role "foo", so the role string immediately follows has_role. Similarly, a
0
+model accepts a role "foo", so the role string immediately follows
0
+accepts_role. Then we append the scope.
0
Sometimes the user-like object might be an authorizable object as well, for example, when you
0
allow 'friend' roles for users. In this case, the user-like object can be declared to be
0
@@ -178,24 +255,25 @@ allow 'friend' roles for users. In this case, the user-like object can be declar
0
Role queries follow the same pattern as the setting of roles:
0
- user.has_role? 'moderator'
0
- user.has_role? 'moderator', group
0
- user.has_role? 'member', Group
0
+ user.has_role? 'moderator'
0
+ user.has_role? 'moderator', group
0
+ user.has_role? 'member', Group
0
- a_model.accepts_role? 'moderator', user
0
- Model.accepts_role? 'moderator', user
0
+ a_model.accepts_role? 'moderator', user
0
+ Model.accepts_role? 'moderator', user
0
-When a user is queried without specifying either a model class or object, it returns true if the
0
-user has *any* matching role. For example, <tt>user.has_role? 'moderator'</tt> returns true if
0
-the user is 'moderator' of a class, a model object, or just a generic 'moderator'.
0
-Note that if you say <tt>user.has_role 'moderator'</tt>, the user does not become 'moderator'
0
-for all classes and model objects; the user simply has a generic role 'moderator'.
0
+When a user is queried without specifying either a model class or object, it
0
+returns true if the user has *any* matching role. For example,
0
+<tt>user.has_role? 'moderator'</tt> returns true if the user is 'moderator' of
0
+a class, a model object, or just a generic 'moderator'. Note that if you say
0
+<tt>user.has_role 'moderator'</tt>, the user does not become 'moderator' for
0
+all classes and model objects; the user simply has a generic role 'moderator'.
0
==== Dynamic methods through the Identity mixin
0
-The Object Roles Table version includes some dynamic methods that use the roles table.
0
-For example, if you have roles like "eligible", "moderator", and "owner", you'll be able to
0
+The Object Roles Table version includes some dynamic methods that use the roles
0
+table. For example, if you have roles like "eligible", "moderator", and
0
+"owner", you'll be able to use the following:
0
user.is_eligible_for_what --> returns array of authorizable objects for which user has role "eligible"
0
user.is_moderator_of? group --> returns true/false
0
@@ -207,63 +285,79 @@ Models get has_* methods:
0
group.has_moderators --> returns array of users with role "moderator" on that group
0
group.has_moderators? --> returns true/false
0
-Allowed prepositions are optional in the above dynamic methods. They are simply syntactic sugar.
0
-For example, the following are equivalent:
0
+Allowed prepositions are optional in the above dynamic methods. They are simply
0
+syntactic sugar. For example, the following are equivalent:
0
user.is_member_of group
0
user.is_member_for group
0
-Allowed prepositions are required in the authorization expressions because they are used to distinguish
0
-"role" and "role of :model" and "role of Model".
0
+Allowed prepositions are required in the authorization expressions because they
0
+are used to distinguish "role" and "role of :model" and "role of Model".
0
-If you prefer not to pollute your namespace with these dynamic methods, do not include the
0
-Identity module in <tt>object_roles_table.rb</tt>.
0
+If you prefer not to pollute your namespace with these dynamic methods, do not
0
+include the Identity module in <tt>object_roles_table.rb</tt>.
0
We expect the application to provide the following methods:
0
-Returns some user object, like an instance of my favorite class, <tt>UserFromMars</tt>.
0
-A <tt>user</tt> object, from the Authorization viewpoint, is simply an object that
0
-provides a <tt>has_role?</tt> method.
0
-Note that duck typing means we don't care what else the <tt>UserFromMars</tt> might be doing.
0
-We only care that we can get an id from whatever it is, and we can check if a given
0
-role string is associated with it. By using <tt>acts_as_authorized_user</tt>, we inject what
0
-we need into the user object.
0
+Returns some user object, like an instance of my favorite class,
0
+<tt>UserFromMars</tt>. A <tt>user</tt> object, from the Authorization
0
+viewpoint, is simply an object that provides a <tt>has_role?</tt> method.
0
+Note that duck typing means we don't care what else the <tt>UserFromMars</tt>
0
+might be doing. We only care that we can get an id from whatever it is, and we
0
+can check if a given role string is associated with it. By using
0
+<tt>acts_as_authorized_user</tt>, we inject what we need into the user object.
0
If you use an authorization expression "admin of :foo", we check permission by
0
-asking <tt>foo</tt> if it <tt>accepts_role?('admin', user)</tt>. So for each model that is used in an
0
-expression, we assume that it provides the <tt>accepts_role?(role, user)</tt> method.
0
+asking <tt>foo</tt> if it <tt>accepts_role?('admin', user)</tt>. So for each
0
+model that is used in an expression, we assume that it provides the
0
+<tt>accepts_role?(role, user)</tt> method.
0
Note that <tt>user</tt> can be <tt>nil</tt> if <tt>:allow_guests => true</tt>.
0
==== #store_location (optional)
0
-This method will be called if authorization fails and the user is about to be redirected to
0
-the login action. This allows the application to return to the desired page after login.
0
-If the application doesn't provide this method, the method will not be called.
0
+This method will be called if authorization fails and the user is about to be
0
+redirected to the login action. This allows the application to return to the
0
+desired page after login. If the application doesn't provide this method, the
0
+method will not be called.
0
-The name of the method for storing a location can be modified by changing the constant
0
-STORE_LOCATION_METHOD in environment.rb. Also, the default login and permission denied pages are defined by the
0
-constants LOGIN_REQUIRED_REDIRECTION and PERMISSION_DENIED_REDIRECTION in authorization.rb and can be overriden in your environment.rb.
0
+The name of the method for storing a location can be modified by changing the
0
+constant STORE_LOCATION_METHOD in environment.rb. Also, the default login and
0
+permission denied pages are defined by the constants LOGIN_REQUIRED_REDIRECTION
0
+and PERMISSION_DENIED_REDIRECTION in authorization.rb and can be overriden in
0
Roles specified without the "of model" designation:
0
-1. We see if there is a <tt>current_user</tt> method available that will return a user object. This method can be overridden with the <tt>:user</tt> hash.
0
-2. Once a user object is determined, we pass the role to <tt>user.has_role?</tt> and expect a true return value if the user has the given role.
0
+1. We see if there is a <tt>current_user</tt> method available that will return
0
+ a user object. This method can be overridden with the <tt>:user</tt> hash.
0
+2. Once a user object is determined, we pass the role to
0
+ <tt>user.has_role?</tt> and expect a true return value if the user has the
0
Roles specified with "of model" designation:
0
-1. We attempt to query an object in the options hash that has a matching key. Example: <tt>permit "knight for justice", :justice => @abstract_idea</tt>
0
-2. If there is no object with a matching key, we see if there's a matching instance variable. Example: @meeting defined before we use <tt>permit "moderator of meeting"</tt>
0
-3. Once the model object is determined, we pass the role and user (determined in the manner above) to <tt>model.accepts_role?</tt>
0
+1. We attempt to query an object in the options hash that has a matching
0
+ key. Example: <tt>permit "knight for justice", :justice =>
0
+2. If there is no object with a matching key, we see if there's a matching
0
+ instance variable. Example: @meeting defined before we use <tt>permit
0
+ "moderator of meeting"</tt>
0
-Information on this plugin and other development can be found at http://www.writertopia.com/developers
0
+3. Once the model object is determined, we pass the role and user (determined
0
+ in the manner above) to <tt>model.accepts_role?</tt>
0
+Information on this plugin and other development can be found at
0
+http://www.writertopia.com/developers
Comments
No one has commented yet.