Système de gestion de produits multi-user avec droits

Bonjour à tous

Je souhaiterai avoir vos avis/recommandations sur la meilleure façon de créer mon application de gestion de produit (le mot produit reste vague car c'est pour mon travail).
Je me débrouille en php, html, mysql, js (jquery) et css.
Ce projet fait partie d'un ensemble plus grand d'applications, accessibles par un "portail".
Cela signifie qu'il y a déjà des éléments en place, notamment la base de données avec la table "utilisateurs" (que je ne peux donc plus modifier).

Voici le projet :

Mes utilisateurs (U1, U2...) sont regroupés par équipes (WP1, WP2..).
Chaque utilisateur utilise(!) un ou des produits (P1, P2...).
Ces produits sont rangés dans des emplacements particuliers (4A01, 2C05... disons un pseudo regex [1-6][A-F][01-99])

La difficulté est que les utilisateurs ne veulent pas que les autres aient accès à leurs produits directement.
Tout le monde peut voir la liste des produits mais seuls les utilisateurs propriétaires des produits peuvent en avoir le détail.
Par propriétaire, j'entends celui qui possède le produit, celui qui l'a rentré dans la base de données, celui qui sait où il est stocké...
Un non-propriétaire ne pourra voir que la liste des produits et à qui il faut se renseigner pour en avoir le détail et la localisation.

Par exemple
U1 a le P1 et P2 qu'il a rangé en 1A01 et 1A02.
U2 a le P3, rangé en 2B06.

du coup tout le monde sait qu'il y a 3 produits (P1-P3) mais si U1 veut le produit P3, il doit se rapprocher de U2 qui lui donnera les infos (ou non ;-) )

difficulté supplémentaire: les utilisateurs travaillent en équipe.
Ainsi U1 peut autoriser U10 et U11 à avoir accès à ses produits (ici P1 et P2)...
Il y aurait donc plusieurs niveau de droits sur chaque produit.
exemple pour P1: admin = U1, autorisé = U10, U11,
tous les autres seraient simple user (voit que le produit existe mais doit solliciter admin et/ou autorisé pour l'accès)

Auriez-vous des conseils sur la façon de coder ça ? d'organiser les relations entre les tables...?

Je voyais un truc du genre

id_produit	nom_produit	detail_produit	localisation_produit	quantité_produit	admin_produit	autorise_produit
1	P1	produit1	1A01	6	U1	U10,U11
2	P3	produit3	2B06	2	U3	null

• Est-ce que je dois créer une table pour que les utilisateurs soient "liés" entre eux ? (par exemple U1 avec U10 et U11 au sein de la même équipe)

• Comment gérer au mieux les multi-users comme dans la case U10,U11 (je peux toujours faire un split puis un foreach... y'a peut-être mieux...)

• Je suis quasi certain que les jointure sql seront mes amis, mais là je ne suis pas encore au point ;-)

Enfin tout cela me permettra en tant qu'administrateur global d'extraire la totalité des produits pour assurer un suivi/état des lieux et éventuellement de mutualiser les produits en doublon.

Merci ;-)
Rod

les groupes d'utilisateurs sont juste là pour organiser les utilisateurs, les groupes ne changent rien aux autorisations accordées aux produits, c'est bien ça ?

Bonjour mathieu

Oui c'est bien ça. Les groupes sont là pour permettre à un admin de gérer qui peut avoir accès aux produits... histoire d'éviter de devoir donner individuellement des droits sur chaque produit.
Ici, un admin ou un membre de son groupe créé, modifie, vois les détails d'un produit.

Merci pour l'intérêt que tu portes à ma question :-)

dans ce cas je trouve que la table "produit" à une structure correcte. tout en sachant que la théorie voudrait que la colonne "autorise_produit" soit gérée par une autre table avec les colonnes suivantes :

• id_produit
• id_utilisateur

avec une clé primaire composée de ces 2 colonnes.
cette table séparée permettrait par exemple de retrouver plus rapidement tous les produits accessibles par un utilisateur. elle permet aussi de prévoir des évolutions : par exemple différents niveaux d'autorisation en ajoutant une colonne qui indique si l'utilisateur peut tous modifier ou juste voir tous les détails sans pouvoir les modifier.

en ce qui concerne la gestion des équipes, je pense que ça se gère simplement avec une table "equipe" avec ces colonnes :

• id_equipe
• nom_equipe
• admin_equipe (bin oui il faut toujours un chef ;))

et donc la table des utilisateurs aura une colonne "id_equipe".

Merci Mathieu

Je ne pense jamais à ça car je ne suis pas encore à l'aise avec les jointures sql (autodidacte à mes heures perdues).
Je vais réfléchir à tout ça et revenir vers toi si tu es d'accord pour peaufiner l'ensemble et surtout penser aux évolutions futures comme tu le soulignes...

Rod

Bonjour Mathieu

ça donnerait le diagramme suivant.
Du coup je ne suis pas certain de admin-produit et autoriz_produit dans la table produit.
ça me parait rendre les choses plus compliquées, non?
est-ce qu'avec la table autoriz ça ne fait pas doublon...?

Et puis pour la localisation_produit, je devrais peut-être faire autrement...
Je m'explique. En fait les codes 4A01 par exemple décrive l'armoire 4, l'étagère A et l'emplacement 01...
Est-ce qu'une table avec toutes les localisations différentes serait pertinente et dans ce cas, la table produit aurait plutôt un champ id_localisation ...?

qu'en penses-tu ?

Pièce jointe 620058

Citation:

---

Envoyé par rodblochon

Du coup je ne suis pas certain de admin-produit et autoriz_produit dans la table produit.
est-ce qu'avec la table autoriz ça ne fait pas doublon...?

---

oui la table des autorisations est là pour remplacer le champ "autoriz_produit"
par contre admin_produit contient l'information du propriétaire du produit donc cette colonne reste dans la table produit.

Citation:

---

Envoyé par rodblochon

ça me parait rendre les choses plus compliquées, non?

---

complètement, sinon ça ne sera pas drôle ;)
plus sérieusement, un des buts principaux de la normalisation des base de données est de rendre les applications évolutives. donc en utilisant cela vous allez peut être avoir besoin d'une heure en développement en plus pour le mettre en place, mais ça sera plusieurs heures d'économisées quand vous allez ajouter des fonctionnalités comme par exemple des niveaux d'autorisations différents.

si vous voulez en savoir plus sur la théorie de la normalisation, vous pouvez regarder là :
https://fsmrel.developpez.com/basesr...normalisation/
je pense que la structure actuelle que vous avez préparée est très proche de la structure optimale donc après la lecture de cet article, ne vous embêtez pas à repartir de zéro en suivant les différentes étapes indiquées, vous arriverez certainement au même résultat.

Citation:

---

Envoyé par rodblochon

Et puis pour la localisation_produit, je devrais peut-être faire autrement...
Je m'explique. En fait les codes 4A01 par exemple décrive l'armoire 4, l'étagère A et l'emplacement 01...
Est-ce qu'une table avec toutes les localisations différentes serait pertinente et dans ce cas, la table produit aurait plutôt un champ id_localisation ...?

---

une table avec les localisations peut être utile si par exemple vous voulez faire une recherche de tous les produits de l'armoire 4. ou par exemple si le nom de l'armoire 4 change et s'appelle par exemple "armoire des outils à plumes".
donc la table produit aura 2 colonnes "id_localisation" (ou "id_armoire") et "details_localisation_produit" qui contiendra par exemple "étagère A emplacement 1".

Merci Mathieu

je regarde tout ça avec intérêt et reviens vers toi.
Je suis impatient de relever ce challenge ;-)

Bonjour Mathieu

voici ma nouvelle arborescence.
Il y a plusieurs relations redondantes (id.user sert sur 3 tables différentes)
mais qui me permettront de :
- lister tous les produits
- savoir à qui sont les produits
- savoir où sont les produits de son équipe (mais pas ceux des autres équipes)
- créer des équipes
... et sûrement d'autres fonctions
La création des administrateurs sera faite en manuel je pense (je me ferai une interface admin pour ça)

Par contre je vois pas trop comment faire ma requête pour lister mes produits ...

Code:

---

SELECT * FROM table_produits WHERE table_produits.id_produit = table_autoriz.id_produit AND table_autoriz.id_user = :user

---

avec un execute PDO sur :user

Du coup pas besoin de jointure dans ce cas...

Mais si je veux en plus avoir la localisation, je vais devoir ajouter une clause WHERE ou faire un join sur id_localisation de la 1ere partie de la requête ?

Rod

Pièce jointe 620608

à quoi correspond l'information "id_equipe" dans la table "localisation" ?

en ce qui concerne la requête sql, votre exemple retournera une erreur qui voudra dire que la table "table_autoriz" est inconnue dans cette requête.
regardez le cours suivant, il détaille plusieurs types de jointure mais lisez surtout ce qui a un rapport avec les jointures internes qui sont les plus utilisées :
https://sqlpro.developpez.com/cours/sqlaz/jointures/

plus vous allez utiliser des jointures et plus cela va devenir logique pour vous.

Bonjour Mathieu

l'id_equipe dans la table_localisation serait là pour attribuer des localisations à toute une équipe et retrouver ces localisations d'équipe...
ça peut faire doublon avec id_admin (qui est relié à une équipe) et la table_autoriz_produit...


je m'en vais lire la doc sur les jointures :-)
ça m'aidera à comprendre cette logique et éviter ce type de doublon

Je dois encore mûrir toute cette réflexion et me poser pour bien définir toutes les fonctions dont j'ai besoin et comment les faire fonctionner.
je reviendrai dans quelques temps (c'est possible qu'il se passe quelques mois, je code lentement en bon amateur que je suis!) pour te donner un retour (positif ou plein de bugs).

Encore merci !!