【问题标题】：Devise gem - unclear "how-to" guide设计 gem - 不清楚的“操作方法”指南
【发布时间】：2017-03-07 18:38:34
【问题描述】：

这篇文章是指Devise wiki中的以下操作指南：要求管理员在登录前激活帐户

我已经为我的应用设置了 Devise 身份验证，没有任何问题，并且一切正常。

但是，由于该应用仅供内部使用，我想要求管理员在登录前激活新帐户。

因此，我一直在尝试按照“操作方法”文章中的分步说明进行操作，但遇到了一些我想澄清的问题：

1) 模型更改：

在模型更改下，要求：

“然后，在你的模型（User.rb）中覆盖以下方法：”

def active_for_authentication? 
    super && approved? 
end 

def inactive_message 
    if !approved? 
      :not_approved 
    else 
      super # Use whatever other message 
    end 
end

-> 我的困惑来自“覆盖”这个词的使用。我应该简单地将它添加到 model/user.rb 文件中吗？无需其他更改。

以下步骤要求您：

"您需要在 i18n 文件中为 :not_approved 和 :signed_up_but_not_approved 创建一个条目，该文件位于 config/locales/devise.##.yml:"

devise:
    registrations:
      user:
        signed_up_but_not_approved: 'You have signed up successfully but your account has not been approved by your administrator yet'
failure:
    not_approved: 'Your account has not been approved by your administrator yet.'

-> 我的问题是关于如何正确地将它们添加到 yml 文件中。我是将它集成到现有代码中（即，在现有注册下添加 user:... :)，还是简单地将其添加到顶部 - 包括“设计：”？

2) 控制器和视图

第一部分要求人们执行以下操作：

“您需要创建一个仅管理员可访问的控制器方法，它列出未批准的用户并提供一种简单的批准方法。”

-> 我的问题是我们在谈论哪个控制器？ Devise 不会创建一个可编辑的控制器...我是生成一个名为 user_controller 的控制器还是会与设计中的控制器发生冲突？

-> ...在这种情况下，它是否应该从设计控制器继承？

-> 或者，我可以将代码完全添加到另一个控制器中，然后用于访问新方法吗？不喜欢这样做，因为它会弄乱我现有的控制器之一...

-> 还提到了一个 index.html.haml，其中一个是添加代码以显示来自用户模型的信息。这个页面（我的版本是 html.erb）可以在任何你想显示用户状态信息的地方，只要它可以访问新的用户控制器方法吗？

3) 电子邮件通知

-> 一切似乎都很清楚......这里有什么我应该考虑使用的电子邮件地址吗？在设置设计时，我添加了我的 gmail 地址作为临时措施。这会使事情复杂化吗？

4) 重置密码说明

-> 一切似乎都很清楚......添加到： app/models/user.rb

-> 评论：似乎向 user.rb 模型添加了很多东西。？

这是一个相当多的列表，但如果有人可以帮助我，我保证会创建并发布一个更加用户友好的指南版本......任何新手都应该能够成功使用的版本。

谢谢！

【问题讨论】：

标签： ruby-on-rails devise

【解决方案1】：

1。是的，您只需将这 2 个方法添加到您的资源模型中。

它覆盖方法不是因为您应该在模型中拥有它们，而是因为它们已经在 gem 中。

2。是的，您需要一个自己创建的控制器。

您说得对，Devise 没有内置模板供您管理用户。所以是的，您必须自己创建一个，或者如您所述，将其添加到现有控制器中。例如，您可以有一个 admin 命名空间，其中包含多个控制器，包括一个供用户帮助您管理的控制器。

#routes.rb

namespace :admin do
  get '', to: 'dashboard#index', as: '/'  ## just an example to show a dashboard in your admin namespace
  get 'manage-users', to 'users#index'
end

#controllers/admin/users_controller.rb

class Admin::UsersController < ApplicationController
  layout 'dashboard' #custom layout for admins
  before_action :authenticate_user! #make sure they are logged in
  before_action :verify_admin #make sure they are an admin

    def index
      if params[:unapproved]
        @users.unapproved
      else
        @users = User.all
      end
    end

    private

    def verify_admin
      unless current_user.admin? # this implies that you have a method in user called admin? that checks for the admin role 
        flash.now[:warning] = "You do not have permission to be here.  If you feel this is an error please request permission from your administrator"
        redirect_to root_path
    end
end

因为action是users#index，那么页面就是views/admin/users/index.html.erb

但是 - 我发现对于管理用户等管理任务，我有更多请求将其直接放入仪表板控制器。我只是这样做

@unapproved_users = User.unapproved

在仪表板#index 操作中并在仪表板上添加一个小部件，其中包含所有未批准用户的列表

然后在用户模型中快速获取未批准的用户

class User < ActiveRecord::Base

  devise :invitable, :database_authenticatable, :registerable,   :omniauthable, 
     :recoverable, :rememberable, :trackable , :validatable , :confirmable

  scope :unapproved, -> { where(approved: false) } 
  # this works because if you followed the wiki you should have a migration that has a default of false and doesn't allow nil, so every record will either be true or false for approved

end

这样，在您看来，无论您将它放在哪里，您都可以拥有一个包含用户列表的区域，每个用户都有一个复选框，该复选框向该记录发出 ajax 更新请求以批准该用户。例如

# views/admin/dashboard/index.html.erb or views/admin/users/index.html.erb or views/users/ .. etc, you get the idea, just make sure when it comes to managing users it's in a locked down place.

<table class="table table-striped" id="manage-users">
  <thead>
    <tr>
      <th>First Name</th>
      <th>Last Name</th>
      <th>Email</th>
      <th>Status</th>
    </tr>
  </thead>
  <tbody>
    <%- @users.each do |user| %>
      <tr id="user-<%= user.id %>">
        <td>
          <%= user.first_name %>
        </td>
        <td>
          <%= user.last_name %>
        </td>
        <td>
          <%= user.email %>
        </td>
        <td class="status">
          <%= user.approved ? "Approved" : check_box_tag('approved', true, false) %>
        </td>
      </tr>
    <% end %>
  </tbody>
</table>

然后喝杯咖啡赶上更新

# javascripts/admin.coffee

->
  $('table#manage-users input[name=approved]').on 'change', ->
    uid = $(this).parent().parent().attr('id').replace(/user-/i, '')
    $.ajax
      type: 'PUT'
      dataType: 'json'
      url: '/admin/users/' + uid
      data: user: approved: true
      success: (data) ->
        user = 'user-' + uid
        $('tr#' + user).find('td.status').html 'Approved'
        return
    return
  return

在大多数情况下，您在处理设计时不需要用户控制器，因为它会为您处理。但是在管理员中拥有一个用户控制器是一种阻止非管理员用户访问并仍然允许管理的简单方法。而且很安静。

3 Gmail 很好。

您使用的电子邮件地址无关紧要。只要您正确设置了电子邮件以便主动邮件程序可以发送，就可以了。

4 相关性几乎就是这里的一切。

现代（截至目前）的想法是，如果它与数据的发现/验证/持久化有关，那么它可以进入模型，如果它的业务逻辑过于复杂，它可能应该是一个服务对象.

【讨论】：