Defining Roles with Rolify
I am trying to make an app with Rails 4.
I am looking at role management and want to use Rolify because it supports instance level role assignment.
For others looking at the same problem, there are 2 really good answers below (I can only tick one but I used both). Check out lorefnon & Cyb3rDud3 answers below). I'm still figuring it out, but have made a migration with an array (as lorefnon shows) and the controller/routes functions (as Cyb3rDud3 shows).
What is completely baffling me is that all the documents for the Rolify gem use the console to define roles.
How do I define roles in my code?
Others on this board have asked questions which allude to them defining roles in their db:seeds file. I don't want to do that because I want to control who uses my seeds file more tightly than who can create roles.
Where do you do it?
All the examples show it being done from the console. I want to define a list of roles and then I want to give roles permissions (I want to use pundit for this part).
I have a user model. The other gem I looked at was role model. It asks you to create an array of roles in the user model. It it just so obvious that you're supposed to do that in Rolify- that none of the documents give you this step?
Where do you define the roles?
Answer
What is completely baffling me is that all the documents for the Rolify gem use the console to define roles.
Rolify documentation does not use the console to define roles - it demonstrates how roles can be added in pure ruby. This is amazingly powerful because you can define roles whereever you can run ruby. You are not restricted to a static list of roles defined in some configuration file or in some database table.
The first question you need to ask is when do the roles get created ?
The most common use cases fall into two groups:
1. Roles are static.
Roles are created once by the application developer, support staff or company executives during application installation/deployment and during the lifetime of the running application these pre-created roles are assigned to different users.
The most common use cases of such roles includes modelling designations of a people in a company (developer, manager, support etc.), or modelling priorly known responsibilities (editor, administrator, viewer etc.)
If your roles do fall into such use cases, next thing you have to decide - whose responsibility is it to create and modify the roles. There are typically two possibilities:
1.1. Application developer himself is the person who has to add/remove/modify roles. In such cases it is best to rely on seed data or Rails migrations.
Advantage of migrations is that you can rollback the data easily if need be. This migration is additional to migration generated by rolify generators which create the schema of roles related tables for you (refer to the diagram below).
Such a migration might look like:
db/migrate/20151204083556_create_application_roles.rb
class CreateApplicationRoles < ActiveRecord::Migration
def up
['admin', 'support', 'editor'].each do |role_name|
Role.create! name: role_name
end
end
def down
Role.where(name: ['admin', 'support', 'editor']).destroy_all
end
end
Some people rightly consider it an antipattern to have schema changes and data changes both managed by migrations. data-migrate is a gem that allows you to separate the data centric migrations from your schema migrations.
In this case and all the other cases below actual assignment of roles will happen based on user actions or application events through add_role or remove_role methods provided by rolify.This will happen during the course of the lifecycle of running application and not during application installation.
1.2 The task of adding/removing/modifying roles is done by a support team or technical executives. In such cases it would be required to provide an administrative interface for managing roles.
In this case you will have a rails controller to manage the roles. The create action will be used for creating role, show action will be there to present the role etc. These actions will have accompanying views that will provide a graphical user interface to end user to manage the roles.
2. Roles are dynamic
This category covers use cases where roles are treated more like categories or tags and can be created/modified/deleted by end users. For example a librarian can assign some role/category to a particular genre of books.
This case is similar to 1.2 because you have to handle creating/deleting/updating roles through rails controllers.
Next part is how the information is structured in your tables.
Rolify expects a specific schema (customizable to certain extent) but the expected schema is flexible enough to handle all the above use cases.
