• Listing Permissions

In the Setup example, current_user (typically returning an instance of an ActiveRecord User model) must implement a method #permissions which returns an array of strings. You are free to implement this however you like, whether you store your permissions as a JSON array in your database, in a join table, or via an external API call.

ActiveElement requires various inferred permissions to be present in order for a user to access a Rails route. If a user does not have permissions, a splash screen appears informing the user what permissions they need to access the resource.

Permission names are based on the following templates:

e.g. if your application is defined as:

# config/application.rb

module BookingSystem
  class Application < Rails::Application
  end
end

and you have your controllers namespaced under admin:

# config/routes.rb

namespace :admin do
  resources :bookings
end

then the following permissions will be applied:

• can_list_booking_system_admin_bookings
• can_view_booking_system_admin_bookings
• can_edit_booking_system_admin_bookings
• can_create_booking_system_admin_bookings
• can_delete_booking_system_admin_bookings

Note that permissions are not mapped 1:1 to controller actions. This design choice is intended to reduce the risk of e.g. revoking a permission only for the #edit action and being misled into thinking that this would prevent a user from submitting a request directly to the #update action. #index and #show are implemented as separate permissions as it is expected that one view may provide more detailed information than another.

All permissions can be viewed at any time by running the provided Rake task:

$ rake active_element:permissions

* can_list_booking_system_admin_bookings
* can_view_booking_system_admin_bookings
* can_edit_booking_system_admin_bookings
* can_create_booking_system_admin_bookings
* can_delete_booking_system_admin_bookings