Je travaille actuellement sur une application HRMS d'entreprise, mais il y a certains problèmes de gestion des autorisations auxquels je n'arrive pas à réfléchir :
1 Détermination des autorisations à plusieurs granularités :
Autorisations basées sur le département
Autorisations du module de base
Autorisations du module Personnel
Autorisations du module d'administration
Autorisations du module de recrutement
Autorisations du module de formation
Parmi les cinq modules ci-dessus, les quatre derniers dépendent du premier module, donc certaines données privées telles que la visualisation des données de présence seront placées dans les autorisations de base du module.
Autorisations basées sur la position
Directeur de département
Senior Manager
Gérant
Personnel ordinaire
Le module de base contient également le processus d'initiation, mais les employés ordinaires ne peuvent pas approuver le processus. Ce n'est qu'au niveau du manager et au-dessus que le processus initié par les employés subordonnés peut être ouvert.
Les utilisateurs sont directement liés aux autorisations
Car dans l'environnement de production actuel, certaines personnes seront assistantes-réalisatrices ou occuperont plusieurs postes. Pour cette situation, je laisserai l'utilisateur utiliser directement la gestion des tables user_permisson.
Question 1 : Conception du modèle de données
Serait-il plus difficile de vérifier la conception plus tard ?
Question 2 : Les interfaces affichées par les différents départements et postes sont légèrement différentes. Comment mettre cela en œuvre ? (Il est préférable de charger en mode ajax)
Par exemple, le service du personnel peut voir la bibliothèque de CV et les informations sur le personnel basées sur le module de base. Le niveau du manager peut approuver les employés subordonnés, les performances de l'équipe et d'autres données.
En attente de réponses d'experts expérimentés en ligne, merci beaucoup !
Ce projet est basé sur Laravel 5.2.29. Il est actuellement travaillé par une seule personne et devrait être open source.
Si vous êtes intéressé, vous pouvez évoluer ensemble.
Avez-vous pensé
RBAC
? Un service peut être un rôle, un poste peut être un rôle, et les autorisations spéciales d'un utilisateur peuvent également être divisées en un rôle indépendant. Votre idée est correcte. Le problème post-vérification qui vous inquiète devrait faire référence. à la table d'association d'autorisations. Un nombre trop élevé entraînera l'expiration du délai de requête, puis stockera les autorisations dans NoSQL.Concernant la deuxième question, si l'affichage est différent, il est préférable de combiner l'affichage du menu avec les autorisations. Il y a des éléments de permission pure + des éléments de menu dans le tableau des autorisations
.