Определение ролей с помощью Rolify

Что меня совершенно сбивает с толку, так это то, что все документы для драгоценного камня Rolify используют консоль для определения ролей.

Документация Rolify не использует консоль для определения ролей — она демонстрирует, как можно добавлять роли в чистом Ruby. Это удивительно мощно, потому что вы можете определять роли, где бы вы ни запускали ruby. Вы не ограничены статическим списком ролей, определенных в каком-либо файле конфигурации или в какой-либо таблице базы данных.

Первый вопрос, который вам нужно задать, это когда создаются роли?

Наиболее распространенные варианты использования делятся на две группы:

<сильный>1. Роли статичны.

Роли создаются один раз разработчиком приложения, персоналом службы поддержки или руководителями компании во время установки/развертывания приложения, и в течение всего срока службы приложения эти предварительно созданные роли назначаются разным пользователям.

Наиболее распространенные варианты использования таких ролей включают моделирование назначений людей в компании (разработчик, менеджер, служба поддержки и т. д.) или моделирование ранее известных обязанностей (редактор, администратор, наблюдатель и т. д.).

Если ваши роли действительно попадают в такие варианты использования, следующее, что вам нужно решить, — кто отвечает за создание и изменение ролей. Обычно есть две возможности:

1.1. Разработчик приложения — это человек, который должен добавлять/удалять/изменять роли. В таких случаях лучше полагаться на начальные данные или миграции Rails.

Преимущество миграции заключается в том, что вы можете легко откатить данные, если это необходимо. Эта миграция является дополнительной к миграции, созданной генераторами rolify, которые создают для вас схему таблиц, связанных с ролями (см. диаграмму ниже).

Такая миграция может выглядеть так:

БД/мигрировать/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

Некоторые люди справедливо считают, что изменение схемы и данных одновременно является антипаттерном. управляемые миграциями. data-migrate — это драгоценный камень, который позволяет вам отделить ориентированные на данные миграции от миграций вашей схемы.

В этом и во всех других случаях, описанных ниже, фактическое назначение ролей будет происходить на основе действий пользователя или событий приложения с помощью add_role или remove_role методов, предоставляемых rolify. Это произойдет в ходе жизненного цикла работающего приложения, а не во время установки приложения.

1.2 Задача добавления/удаления/изменения ролей выполняется службой поддержки или техническими руководителями. В таких случаях потребуется предоставить административный интерфейс для управления ролями.

В этом случае у вас будет контроллер rails для управления ролями. Действие create будет использоваться для создания роли, действие show будет использоваться для представления роли и т. д. Эти действия будут иметь сопровождающие представления, которые предоставят конечному пользователю графический интерфейс для управления ролями.

<сильный>2. Роли являются динамическими

Эта категория охватывает случаи использования, когда роли рассматриваются скорее как категории или теги и могут быть созданы/изменены/удалены конечными пользователями. Например, библиотекарь может назначить определенную роль/категорию определенному жанру книг.

Этот случай похож на 1.2, потому что вы должны обрабатывать создание/удаление/обновление ролей через контроллеры rails.

Следующая часть — это то, как информация структурирована в ваших таблицах.

Rolify ожидает конкретную схему (в определенной степени настраиваемую), но ожидаемая схема достаточно гибкая, чтобы обрабатывать все вышеперечисленные варианты использования.

Я буквально только что прошел через тот же процесс, и, как и @user2860931, все, что я смог найти, это несколько примеров того, как назначать роли из консоли. Что мне нужно, так это программно гибкий способ того, как пользователь с ролью администратора или пользователь, скажем, с ролью pmo, может назначать эти роли другим.

Немного поэкспериментировав, я решил это для себя. В этом примере я использую Devise для аутентификации и Rolify для ролей.

Я предполагаю, что у вас уже установлен и работает Devise, поэтому у вас есть существующая модель пользователя. Установите Rolify согласно инструкции на странице гема. Я использовал предложенное имя Роль для модели ролей. Так что делайте все, как указано здесь: https://github.com/RolifyCommunity/rolify. Установите GEM, сгенерируйте с помощью роли пользователя. И перенесите миграцию базы данных.

Это эффективно оставит вас с новой таблицей Roles и отношением has_and_belongs_to_many с таблицей Users.

Что касается моей цели, то мне не требуется обычный интерфейс Create Read (show) Update Delete (CRUD) для ролей, я просто создал несколько с помощью seed.rb вот так.

#Seeding the Role table
#
p "Removing existing #{Role.all.count} roles"
Role.destroy_all
p "Creating 7 roles"
[:user, :admin, :portfolio_manager, :programme_manager,     :project_manager, :coordinator, :pmo].each do |role|
  Role.create( name: role )
end
p "Should have created 7 Roles, roles created: #{Role.all.count}"

Я оставил свой дополнительный комментарий, как и в отношении разработки, чтобы с первого взгляда увидеть, что все работает нормально. Итак, когда вы бежите

грабли дб: семя

У вас будет несколько настроек ролей. В качестве альтернативы вы можете создать контроллер ролей и представления обычным способом, чтобы пользователи с ролью администратора могли добавлять новые роли.

Теперь самое интересное может начаться. До сих пор Devise сделал все, что касается ваших пользователей, или, возможно, вы все равно сделали свой собственный контроллер, но вам нужно создать свой собственный контроллер пользователей и представления. Поскольку мне нужен только список флажков для ролей для каждого пользователя, я сделал это следующим образом. Вот мой

users_controller.rb

class UsersController < ApplicationController
  before_action :set_user, only: [:show, :edit, :update]

  def index
    @users = User.all
  end

  def show
  end

  def edit
  end

  def update
    respond_to do |format|
      if @user.update(user_params)
        # TODO: Move hardcode flash message into language file
        format.html { redirect_to @user, notice: 'User was successfully updated.'}
        format.json { render :show, status: :ok, location: @user }
      else
        format.html { render :edit }
        format.json { render json: @user.errors, status: :unprocessable_entity }
      end
    end
  end

  private

  def set_user
    @user = User.find(params[:id])
  end

  def user_params
    params.require(:user).permit(:username, :email, {role_ids: []})
  end
end

Теперь вам нужно определить маршруты для них, чтобы они не конфликтовали с маршрутами Devise. На данный момент я сделал это простым и предоставил все обычные маршруты для защиты вашего приложения, которое вы можете изменить, и разрешать маршруты только для тех, которые у вас действительно есть.

routes.rb

Rails.appliction.routes.draw do
  devise_for :users
  root 'pages#home'
  resources :users    #must be after devise
end

Теперь, когда вы делаете rake route, вы получите обычные пути для вашего приложения, чтобы заставить контроллер работать. Вот так и в таком порядке:

                  Prefix Verb   URI Pattern                      Controller#Action
        new_user_session GET    /users/sign_in(.:format)       devise/sessions#new
            user_session POST   /users/sign_in(.:format)       devise/sessions#create
    destroy_user_session DELETE /users/sign_out(.:format)      devise/sessions#destroy
           user_password POST   /users/password(.:format)      devise/passwords#create
       new_user_password GET    /users/password/new(.:format)  devise/passwords#new
      edit_user_password GET    /users/password/edit(.:format) devise/passwords#edit
                         PATCH  /users/password(.:format)      devise/passwords#update
                         PUT    /users/password(.:format)      devise/passwords#update
cancel_user_registration GET    /users/cancel(.:format)        devise/registrations#cancel
       user_registration POST   /users(.:format)               devise/registrations#create
   new_user_registration GET    /users/sign_up(.:format)       devise/registrations#new
  edit_user_registration GET    /users/edit(.:format)          devise/registrations#edit
                         PATCH  /users(.:format)               devise/registrations#update
                         PUT    /users(.:format)               devise/registrations#update
                         DELETE /users(.:format)               devise/registrations#destroy
             user_unlock POST   /users/unlock(.:format)        devise/unlocks#create
         new_user_unlock GET    /users/unlock/new(.:format)    devise/unlocks#new
                         GET    /users/unlock(.:format)        devise/unlocks#show
                    root GET    /                              pages#home
                   about GET    /about(.:format)               pages#about
                 contact GET    /contact(.:format)             pages#about
                   users GET    /users(.:format)               users#index
                         POST   /users(.:format)               users#create
                new_user GET    /users/new(.:format)           users#new
               edit_user GET    /users/:id/edit(.:format)      users#edit
                    user GET    /users/:id(.:format)           users#show
                         PATCH  /users/:id(.:format)           users#update
                         PUT    /users/:id(.:format)           users#update
                         DELETE /users/:id(.:format)           users#destroy

Все, что осталось сделать сейчас, это создать пользовательский интерфейс, самую важную часть для меня, и, если я правильно понял, для вас тоже. Чтобы построить это быстро, мой пример еще не очень хорошо представлен с полной магией css, но я уверен, что вы можете сделать это по своему вкусу.

Итак, чтобы показать существующих пользователей и выбрать их из списка, создайте index.html.erb в папке /app/views/users. Создайте простой show.html.erb и редактирование, в котором вы можете назначать и удалять существующие роли. Как это.

index.html.erb

<!-- TODO: Tidy up this file and make it look good -->
<!-- TODO: Remove hard coded text to a locale file -->
<% @users.each do |user| %>
  <p>
    <%= link_to "#{user.username}<#{user.email}>", user %>
    <%= link_to "edit", edit_user_path(user) %>
  </p>
<% end %>

show.html.erb

<!-- TODO: Tidy up this file and make it look good -->
<!-- TODO: Remove hard coded text to a locale file -->
<p>
  Username: <%= @user.username %>
</p>
<p>
  Email address: <%= @user.email %>  
</p>

<%= link_to "Back", users_path %>

edit.html.erb

<!-- TODO: Tidy up this file and make it look good -->
<!-- TODO: Remove hard coded text to a locale file -->
<p>
 Username: <%= @user.username %>
</p>
<p>
 Email address: <%= @user.email %>
</p>

<%= form_for @user do |f| %>
  <% Role.all.each do |role| %>
    <%= check_box_tag "user[role_ids][]", role.id, @user.role_ids.include?(role.id) %>
    <%= role.name %></br>
  <% end %>
  <%= f.submit %>
<% end %>

<%= link_to "Back", users_path %>

И вот он у вас есть, простой пользовательский интерфейс, в котором перечислены все доступные роли из базы данных и предусмотрены флажки напротив записи пользователя, чтобы включить или отключить такую ​​роль. Как это:

Пример записи пользователя и списка выбора роли

Для меня это тоже было небольшой головной болью, но, надеюсь, это поможет вам улучшить логику и пользовательский опыт.

Прочитав документацию и примеры на страницах их проектов, я решил не использовать драгоценный камень для управления ролями на моей странице, потому что считал, что настройка и использование займут у меня много времени. Поэтому вместо этого я сделал следующее (я полагаю, что вы использовали разработку для своей пользовательской модели, хотя это и не обязательно):

Если вы хотите, чтобы определенные роли были определены и «статичны», не изменялись, но назначались со вашей страницы, см. ниже, если нет, перейдите к следующей жирной строке

1. Добавьте поле с именем role: integer в модель User с помощью миграции. (мы используем целое число, потому что это значение будет связано с одной записью в перечислении, которое мы определяем на следующем шаге)

2. В вашем файле user.rb (модель) добавьте enum, как показано ниже:

   class User < ActiveRecord::Base
     devise :registerable, #...
   
     enum role: [:admin, :normal, :premium, :moreRolesHere ]
     after_initialize :set_default_role, :if => :new_record?
   
     def set_default_role
       self.role ||= :normal
     end
   
   end
   

3. Затем в любом контроллере, представлении или def вам просто нужно получить текущего пользователя или любого пользователя, которому вы хотите назначить роль, и сделать так же просто, как в строке ниже:

   #let's suppose we want to make premium the current user
   current_user.premium!
   
   #or someone else to be admin
   user = User.first
   user.admin!
   

4. Затем вы можете сделать свои собственные проверки на любой странице или контроллере, над которым вы работаете, просто спросив роль пользователя:

   #see if the current user is admin
   if current_user.role == "admin"
     #do some admin stuff
   end    
   

Если вы хотите добавлять, изменять и удалять роли на своей странице, а также назначать их там

Прежде всего будьте осторожны при назначении ролей прямо со своей страницы. Проблема здесь в том, что каждый сможет назначить себе свою роль, выбранную в поле. Но если это то, что вам нужно, сделайте следующее:

1. Создайте модель под названием Role с полем role: string
2. Создайте контроллер, связанный с этой моделью, roles_controller.rb
3. Создайте представления, необходимые для отображения действий, связанных с управлением ролями (создание, редактирование, удаление). обратите внимание на то, чтобы эти страницы были доступны только зарегистрированным пользователям. Выбор или добавление роли пользователю, которым вы будете управлять в своем контроллере пользователей или любом другом контроллере, который вы хотите.

4. В любом другом представлении, в котором вы хотите запросить роль пользователя, вам потребуется получить доступ к таблице ролей и получить те, которые соответствуют пользователю. В таблице пользователей потребуется столбец role_ids: text (это текст, потому что вам нужно сохранить несколько ролей, все роли заключены в массив), который будет представлять его роли. В вашей модели user.rb у вас могут быть методы get_roles и другие методы defs, чтобы иметь более чистый код в контроллерах и представлениях:

   class User < ActiveRecord::Base
     devise :registerable, #...
   
     serialize :role_ids
   
     #will return you an array of roles-(strings) of the user
     def get_roles
       roles = []
       role_ids.each do |role_id|
         roles << Role.find(role_id).role
       end
       return roles      
     end
   
     #ask if this user has some role-(string)
     def has_role(role)
       roles = get_roles
       return roles.include?(role)
     end
   
   end
   

5. Наконец, конечно, вам нужно будет реализовать контроллер для ролей, создания, обновления и уничтожения, а также всех def, связанных с их представлениями.

Вы можете взглянуть на как сохранить массивы в базе данных, сериализовать< /а>

В этом подходе не используются какие-либо жемчужины, связанные с управлением ролями или авторизацией, как в market: эксперт, канкан, свернуть. Оставьте вам несколько ссылок, если вы скептически относитесь к моему подходу и хотите запачкать руки.

Принятый ответ от @lorefnon действительно содержит порочный анти-шаблон в миграции:

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

Не из-за принципа разделения данных и схемы, а потому, что мы не должны никогда использовать объект модели при миграции!

Миграции неизменяемы, но модель изменчива: если одна из ваших миграций зависит от одного или нескольких классов модели, ее можно легко сломать, если один из классов будет изменен, переименован или удален (если мы решим, например, удалить изменение наших зависимостей ).

Миграции должны основываться только на механизмах ActiveRecord::Migration (add_column, create_tables, ...) и чистом SQL.