This rails plugin includes modifications to the Aegis gem. As it is a gem, I haven’t created my own fork. I could possibly have forked and sent a pull request, but haven’t.

It is initially assumed that there is only ONE subclass of Aegis::Permissions and its name is Permissions (ie. ::Permissions). I don’t know why someone would have more, but I’m sure that there is a reason. If you do, aegis_extension/action_controller.rb may need modified or removed to suit your needs as it uses ::Permissions.exists?

current_user method is also assumed to exist and is used in the action_controller method_missing.

Added attr_reader for the options passed to new Aegis::Roles. The initialize method accepts it, but the developer never has access to it. I’d like to pass :position so that I can sort my roles based on something other than randomness. I found this useful for viewing user profiles and assigning the user’s role. I had considered assigning a value based on the order which the roles were called, but opted against it.

class Permissions < Aegis::Permissions
 role :user, :position => 1	#	default value for User.new
 role :employee, :position => 2
 role :moderator, :position => 3
 role :administrator, :default_permission => :allow, :position => 4
end

>> Permissions.find_all_roles.collect(&:options)
=> [{:default_permission=>:allow, :position=>4}, {:position=>2}, {:position=>3}, {:position=>1}]

>> @roles = Permissions.find_all_roles.sort_by{|role| role.options[:position]}.collect(&:options)
=> [{:position=>1}, {:position=>2}, {:position=>3}, {:default_permission=>:allow, :position=>4}]

>> @roles = Permissions.find_all_roles.sort_by{|role| role.options[:position]}.collect(&:name)
=> [:user, :employee, :moderator, :administrator]

Added Permissions.permission_names which returns @permission_blocks.keys

>> Permissions.permission_names.collect(&:to_s).sort
=> ["create_address", "create_addresses", "destroy_address", "destroy_addresses", "maintain_page", "maintain_pages", "read_address", "read_addresses", "read_calendar", "read_package", "read_packages", "read_user", "read_users", "update_address", "update_addresses"]

Added Permissions.exists?(permission) which returns the obvious boolean as to whether or not the permission has actually been defined and exists in the Permissions.permission_name array. “permission” will be “normalized” before being tested.

>> Permissions.permission_names.collect(&:to_s).sort
=> ["create_address", "create_addresses", "destroy_address", "destroy_addresses", "maintain_page", "maintain_pages", "read_address", "read_addresses", "read_calendar", "read_package", "read_packages", "read_user", "read_users", "update_address", "update_addresses"]
>> Permissions.exists?(:view_users)
=> true
>> Permissions.exists?(:read_users)
=> true

Added dynamically ‘created’ before_filters based on naming conventions by adding a method_missing method. This is still in development and, due to some natural english usage, may never be perfect. The purpose being that using a before_filter that matches /^may_(.+)_required$/ like …

before_filter :may_administrate_required
before_filter :may_create_post_required
before_filter :may_maintain_pages_required
before_filter :may_view_users_required
before_filter :may_view_user_required

… either passes or redirects, currently just to the root_path, based on the permission. Those items that contain a singular target, like ‘post’ or ‘user’ expect that @post and @user be defined before this before_filter is executed if it affects the permission. Those targets whose singular and plural forms are the same may not work yet.

Also just added negated before filters. Not real sure how well this’ll work, but for now it does. A permission like …

permission :be_user do |current_user, target_user|
  deny :everyone
  allow :everyone do
    current_user == target_user
  end
end

… will enable the functioning of the before_filter …

before_filter :may_not_be_user_required

I don’t see a lot of demand for this so it may have been simply a programming exercise. Linguistically, “must_not_be_user_required” sounds better as does “must_be_user_required.” “May” sounds too passive. “Must” sounds more demanding. Of course, the trailing “required” is then redundant.

• Devise a way for the user to control access denied redirects and perhaps messages. This is currently in progress.

Aegis Permissions on GitHub

github.com/makandra/aegis/commit/691083a0513e1901ccca87ee846e5923fdeb4fb6 fixed the need for the validates_role_name override so removed it here.