activeaclplus 0.3.1 → 0.4.0

data/CHANGELOG

@@ -1,5 +1,17 @@
 ActiveAcl rails authorization system
 
+Version 0.4.0 - 2008/03/08
+- complete rewrite of the SQL generation
+- abstraction of the grouping
+- added #grant_privilege
+- dropped test, moving to rspec
+- allows ungrouped requesters/targets
+- propper namespace handling of options (THANKS http://github.com/garytaylor)
+
+Version 0.3.1 - 2008/12/11
+- forgot active_acl.rb in gem
+- fixed generator
+
 Version 0.3.0 - 2008/12/07
 - Renamed Project to ActiveACLPlus
 - code cleanup

data/README.rdoc

@@ -2,7 +2,8 @@
 The ActiveAclPlus plugin implements a flexible, fast and easy to use generic access control system.
 
 ==License
-ActiveAclPlus is released under the LGPL[http://www.opensource.org/licenses/lgpl-license.php] (Gnu Lesser General Public License) - see the included LICENSE file, too.
+ActiveAclPlus is released under the LGPL[http://www.opensource.org/licenses/lgpl-license.php]
+(Gnu Lesser General Public License) - see the included LICENSE file, too.
 
 ==Features
 * ease of use - uses polymorphic collections for associations.
@@ -10,11 +11,10 @@ ActiveAclPlus is released under the LGPL[http://www.opensource.org/licenses/lgpl
 * scalable - there are no real benchmarks yet. But the system design is based on http://phpgacl.sourceforge.net, adding object orientation, polymorphism and two levels of caching. PhpGacl claims "A real-world working version with many added layers of complexity supports over 60,000 Accounts, 200 Groups and 300 ACO's." Tests on my dev notebook show 10 - 30 times performance improvements compared to active_rbac.
 * caching - uses instance caching and optionally stores permission results in memcached using timeouts.
 * flexible - grants simple (2D, like <code>current_user.has_permission?(User::LOGIN)</code>) and object level (3D, like <code>admin.has_permission?(Forum::ADMIN, :on => team_forum)</code>) permissions. Can assign and request permissions to and from every ActiveRecord model. No "hardcoded" permissions - all permissions can be assigned at runtime.
-* grouping - permissions are inherited at target and requester side through groups. Every model implementing an SQL nested set tree may be used as a group.
+* grouping - permissions can be inherited at target and requester side through groups. Every model implementing an SQL nested set tree may be used as a group.
 * ControllerAction model loader: It maps controller actions to the DB so they can be used in permission assignment. The access object is available via calling <code>current_action</code> on the controller.
 * exchangeable DB interface: ActiveRecord and direct MySQL adapter available
 * supports namespaced models and single table inheritance (STI)
-* 100 % C0 code coverage on unit tests
 
 ==Limitations
 * At present only one grouping type per model is supported. This could be changed on request but I don't see a use case for it yet.
@@ -25,41 +25,76 @@ ActiveAclPlus is released under the LGPL[http://www.opensource.org/licenses/lgpl
 ActiveAclPlus uses the has_many_polymorphs[http://www.agilewebdevelopment.com/plugins/restful_authentication] plugin. Make shure you've got a recent version, old versions have bugs affecting active_acl_plus. 
 !!Be sure you have the paches for 2.1, see: http://rubyforge.org/forum/forum.php?thread_id=26041&forum_id=16450
 
-./script/plugin install git://github.com/popel/active_acl_plus.git
+  ./script/plugin install git://github.com/popel/active_acl_plus.git
 
-generators XXX
+or
 
+  sudo gem install activeaclplus
+
+or from a github repository.
+ 
+If you want to use grouped access objects you should install some kind of nested_set plugin
+(awesome_nested_set,better_nested_set,...).
 ==Short summary
-The ActiveAclPlus system consists of access objects, organized by access groups, that request privileges on each other. Allowing or denying access to a privilege is controlled by ACL (access control list entry) objects. Access objects and access groups can be instances of arbitrary ActiveRecord model classes enhanced by acts_as_access_object and acts_as_access_group. They are associated to ACL entries via polymorphic associations.
+The ActiveAclPlus system consists of access objects, which can be organized by access groups, 
+that request privileges on each other. Allowing or denying access to a privilege is controlled by 
+ACL (access control list entry) objects. Access objects and access groups can be instances of arbitrary
+ActiveRecord model classes enhanced by acts_as_access_object and acts_as_access_group. They are associated
+to ACL entries via polymorphic associations.
 
 ===Access objects
-These are basically requesters and targets in the permission system, as for example a User or a Forum model object. In this case a user could act as a requester ("do I have privilege Y?") or target ("does access object X have privilege Y on me?"). A Forum would most certainly be only used as a target, but all access objects can theoretically be used as both requesters and targets. Access objects use the acts_as_access_object macro inside their definition. This registers the model with the ACL system and enhances it with methods like has_privilege?.
+These are basically requesters and targets in the permission system, as for example a User or a Forum model object.
+In this case a user could act as a requester ("do I have privilege Y?") or target ("does access object X have
+privilege Y on me?"). A Forum would most certainly be only used as a target, but all access objects can theoretically
+be used as both requesters and targets. Access objects use the acts_as_access_object macro inside their definition.
+This registers the model with the ACL system and enhances it with methods like has_privilege?.
 
-Every model class must specify an association that is used as the "grouping type" to it. So User may declare has_and_belongs_to_many :user_groups and use acts_as_access_object :grouped_by => :user_groups. You can use a has_and_belongs_to_many or a belongs_to association for this. Common mapping attributes (:join_table, :foreign_key etc.) are supported.
+See: ActiveAcl::Acts::AccessObject::ClassMethods, ActiveAcl::Acts::AccessObject::InstanceMethods,
+ActiveAcl::Acts::AccessObject::SingletonMethods, ActiveAcl::Acts::Grant
 
 
-===Access groups
-The access group model needs to implement a tree with nested set semantics having a "left" and "right" column, e.g. by using the built-in acts_as_nested_set or the much more recommended acts_as_betted_nested_set plugin. Groups are declared with acts_as_access_group. 
+Every access object class can specify an association that is used as the "grouping type" to it. So User may declare
+has_and_belongs_to_many :user_groups and use acts_as_access_object :grouped_by => :user_groups. You can use
+ a has_and_belongs_to_many or a belongs_to association for this. Common mapping attributes
+ (:join_table, :foreign_key etc.) are supported.
 
-Groups may be used to specify inheritance hierarchies for permissions. So you could have a 'registered users' group as a subgroup of the 'users' group and assign the privilege to log in to this group via an ACL entry. Every user belonging to this group will now be granted the privilege to log in. Then you could add a subgroup to registerd users, 'banned users', and deny the log in privilege for this group. Every user added to this group would now be unable to log in, regardless of beeing in 'registered users' or not, as 'banned users' would override the permission settings of 'registered users'.
+===Access groups
+The access group model needs to implement a tree with nested set semantics having a "left" and "right"
+column, e.g. by using the built-in acts_as_nested_set or the much more recommended acts_as_betted_nested_set
+plugin. Groups are declared with acts_as_access_group. 
 
+Groups may be used to specify inheritance hierarchies for permissions. So you could have a 'registered users'
+group as a subgroup of the 'users' group and assign the privilege to log in to this group via an ACL entry.
+Every user belonging to this group will now be granted the privilege to log in. Then you could add a subgroup
+to registerd users, 'banned users', and deny the log in privilege for this group. Every user added to this
+group would now be unable to log in, regardless of beeing in 'registered users' or not, as 'banned users' would
+override the permission settings of 'registered users'.
 
 ===Privileges
-A privilege object is an object for the thing we wish to define a permission for. So User::LOGIN could be a privilege object for checking a users permission to log in, while Forum::ADMIN might define administration rights on a forum.
-
-A privilege object itself is little more than it’s name and id and is usually bound to a constant inside the application, as it is not expected to change at runtime. Privileges are usually created by the developer in the source code and not in the admin frontend, as creating new privilege objects that have no meaning (by code that checks for them) would be pointless.
+A privilege object is an object for the thing we wish to define a permission for. So User::LOGIN could be a
+privilege object for checking a users permission to log in, while Forum::ADMIN might define administration rights on a forum.
 
+A privilege object itself is little more than it’s name and id and is usually bound to a constant inside the
+application, as it is not expected to change at runtime. Privileges are usually created by the developer in
+the source code and not in the admin frontend, as creating new privilege objects that have no meaning (by code
+that checks for them) would be pointless.
 
 ===Access Control List (ACL) entries
-ACL entries are the glue between all these objects, defining which requesters and requester groups have access to which privileges, optionally defining target objects and target groups as well. ACL entries are organized by ACL sections, for better overview in the admin screens. 
-
+ACL entries are the glue between all these objects, defining which requesters and requester groups have access
+to which privileges, optionally defining target objects and target groups as well. ACL entries are organized by
+ACL sections, for better overview in the admin screens. 
 
 ==Usage
 ===In short
-"No access defined" for a privilege evaluates to "deny". This may be overriden by an explicit "allow" or "deny". Privileges are inherited in requestor and target groups, this means you can override them in subgroups again. Privileges directly assigned to an object always supercede those assigned to groups. 
+"No access defined" for a privilege evaluates to "deny". This may be overriden by an explicit "allow" or "deny".
+Privileges are inherited in requestor and target groups, this means you can override them in subgroups again.
+Privileges directly assigned to an object always supercede those assigned to groups. 
 
 ===Simple (2D) permissions
-We want all registered users to be able to log in. We create the User model, the UserGroup model and the User::LOGIN privilege object as described above. Then we create a new ACL entry, set 'allow' to true, add the "registered users" group as requester group, User::LOGIN as privilege and we are done. Every user assigned to "registered users" or a subgroup of it will now be granted access by calling <code>my_user.has_privilege?(User::LOGIN)</code>. 
+We want all registered users to be able to log in. We create the User model, the UserGroup model and the
+User::LOGIN privilege object as described above. Then we create a new ACL entry, set 'allow' to true, add
+the "registered users" group as requester group, User::LOGIN as privilege and we are done. Every user assigned
+to "registered users" or a subgroup of it will now be granted access by calling <code>my_user.has_privilege?(User::LOGIN)</code>. 
 
 ====Simple permissions example
 
@@ -78,22 +113,29 @@ We want all registered users to be able to log in. We create the User model, the
   # assume 'registered_users' exists and users 'john' and 'dr_evil' are members of it but 'anonymous' is not. 
   registered_users = UserGroup.find_by_name('registered_users')
 
+the hard way:
   acl = ActiveAcl::Acl.create :section => ActiveAcl::AclSection.create(:description => 'users')
 
   acl.allow = true # true is default
   acl.privileges << User::LOGIN
-  acl.note="login"
+  acl.iname="login"
   acl.save
 
   acl.requester_groups << registered_users
 
+or much easier:
+  
+  registered_users.grant_privilege!(User::LOGIN,:section_name => 'users',:acl_name => 'login')
+
   john.has_privilege?(User::LOGIN) #=> true
   dr_evil.has_privilege?(User::LOGIN) #=> true
 
   anonymous.has_privilege?(User::LOGIN) #=> false
 
 ===Overriding permissions
-We want to ban specific users from our site. We create another ACL entry, assign the User::LOGIN privilege object, set 'allow' to false and then assign these users as requesters to the ACL entry. The direct permission assignment on the objects overrides the 'allow login' ACL entry from above.
+We want to ban specific users from our site. We create another ACL entry, assign the User::LOGIN privilege
+object, set 'allow' to false and then assign these users as requesters to the ACL entry. The direct
+permission assignment on the objects overrides the 'allow login' ACL entry from above.
 
 ====Overriding permissions example
 
@@ -109,11 +151,17 @@ We want to ban specific users from our site. We create another ACL entry, assign
   dr_evil.has_privilege?(User::LOGIN) #=> false
 
 ===Object level (3D) permissions
-We want to assign forum permissions. We have several privileges (Forum::ADMIN, Forum::READ, Forum::POST etc.), the afore mentioned User and UserGroup models as well as a Forum and a Category model for grouping the forums. 
+We want to assign forum permissions. We have several privileges (Forum::ADMIN, Forum::READ, Forum::POST etc.),
+the afore mentioned User and UserGroup models as well as a Forum and a Category model for grouping the forums. 
 
-If we want to check if a certain user may read in a certain forum, it is not sufficient to check <code>test_user.has_privilege?(Forum::READ)</code> as the target object - in this case a forum - is needed to make a decision. The code to do the check is like <code>test_user.has_privilege?(Forum::READ, :on => teamforum)</code>. 
+If we want to check if a certain user may read in a certain forum, it is not sufficient to check
+<code>test_user.has_privilege?(Forum::READ)</code> as the target object - in this case a forum - is needed
+to make a decision. The code to do the check is like <code>test_user.has_privilege?(Forum::READ, :on => teamforum)</code>. 
 
-To make this work you create a new ACL entry, add Forum::POST and Forum::READ as privileges, set 'allow' to true, add the registered users group as a requester group and the public forums category as a target group to the acl. Now every user belonging to the registered users group or a subgroup of it gains post and read privileges on all forums of the public forums category or a subcategory of it. 
+To make this work you create a new ACL entry, add Forum::POST and Forum::READ as privileges, set 'allow' to
+true, add the registered users group as a requester group and the public forums category as a target group
+to the acl. Now every user belonging to the registered users group or a subgroup of it gains post and read
+privileges on all forums of the public forums category or a subcategory of it. 
 
 ====Object level permissions example
 
@@ -152,43 +200,71 @@ To make this work you create a new ACL entry, add Forum::POST and Forum::READ as
   anonymous.has_privilege?(Forum::READ, :on => speakers) #=> false
 
 ==CAUTION
-Do not create ACL entries that are on different branches of the inheritance hierarchy and have allow/deny set differently on the same privilege objects. This way it's impossible to tell which permission should take precedence. At present this is by creation date, later entries superceding older ones, but this is most certainly not what you want. 
-
-Error checking for conflicting ACL entries is high up on the ToDo list.
+Do not create ACL entries that are on different branches of the inheritance hierarchy and have
+allow/deny set differently on the same privilege objects. This way it's impossible to tell which
+permission should take precedence. At present this is by creation date, later entries superceding older
+ones, but this is most certainly not what you want. 
 
 ==Controller Actions
-Defining permissions on controller actions (like "may user x execute AdminController.list ?") is quite a common case but we are facing a problem here: Controller actions have no corresponding DB models so permissions on them can't be easily defined. 
+Defining permissions on controller actions (like "may user x execute AdminController.list ?") is quite a
+common case but we are facing a problem here: Controller actions have no corresponding DB models so
+permissions on them can't be easily defined. 
 
-ActiveAclPlus solves this by adding a ControllerAction and ControllerGroup model. For every public controller method (=action) there is one ControllerAction object in the DB.
+ActiveAclPlus solves this by adding a ControllerAction and ControllerGroup model. For every public
+controller method (=action) there is one ControllerAction object in the DB.
 
-On application startup, the plugin loader checks all controller files in app/controllers and loads or creates a ControllerAction object for every action it finds. These objects get cached in a hash in the ActiveAclPlus module. Every controller now has a method <code>current_action</code> that looks up and returns the access object for the current action, so it can be used for access checks like <code>current_user.has_privilege?(ActiveAcl::ControllerAction::EXECUTE, :on => current_action)</code>.
+On application startup, the plugin loader checks all controller files in app/controllers and loads
+or creates a ControllerAction object for every action it finds. These objects get cached in a hash
+in the ActiveAclPlus module. Every controller now has a method <code>current_action</code> that looks
+up and returns the access object for the current action, so it can be used for access checks like
+<code>current_user.has_privilege?(ActiveAcl::ControllerAction::EXECUTE, :on => current_action)</code>.
 
 This works nicely for before_filters with authorization checks. 
 
-A word on the load mechanism: If the action has no corresponding DB entry (it's looked up on method creation by controller and action name) the loader searches for a controller group with the same name as the controller. If it is found, the action is created and assigned to this group. Else the controller group is created as a subgroup to the "unassigned controller actions" group (this name can be changed in the options) and the unassigned action is added to the controller group.
+A word on the load mechanism: If the action has no corresponding DB entry (it's looked up on method creation
+by controller and action name) the loader searches for a controller group with the same name as the
+controller. If it is found, the action is created and assigned to this group. Else the controller group
+is created as a subgroup to the "unassigned controller actions" group (this name can be changed in the
+options) and the unassigned action is added to the controller group.
 
-So you are free on how to organize your controllers. Maybe create an admin group and a public group and move controllers as a subgroup inside them?
+So you are free on how to organize your controllers. Maybe create an admin group and a public group and
+move controllers as a subgroup inside them?
 
 ==Caching
-The plugin provides two levels of caching. The instance cache is a hash inside the access object. The object first tries to serve a permission request from the instance cache. If it is not found and a simple permission is requested, the query fetches all simple permissions of the object and puts them in the instance cache. The reason for this is that there is no noticable speed penalty in fetching all 2D permissions at once compared to fetching only one, so this will save time and DB IO later on. Complex 3D queries are fetched independently and also saved to the instance cache. The instance cache lives inside the access object, so it has it's lifetime, too - which in rails usually is no more than a single request.
-
-The second level cache tries to overcome this limitation by putting the instance cache of an access object in an external cache. It tries to get the instance cache from there if it is not set, and sets it if it was changed. The only real implementation for now is with the memcache daemon. The second level cache uses a timeout (which can be defined in the options) to expire the cached permissions. 
-
-Instance and second level cache can be expired explicitly by calling <code>clear_cached_permissions</code> on the access object. Calling <code>reload</code> on the object also purges the caches.
+The plugin provides two levels of caching. The instance cache is a hash inside the access object. The object
+first tries to serve a permission request from the instance cache. If it is not found and a simple permission
+is requested, the query fetches all simple permissions (2D) of the object and puts them in the instance cache. The
+reason for this is that there is no noticable speed penalty in fetching all 2D permissions at once compared to
+fetching only one, so this will save time and DB IO later on. Complex 3D queries are fetched independently
+and also saved to the instance cache. The instance cache lives inside the access object, so it has it's
+lifetime, too - which in rails usually is no more than a single request.
+
+The second level cache tries to overcome this limitation by putting the instance cache of an access object
+in an external cache. It tries to get the instance cache from there if it is not set, and sets it if it was
+changed. The only real implementation for now is with the memcache daemon. The second level cache uses a timeout
+(which can be defined in the options) to expire the cached permissions. 
+
+Instance and second level cache can be expired explicitly by calling <code>active_acl_clear_cache!</code>
+on the access object. Calling <code>reload</code> on the object also purges the caches.
 
 See ActiveAcl::Cache::MemcacheAdapter on how to set it up.
 
 
 ==Preloader
-The plugin includes a <code>load_files_from filenames</code> function. It can be used to preload source files (and therefore the classes in it) from an application path and should be used from environment.rb.
+The plugin includes a <code>load_files_from filenames</code> function. It can be used to preload source files
+(and therefore the classes in it) from an application path and should be used from environment.rb.
 
   load_files_from("#{RAILS_ROOT}/app/controllers/**/[^.]*.rb")
   load_files_from("#{RAILS_ROOT}/app/models/**/[^.]*.rb")
 
-will load all models and controllers inside these folders and their subfolders. This way you can be shure they are registered with the ACL system at rails boot time - else they will be registered when they are called for the first time. This means that new controllers will not show up in the admin screens until they were accessed if not using the preloader.
+will load all models and controllers inside these folders and their subfolders. This way you can be shure they
+are registered with the ACL system at rails boot time - else they will be registered when they are called for
+the first time. This means that new controllers will not show up in the admin screens until they were accessed
+if not using the preloader.
 
 ==Options
-<code>ActiveAcl::OPTIONS</code> is an array that can be used to override various options for the system by setting the values in environment.rb. <code>ActiveAcl::DEFAULT_OPTIONS</code> is as follows:
+<code>ActiveAcl::OPTIONS</code> is an array that can be used to override various options for the system by setting
+the values in environment.rb. <code>ActiveAcl::DEFAULT_OPTIONS</code> is as follows:
 
   DEFAULT_OPTIONS = {
     :acl_sections_table => 'acl_sections',
@@ -202,7 +278,8 @@ will load all models and controllers inside these folders and their subfolders.
     :controller_actions_table => 'controller_actions',
     :controller_groups_table => 'controller_groups',
   
-    :controllers_group_name => 'unassigned_controller_actions', # the name of the base group that newly created controller groups get assigned to
+    :controllers_group_name => 'unassigned_controller_actions', # the name of the base group
+                                                                # that newly created controller groups get assigned to
     :controller_group_name_suffix => '_controller', # name suffix for generated controller groups
   
     :cache_permission_timeout => 10, # timeout in seconds for the second level cache
@@ -212,30 +289,29 @@ will load all models and controllers inside these folders and their subfolders.
   }
 
 ==Tests
-See: http://github.com/popel/active_acl_plus_test/tree/master for more info.
+Not anymore, sorry. I'm using RSpec for testing. A repository
+is/will be setup at http://github.com/popel/active_acl_plus_rspec/tree/master . Check it out and move it to "spec". Run 
+  rake spec
 
 ==Credits
 * Gregor Melhorn implemented this and maintained it up to Version 0.2.1. Thanks for releasing this!
-* Evan for writing that great polymorph plugin and beeing so kind to add namespace and tablename support on my request. 
+* Evan for writing that great polymorph plugin and beeing so kind to add namespace and tablename support on Gregor's request. 
 * ReinH and markmeves for great support and suggestions at the rubyonrails channel on freenode.org.
 * http://phpgacl.sourceforge.net as a great source of inspiration
-* Obrie for writing plugin_migrations and loaded_plugins and also very nice support when I got stuck with using them.
+* Obrie for writing plugin_migrations and loaded_plugins and also very nice support when Gregor got stuck with using them.
 
 ==ToDo/Ideas
 
 in no particular order, just a reminder...
 
+* add materialized_tree_support 
+* use Moneta as key/value store
 * direct PostgreSQL interface
-* example on how to integrate with acts_as_authenticated
+* example on how to integrate with authentication
 * example on controller actions
-* make grouping optional
-* add interface generators (started)
 * error checking for conflicting ACL entries
-* permissions should have more attributes (like :until,:left_boni,...)
 * get all permissions for a requester within a section
 * get all permissions of a requester (with one query)
 * get all permissions of a requester on a target (with one query)
 * get all requester with a given privilege on a target (one query)
 * get all targets on which a requester has a certain privilege (one query)
-
-

data/Rakefile

@@ -18,13 +18,8 @@ Rake::GemPackageTask.new(PKG_GEM) do |p|
   p.need_zip = true
 end
 
-desc 'Default: run unit tests.'
-task :default => :test
-
-#desc "Publish the beta gem"
-#task :pgem => [:package] do
-#  Rake::SshFilePublisher.new("pluginaweek@pluginaweek.org", "/home/pluginaweek/gems.pluginaweek.org/gems", "pkg", "#{PKG_FILE_NAME}.gem").upload
-#end
+desc 'Default: run specs'
+task :default => :spec
 
 desc "Publish the API documentation"
 task :pdoc => [:rdoc] do
@@ -67,11 +62,16 @@ task :coverage_diff do
   sh "#{RCOV} --rails -T -Ilib -x db/**/* --text-coverage-diff ../../../coverage/active_acl/coverage.info --output ../../../coverage/active_acl test/all_tests.rb"
 end
 
-desc 'Test the active_acl_plus plugin.'
-Rake::TestTask.new(:test) do |t|
-  t.libs << 'lib'
-  t.pattern = 'test/unit/**/*_test.rb'
-  t.verbose = true
+begin #no spec or spec-rails? ok no tasks
+  require 'spec/rake/spectask'
+  
+  desc 'Test the active_acl_plus plugin.'
+  Spec::Rake::SpecTask.new(:spec) do |t|
+    #t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
+    t.spec_files = FileList['spec/**/*_spec.rb']
+  end
+rescue LoadError => e
+  puts "No spec tasks! - gem install rspec-rails (#{__FILE__})"
 end
 
 desc 'Generate documentation for the active_acl_plus plugin.'
@@ -79,6 +79,5 @@ Rake::RDocTask.new(:rdoc) do |rdoc|
   rdoc.rdoc_dir = 'rdoc'
   rdoc.title    = 'ActiveAclPlus'
   rdoc.options << '--line-numbers' << '--inline-source'
-  rdoc.rdoc_files.include('README')
-  rdoc.rdoc_files.include('lib/**/*.rb')
+  rdoc.rdoc_files.include('README.rdoc','lib/**/*.rb','app/**/*.rb')
 end

data/{generators/active_acl/templates → app}/controllers/privileges_controller.rb

@@ -1,4 +1,4 @@
-class <%= privileges_class_name %> < ApplicationController  
+class PrivilegesController < ApplicationController  
   verify :method => :post, :only => [ :create, :update],
        :redirect_to => { :action => :list }
   

data/{lib → app/models}/active_acl/acl.rb

@@ -14,8 +14,8 @@ module ActiveAcl
     has_many :requester_group_links, :dependent => :delete_all,:class_name => 'ActiveAcl::RequesterGroupLink'
     has_many :target_group_links, :dependent => :delete_all,:class_name => 'ActiveAcl::TargetGroupLink'
 
-    validates_uniqueness_of :note
-    validates_presence_of :note
+    validates_uniqueness_of :iname
+    validates_presence_of :iname
     
     def self.reloadable? #:nodoc:
       return false
@@ -23,11 +23,11 @@ module ActiveAcl
     
     # used as instance description in admin screen
     def active_acl_description
-      if note
+      if iname
         if section
-        '/' + section.description + '/' + note
+        '/' + section.description + '/' + iname
         else
-          return note
+          return iname
         end
       else
         return nil

data/{lib → app/models}/active_acl/acl_section.rb

@@ -6,11 +6,11 @@ module ActiveAcl
     
     has_many :members, :class_name => 'ActiveAcl::Acl', :foreign_key => 'section_id'
     
-    validates_presence_of :description
-    validates_uniqueness_of :description
+    validates_presence_of :iname
+    validates_uniqueness_of :iname
     
     # Make shure there are no associated acls before destroying a section
-    def before_destroy
+    def before_destroy #:nodoc:
       if members.empty?
         true
       else

data/{lib → app/models}/active_acl/controller_action.rb

@@ -3,7 +3,7 @@
 class ActiveAcl::ControllerAction < ActiveRecord::Base
   set_table_name ActiveAcl::OPTIONS[:controller_actions_table]
   privilege_const_set('EXECUTE')
-    
+
   belongs_to :controller_group, :class_name => 'ActiveAcl::ControllerGroup'
   acts_as_access_object :grouped_by => :"active_acl/controller_group"
   validates_presence_of :action, :controller, :controller_group

data/{lib → app/models}/active_acl/controller_group.rb

@@ -3,7 +3,7 @@ class ActiveAcl::ControllerGroup < ActiveRecord::Base
   set_table_name ActiveAcl::OPTIONS[:controller_groups_table]
   acts_as_nested_set
   has_many :controller_actions,:class_name => 'ActiveAcl::ControllerAction'
-  acts_as_access_group
+  acts_as_access_group :type => ActiveAcl::Acts::AccessGroup::NestedSet
 
    validates_presence_of :description
    

data/db/migrate/001_base_table_setup.rb

@@ -2,22 +2,25 @@ class BaseTableSetup < ActiveRecord::Migration
   def self.up
     create_table ActiveAcl::OPTIONS[:acls_table] do |t|
         t.column :section_id,  :int
+        t.column :iname,       :string,:null => false
         t.column :allow,       :boolean, :null => false, :default => true
         t.column :enabled,     :boolean, :null => false, :default => true
-        t.column :note,        :string, :null => true
+        t.column :description, :text, :null => true
         t.column :updated_at,  :datetime, :null => false
     end
     
     add_index ActiveAcl::OPTIONS[:acls_table], :enabled
     add_index ActiveAcl::OPTIONS[:acls_table], :section_id
     add_index ActiveAcl::OPTIONS[:acls_table], :updated_at
-    add_index ActiveAcl::OPTIONS[:acls_table], :note, :unique
+    add_index ActiveAcl::OPTIONS[:acls_table], :iname, :unique
+    
         
     create_table ActiveAcl::OPTIONS[:acl_sections_table] do |t|
-        t.column :description, :string, :limit => 230, :null => false
+        t.column :iname,       :string, :null => false
+        t.column :description, :text, :null => true
     end
     
-    add_index ActiveAcl::OPTIONS[:acl_sections_table], :description, :unique
+    add_index ActiveAcl::OPTIONS[:acl_sections_table], :iname, :unique
         
     create_table ActiveAcl::OPTIONS[:privileges_table] do |t|
         t.column :section,        :string, :limit => 230, :null => false

data/init.rb

@@ -1 +1,7 @@
-require 'active_acl'
+raise "This Rails version is not supported by ActiveAclPlus" if Rails.version < "2.1.0"
+
+if Rails.version < "2.3.0"
+  model_path=File.join(File.dirname(__FILE__),'app','models')
+  ActiveSupport::Dependencies.load_paths << model_path
+end
+require 'active_acl'

data/lib/active_acl/acts_as_access_group.rb

@@ -7,38 +7,33 @@ module ActiveAcl #:nodoc:
       def self.included(base)    
         base.extend(ClassMethods)
       end
-
+      
       module ClassMethods
-        # Extend self with access group capabilites. See README for details
-        # on usage. Accepts the following options as a hash:
-        # left_column:: name of the left column for nested set functionality, default :lft
-        # right_column:: name of the right column for nested set functionality, default :rgt
-        # Don't use 'left' and 'right' as column names - these are reserved words in most DBMS.
+        # Extend self with access group capabilites.
+        # Options can be: 
+        # type:: is mandatory and is one of the group handler classes 
+        # left_column:: for ActiveAcl::Acts::AccessGroup::NestedSet grouped objects
+        # right_column:: for ActiveAcl::Acts::AccessGroup::NestedSet grouped objects
+        
         def acts_as_access_group(options = {})
-          configuration = {:left_column => :lft, :right_column => :rgt,
-                           :controller => ActiveAcl::OPTIONS[:default_group_selector_controller],
-                           :action => ActiveAcl::OPTIONS[:default_group_selector_action]}
-          configuration.update(options) if options.is_a?(Hash)
-          ActiveAcl::GROUP_CLASSES[self.name] = configuration
+          type=options.delete(:type) || ActiveAcl::Acts::AccessGroup::NestedSet
+          ActiveAcl::GROUP_CLASSES[self.name] = type.new(options)
+
+          include ActiveAcl::Acts::Grant
+          include InstanceMethods
+          extend SingletonMethods                         
           
-          from_classes = ActiveAcl::GROUP_CLASSES.keys.collect do |x| 
-            x.split('::').join('/').underscore.pluralize.to_sym
-          end
-                        
           ActiveAcl::Acl.instance_eval do
-            has_many_polymorphs :requester_groups, {:from => from_classes, 
+            has_many_polymorphs :requester_groups, {:from => ActiveAcl.from_classes, 
               :through => :"active_acl/requester_group_links",
               :rename_individual_collections => true}
-
-            has_many_polymorphs :target_groups, {:from => from_classes, 
+            
+            has_many_polymorphs :target_groups, {:from => ActiveAcl.from_classes, 
               :through => :"active_acl/target_group_links",
               :rename_individual_collections => true}
           end
           
-          include InstanceMethods
-          extend SingletonMethods                         
-          
-         end
+        end
       end
       
       module SingletonMethods