Avec l'implémentation précédente, seul l'affiche peut modifier ou supprimer le message. Cependant, je vais l'étendre afin que n'importe qui puisse modifier / supprimer des messages lorsqu'il est connecté en tant qu'administrateur.
Pour ce faire, ajoutez une colonne d'administration à votre modèle d'utilisateur.
$ rails g migration AddAdminToUsers admin:boolean
db/migrate/xxxxxxxxxxxxxx_add_admin_to_users.rb
# frozen_string_literal: true
class AddAdminToUsers < ActiveRecord::Migration[6.0]
def change
add_column :users, :admin, :boolean, default: false, null: false
end
end
Au fait, jusqu'à présent, j'ai écrit le test après avoir implémenté la fonction, mais je pense que je comprends le comportement de base de pundit, donc je vais l'écrire à partir du test en premier.
Étant donné que le test qui ne peut pas être modifié et supprimé lors de la connexion en tant qu'un autre utilisateur sans privilèges d'administrateur a déjà été écrit,
Implémentons. Strictement parlant, il est parfait d'implémenter à la fois le test de politique et le test de demande, mais ici nous n'implémenterons que la politique.
Si vous le souhaitez, ne regardez pas l'exemple écrit ici, mais si vous essayez de l'implémenter par vous-même et de le comparer, ce sera une pratique d'écrire du code, alors essayez-le.
spec/policies/post_policy_spec.rb
...
RSpec.describe PostPolicy, type: :policy do
let(:user) { create(:user) }
+ let(:admin_user) { create(:user, admin: true) }
let(:post) { create(:post) }
...
it "Non autorisé lors de la connexion mais avec un autre utilisateur" do
expect(subject).not_to permit(user, post)
end
+ it "Autorisé lorsque vous êtes connecté en tant qu'utilisateur administrateur" do
+ expect(subject).to permit(admin_user, post)
+ end
...
spec/factories/posts.rb
...
remember_created_at { nil }
name { "MyString" }
tokens { nil }
+ admin { false }
end
...
Après avoir implémenté jusqu'à présent, déplacez rubocop et rspec et vérifiez. Je n'ai pas encore implémenté le fichier de politique, donc le test est moss.
Tout d'abord, créez une méthode privée dans application_policy.rb qui détermine que vous êtes un administrateur.
app/policies/application_policy.rb
...
private
def mine?
@record.user == @user
end
+
+ def admin?
+ @user.present? && @user.admin?
+ end
+
Il ne reste plus qu'à changer les deux jugements de mise à jour "Destroy" dans post_policy.rb.
app/policies/post_policy.rb
def update?
- mine?
+ mine? || admin?
end
def destroy?
- mine?
+ mine? || admin?
end
C'est tout!
Il s'agit d'un article légèrement fin, je vais donc toucher le factoryBot pour faciliter la création d'un utilisateur administrateur.
spec/factories/users.rb
name { "MyString" }
tokens { nil }
admin { false }
+
+ trait :admin do
+ admin { true }
+ end
end
spec/policies/post_policy_spec.rb
RSpec.describe PostPolicy, type: :policy do
let(:user) { create(:user) }
- let(:admin_user) { create(:user, admin: true) }
+ let(:admin_user) { create(:user, :admin) }
let(:post) { create(:post) }
Que diriez-vous d'exécuter rspec avec cela? Si vous pouvez écrire sans erreur, vous devez réussir le test.
Comme vous pouvez le voir, le trait peut être utilisé en le passant comme alias au second argument tel que create
de factoryBot.
Il y a peu d'avantages et de non-sens si vous définissez simplement l'indicateur d'administrateur, mais par exemple, s'il y a une colonne pour laquelle vous souhaitez avoir une valeur initiale comme ensemble dans le cas d'un utilisateur administrateur, plusieurs colonnes seront ajoutées à chaque fois create
Vous n'êtes pas obligé de définir la valeur initiale.
Veuillez utiliser tous les moyens.
→ Création d'une API de tableau d'affichage avec certification et autorisation dans Rails 6 # 18 ・ Implémentation du contrôleur de l'utilisateur final [Vers la table de sérialisation]
Recommended Posts