2011-07-09 3 views
1

je les modèlesModèle de base de données et la solution des associations

User, Developer, App, Permission 
  1. Un utilisateur peut avoir par défaut permision
  2. Un utilisateur peut avoir l'autorisation pour application différente
  3. Un utilisateur peut installer des applications multiples
  4. Un utilisateur peut également être développeur d'une application
  5. Un développeur est toujours un utilisateur et peut avoir tous les droits d'utilisateur (Installer applcation, autorisation par défaut, les autorisations pour chaque application)

Jusqu'à présent, j'ai:

user.rb

class User < ActiveRecord::Base 
    has_many :apps 
end 

app.rb

class App < ActiveRecord::Base 
    has_many :permissions, :through => :app_permissions 
end 

permission.rb

class Permission < ActiveRecord::Base 
    belongs_to :app 
end 

app_permission.rb

class AppPermission < ActiveRecord::Base 
end 

Questions

  1. Comment distinguer les utilisateurs? (Régulier, Développeur) Est-il préférable d'utiliser CanCan ou Rails STI ou Simple Roles Class? Veuillez justifier pourquoi il est préférable d'utiliser l'une de ces trois solutions ou quelque chose d'autre.
  2. Vaut-il mieux créer un modèle Default_Permission pour séparer les autorisations d'application des autorisations par défaut?

EDIT:

Si je manque toute information s'il vous plaît demander. J'aimerais voir des solutions différentes et comment fonctionne chaque solution. Merci

Répondre

1

je recommande ce qui suit:

Developer est un objet utilisateur. Distinguez les développeurs des utilisateurs avec un booléen is_developer dans votre schéma. Cela facilitera l'intégration des utilisateurs/développeurs (sans instructions de basculement). Vous pouvez ajouter une portée nommée pour trouver les développeurs de manière spécifique:

class User < ActiveRecord::Base 
    named_scope :regular_users, :conditions => { :is_developer => false } 
    named_scope :developers, :conditios => { :is_developer => true } 
    #you can then call User.regular_users or User.developers 
end 

Vous pouvez également utiliser User/Developer comme associations polymorphes. Par exemple. L'inconvénient de cette approche est qu'elle rendra votre code plus compliqué pour un gain sémantique faible ou nul.Je ne comprends pas vraiment ce que vous entendez par autorisation par défaut, mais cela semble être un problème de logique par opposition à une base de données. Est-ce que tout le monde a l'autorisation par défaut? Ensuite, vous pouvez l'ajouter sur * after_create *, ou lors de l'écriture de votre logique, supposer que c'est vrai (ou contrôlé par un drapeau booléen). Le code suivant crée une autorisation pour chaque utilisateur qui est true par défaut après leur création (pour les utilisateurs existants, vous pouvez ajouter les autorisations par tâche manuelle/rake). En ce qui concerne default_permissions, je suggère d'avoir un booléen * is_default * sur la table des permissions. De cette façon, vous pouvez avoir plusieurs autorisations par défaut (ou supprimer les autorisations par défaut plus tard). Par défaut, l'autorisation est une autorisation, il n'est pas nécessaire de différencier les modèles d'objet. C'est à dire.

class Permission < ActiveRecord::Base 
    named_scope :default_permissions, :conditions => { :is_default => true } 
end 

Enfin, assurez-vous de préciser pleinement toutes vos associations ActiveRecord, à savoir

class User < ActiveRecord::Base 
    has_many :apps 
    has_many :permissions, :through => :app_permissions, :as => :permissible #edited 
end 

class App < ActiveRecord::Base 
    belongs_to :app_permission 
    has_many :permissions, :through => :app_permissions, :as => :permissible #edited 
end 

class Permission < ActiveRecord::Base 
    belongs_to :app_permissions 
    belongs_to :permissible, :through => :app_permissions, :polymorphic => true #edited 
end 

class AppPermission < ActiveRecord::Base 
    belongs_to :permissible, :polymorphic => true #edited 
    belongs_to :app 
end 

Lorsqu'un utilisateur installe une application: ÉDITÉ CI-DESSOUS POUR POLYMORPHISME

Class User < ActiveRecord::Base 
    def get_required_app(app) 
    required_permissions = [] 
    app.permissions.each do |p| 
     if self.permissions.find(:first, conditions => { :permission_id => p.id }).nil? 
     required_permissions.push p 
     end 
    end 
    required_permissions 
    end 

    def install_app(app) 
    req = required_permissions app 
    return req if req.count > 0 
    #add user app 
    end 
end 

Espoir cela vous aide à résoudre votre problème et faites-moi savoir si vous avez besoin d'informations supplémentaires.

+0

Avec les autorisations par défaut, je veux dire qu'un utilisateur aura une autorisation qui sera par défaut lors de l'installation d'une application. Après l'installation de l'application, l'utilisateur peut modifier les autorisations pour l'application spécifique. – Immo

+0

Donc, les autorisations sont pour l'application/l'utilisateur? Par exemple. Bob installe 'Playground' avec la permission 'Run on swings', et plus tard, Jane installe Playground avec la permission 'Construire une nouvelle balançoire'? – ghayes

+0

Non. Une application peut écrire sur le disque, lire à partir du disque, supprimer du disque, etc. L'utilisateur peut avoir certaines conditions prédéfinies, par ex. Lecture à partir de disk = true, delete à partir de disk = false donc chaque fois qu'il installe une nouvelle application n'acceptera que les permissions qu'il n'accepte pas avec ses permissions par défaut. – Immo

0

Je ne peux pas dire à partir de votre question quelles sont les exigences spécifiques de votre entreprise, mais la plupart des gens utilisent un modèle basé sur les rôles pour la gestion des autorisations. Voir this question pour une discussion et une recommandation.

+0

Quel type d'information manque? – Immo

+0

Combien de types différents d'autorisations y a-t-il? Combien y a-t-il d'utilisateurs différents? Est-ce que les utilisateurs vont et viennent fréquemment en comparaison avec les différentes manières dont les permissions des utilisateurs sont configurées? La présomption concernant la sécurité basée sur les rôles est qu'il existe un nombre relativement limité de modèles d'autorisation relativement statiques - par ex. emplois/postes - et que de nombreux utilisateurs ont les mêmes modèles d'autorisations et vont et viennent fréquemment. Si chaque utilisateur dispose finalement d'un ensemble unique d'autorisations, la sécurité basée sur les rôles peut ne pas être utile. –

Questions connexes