Quelle est la meilleure façon de mettre en œuvre des rôles? Ce que je veux essentiellement, c'est un modèle utilisateur. Mais je veux deux types d'utilisateurs différents. 1) utilisateur régulier auquel ils peuvent acheter des produits. 2) le deuxième utilisateur est un vendeur. Cet utilisateur peut ajouter et supprimer des produits.
Comment puis-je ajouter un vendeur à l'utilisateur? Je voudrais que l'acheteur et le vendeur aient les mêmes points de vue. Pouvez-vous donner un exemple s'il vous plaît?
Actuellement, j'ai un modèle utilisateur (conception) et un modèle de produits.
4 Réponses :
Je ne sais pas si c'est la meilleure façon, mais voici un exemple de ce qui peut être fait. Utilisation de enum:
class User < ApplicationRecord
devise :database_authenticatable, :rememberable, :trackable, :validatable, :lockable,
authentication_keys: [:login], password_length: 4..32, unlock_strategy: :time
enum available_roles: {buyer: 100, seller: 101}
def buyer?
has_role?(User.available_roles[:buyer])
end
def seller?
has_role?(User.available_roles[:seller])
end
def has_role?(role)
roles.include?(role)
end
end
Pour utiliser les autorisations (comme seul un vendeur peut ajouter et supprimer des produits), vous pouvez utiliser la bibliothèque cancancan https://github.com/CanCanCommunity/cancancan
Si vous utilisez enum pour cela (ce qui est une bonne approche ici), vous aurez accès à user.buyer? et user.seller? < / code> automatiquement ( documentation ici ), ce qui signifie que vous ne pas besoin de les créer manuellement @Xero.
J'aime vraiment cette façon. Cependant, la façon dont je le souhaite est par défaut un utilisateur lorsqu'un utilisateur s'inscrit, il est automatiquement un acheteur. Ils peuvent acheter tout type de produit. L'administrateur devrait créer un compte pour les acheteurs parce que je voudrais vérifier leur entreprise, etc. Ainsi, l'acheteur serait du côté client et le vendeur serait du côté interne de l'application. Votre méthode pourrait-elle encore fonctionner pour cela?
@Xero, alors comment puis-je y accéder dans la vue? Serait-ce <% si @ user.is_buyer? %>
@ Djjhjuser10735674 oui exactement. Au fait, j'ai renommé la méthode "acheteur?" et "vendeur?" sont un nom plus propre
Vous pouvez ajouter la colonne user_type à l'utilisateur. Vous pouvez définir la valeur par défaut sur acheteur ou vous pouvez fournir une liste de sélection de type pour créer / mettre à jour le formulaire de l'utilisateur.
De plus, vous pouvez utiliser la gemme cancancan pour définir leurs autorisations
N'utilisez pas de type pour une colonne de base de données, elle sera en conflit. Utilisez plutôt user_type.
@Catmal Êtes-vous sûr? Je l'avais utilisé dans l'application (rails-4), ne me dérangeait pas. Pouvez-vous expliquer peu?
stackoverflow.com/ questions / 11984893 /… mais j'ai aussi cette erreur sur les rails 5.
@Catmal Oui, je le sais car c'est juste un cas valide uniquement en cas de héritage de table unique (STI) . J'ai toujours mis à jour la réponse pour éviter de futures possibilités rares ce que vous avez dit!
Ok, j'ai probablement besoin d'en savoir plus. Je n'y ai pas prêté attention quand une erreur s'est produite :)
Vous pouvez utiliser la gemme cancancan. Et ajoutez une colonne vendeur (booléen) à la table des utilisateurs.
Ensuite, sur ability.rb
if user.present? can :read, Product end if user.seller? can :manage, Product, user_id: user.id end
Ceci, en supposant qu'un produit appartient à un utilisateur, permettra aux vendeurs de créer / modifier / supprimer leurs produits (si les produits sont communs à tous les vendeurs, vous pouvez supprimer la partie user_id: user.id ).
Alors que tous les autres (acheteurs) peuvent voir tous les produits. S'ils achètent probablement, ils peuvent créer une commande ou comme vous l'appellerez.
Ce que je suggérerais, c'est d'avoir différents modèles et tables pour les clients et les vendeurs, car ce sont des entités logiquement différentes. CustomerModel interagira avec vos applications client et SellerModel interagira avec votre application interne. C'est une meilleure façon pour moi.
Toujours si vous souhaitez les avoir dans une seule table, je suggère d'ajouter une colonne de type dans la table des utilisateurs, puis d'utiliser les principes de l'héritage de table unique. L'avantage que vous avez avec STI est que vous pouvez rendre votre code beaucoup plus modulaire et ajouter des méthodes spécifiques aux clients et aux vendeurs dans leurs modèles respectifs qui hériteraient à leur tour de UserModel.
Voici un lien pour l'héritage d'une table unique qui pourrait être utile: Explication de l'héritage de table unique
Pour le contrôle d'accès, vous pouvez utiliser la gemme Pundit. Voici un lien github pour le même.
Un utilisateur peut-il également être à la fois acheteur et vendeur?