Reprise du message précédent :
Douleur Intestinale > Mon argument n'abonde pas dans le fait qu'il faille utiliser ou non des masques. Je dis juste que perdre 10 secondes à documenter ce qu'on fait permet d'éviter de faire perdre du temps à ceux qui passent derrière, quelque soit la méthode utilisée.
 

En aucun cas, je dis juste que les masques binaires, c'est du quotidien pour un développeur, et il n'y a rien de choquant à travailler avec, contrairement à ce qui a été dit plus haut.
 

C'est pas plus limité que d'avoir une table listant tous les jours fériers sous forme de lignes... Là faut que tu m'expliques en quoi une solution est plus limitée que l'autre... Au contraire (exemple tout à l'heure à l'appui, sous forme de lignes c'est plus limité)
 

La vérification à la mano est pourtant très simple (calculs entiers)...
(val mod 2^x) / 2^(x-1) = 1
 
 
Sinon, exemple d'une table CAL avec masques :
ANNE int16
CODE char(3)  [FER/VAC/INV/...]
JAN int32
FEB int32
MAR int32
APR int32
MAY int32
JUN int32
JUL int32
AUG int32
SEP int32
OCT int32
NOV int32
DEC int32
 
Je veux savoir si le "08/06/1958" était férier ou non ?

SELECT (mod(decode(month(madate), 1, jan, 2, feb, 3, mar, 4, apr, 5, may, 6, jun, 7, jul, 8, aug, 9, sep, 10, oct, 11, nov, 12, dec), pow(2, day(madate)) / pow(2, day(madate) - 1) ferier
FROM cal
WHERE annee = year(madate)
AND code = 'FER'

 
C'est pas la mort non plus hein...
Mais surtout, au lieu de faire tous les calculs dans le SGBD (qui n'est pas optimisé pour -sauf certains, SQL Server 2005 a tout ce qu'il faut pour faire des masques binaires par exemple-) j'ai juste à lire les 12 entiers et les traîter dans mon programme en utilisant de réels masques binaires... Rapide, simple et efficace.
 
Maintenant, la solution des tables :
 
JOUR datetime (déjà, on utilise un float64, c'est bien parti)
CODE char(3) [FER/VAC/INV/...]
FLAG byte (8 bits de plus)
 

SELECT flag
FROM cal
WHERE jour = madate -- avec tous les risques si madate = '08/06/1958 12:31:59' => ça marche plus !
AND code = 'FER'

 
=> plus simple au premier abords...
 
Sauf que par souci d'optimisations, on va rapidement être tentés de ne maquer que les lignes où flag = 1, c'est à dire "fermé".
Effectivement, là où la solution des masques, c'est 1 ligne de 14 champs par type de calendrier et par année, on se retrouve ici avec 365 lignes de 3 champs par type de calendrier et par année, ce qui peut rapidement s'avérer conséquent.
 
Du coup, on va faire :

SELECT top 1 flag
FROM (
SELECT flag
FROM cal
WHERE date = madate -- avec tous les risques si madate = '08/06/1958 12:31:59' => ça marche plus !
AND code = 'FER'
union
SELECT 0 FROM dual
) tmp

 
Ca se complique...
 
Mais surtout, le jour où personne n'a initialisé la table pour une période donnée, on ne sait pas détecter si c'est ouvert ou non renseigné...
Si je veux récupérer tous les jours ouvrés d'un mois, je dois faire un test qui n'utilise plus d'index, ce qui va devenir emmerdant surtout si j'ai de nombreux calendriers en base.
 
 
Bref, je cherche pas à démontrer quoi que ce soit. C'est juste qu'un choix ne s'impose pas sur l'autre. Pour un calendrier, je trouve ça plus pertinant de travailler avec un masque.

Avec un systéme de table de jours férié, tu n'as besoin que de :
- un enregistrement pour les dates fixes (le noel reste le 24 décembre quelque que soit l'année)
- un enregistrement pour les dates telles que la "pâques" si tu as mis également en place un calendrié lunaire (il existe d'ailleurs deux calendriés lunaire perpétuel ne nécessitant théoriquement un réajustement de 24h que tous les 228 ou 307 ans) ou un enregistrement par année si ca n'est pas le cas à moins de permettre une régle de répétition des dates ce qui permet de réutiliser le même enregistrement tous les 19 ans
 
C'est vrai que la table des jours férié se révèle alors plus complexe vu qu'il faut pouvoir indiquer des dates fixes mais aussi définir des dates soit en fonction de l'année (répétition tous les 19 ans) soit en fonction d'évènement stellaire et/ou d'un jour de la semaine.
 
Avec ton systéme de masque, t'es obligé de créer et créer et créer et créer sans fin de nouveaux enregistrements si tu veux gérer plus d'années. La seule solution pour éviter ça avec ta méthode serait de partir sur l'hypothése que les jours fériés d'une année donné seront identiques à ceux de l'année survenu 19 ans plus tôt ou plus tard (19 ans étant la période des calendriés lunaires) en espérant que d'autres régles n'interférent pas et que rien ne change entre temps.

Ah ouais, c'est lisible ton truc c'est fou...
Donc, un union avec des 0 ou des left outer join à n'en plus finir (parceque si je veux la liste des jours ouvrés, je suis vraiment comme un con...)
Un test "p'tet ben qu'c'est la date exacte, p'tet ben qu'c'est le jour sans tenir compte de l'année -donc date bidon, qui vient foutre la merde car y'a pas deux systèmes qui gèrent les dates de la même façon-" sans parler des différents problèmes tels que... C'est bien, pour les jours fériers, t'as 4 jours à modifier par an... Chouette. Mais la fermeture annuelle de l'entreprise, les fermetures pour cause d'inventaires, etc. c'est des dates fixes peut-être ? Bah non, donc tout les ans, de toute façon il faudra qu'une personne passe une heure à saisir les jours feriers dans tous les cas
 
Ah, et j'oubliais... Heureusement que c'est le lundi de pentecôte qui a été supprimé il y a peut. Parceque le jour où c'est le 8 mai, t'es comme un con ! Faut que tu saisisses comme "exception" tous les 8 mais depuis le début de l'exercice, c'est pratique ton truc !

Donc en fait comme tu sais pas utiliser une date dans un SGBD tu codes un système maison ?

c'est quoi le rapport ?
 
"14 juillet", c'est pas une date. aucun système ne sait le représenter.
 
sous unix, ça va être 14 juillet 19chaisplucombien (long) et sous windows, 14 juillet 1901 (float)
 
donc d'entrée de jeu, ça va être la plaie à utiliser depuis le programme final.
 
mais surtout, t'as l'air bien malin avec ton 14 juillet.
mais si demain le 14 juillet n'est plus férier (ou simplement, l'entreprise ne ferme plus ce jour là, donc ne le considère plus comme férier) tu fais comment pour l'historique ? si tu effaces ton 14 juillet 1901, t'as l'air bien con pour savoir si le 14/07/2007 t'était touvert ou non

Une heure pour saisir 2 ou 3 dates par an? Ben dit donc vraudrait mieux que tu changes de secrétaire si il faut autant de temps pour saisir ces infos avec le systéme que j'indique.
 
Quand aux jours férié qui ne le deviennent plus ou qui ne le sont qu'a partir d'une année donné, ca se prévoit depuis le début. Celui qui ne pense pas à ça à foiré une partie de son analyse. Le systéme de votre ERP, c'est "on considére que ca change tout le temps". C'est donc normal que tu n'ai pas le probléme. Avec celui que j'indique, tu dis simplement de quelle année à quelle année la régle est valide. Entre nous qu'est ce qui empéche de mettre l'an 9999  ou mieux, la valeur "null" comme année de fin de validité?
 
Aprés c'est sur, dans l'ERP dont tu parles, ils ont choisit la facilité, d'autres ont préféré coller à la réalité. Maintenant, à toi de me dire en quoi la solution que j'indique est plus limité que la tienne.
 
Au fait, pour les dates d'inventaires, certaines boites utilisent des régles fixes, d'autres le prévoyent juste un ou deux mois à l'avance. Mais pour autant, ca n'est pas des jours fériés : ca n'est pas par ce que c'est un jour d'inventaire qu'aucun enployé ne bossera. Pour les fermetures annuelles ca n'est là non plus des jours férié mais des périodes où la société envoie tout le monde en vacance : ca tombe dont dans le décompte de jour de vacance alors que ca n'est pas le cas pour les jours férié. Dans les deux cas, il est possible d'indiquer ce genre d'infos avec le systéme de ton ERP et avec celui que j'indique. Mais de toute maniére ca me parait tiré par les cheveux d'indiquer les jours d'inventaires dans une table de jour férié. En fait, ca me fait penser à la boite à je bossais l'an dernier, ils utilisaient certaines zones pour des infos qui n'avaient rien à faire là et ce par ce qu'ils n'avaient aucun endroit fait pour. Comme toi qui t'amuses à dire dans ta base : "du premier au 15 aout tous les jours sont férié ... enfin c'est presque ça mais par ce que j'ai rien pour le noter ailleurs."
 
Finalement j'ai l'impression qu'en fait ta table n'est pas une table des jours férié mais une table des jours de fermeture : à besoin différent, réflexion différente et parfois résultat différent. C'est normal qu'une table des jours de fermeture soit plus valable pour noter des jours de fermeture qu'un systéme de jour férié, mais dans le strict cadre des jours férié la solution que j'indique est au moins aussi adapté que la tienne.
 
EDIT : PS : C'est si dur que ça de noter 24/12 dans une base (choix du texte) ou ne pas tenir compte de l'année dans le programme (choix du stockage de fonction date) ?

 
Je sais que ma question est moins interressante qu'un troll sur les jours fériés, mais enfin...  je suis vraiment interressé par une réponse !   Qu'est-ce que les partisants de la solution sans bits proposent pour gérer des compositions/dépendances de droits ?

=> Au final, la secrétaire aura sous les yeux soit une liste des jours feriers, soit un calendrier dans lequel elle va cocher les jours feriers ou non. Ca ne change rien au schmilblick que tu utilises un système ou l'autre. Au contraire, ton système de dates de début/fin d'application, c'est source d'erreurs de saisie, et de présence d'un second niveau de saisie. C'est pas ce qu'il y ade plus ergonomique.
 

=> Sauf que moi je parle de "calendrier", pas spécifiquement de jours feriers. Idem, quand t'es une société qui fait de l'import/export, les jours feriers sont souvents différents entre import et exports, quand c'est pas un calendier spécifique pour chaque pays (ça dépend de tes contrats avec les transporteurs). Si tu t'amuses à faire une table pour les jours ferriers de chaque pays et chaques typesde calendiers, il y a un problème.
 

=> Non, comme donné dans mon exemple, c'est une table "calendrier". On y trouve aussi le calendrier comptable par exemple, qui ne sert que de référenciel pour les clôtures d'exercices...
 

=> Nan, c'est pas plus compliqué. Mais ne me dis pas que ça nécessite moins de documentation et des requêtes moins complexes à lire qu'un masque binaire.
 
 
Au final, je cherche pas à démontrer que le masque binaire est mieux, je réfûte juste un à un les arguments comme quoi c'est moins bien

bordel, ça fait 12 foisque je dis que j'ai posté un lien au début où il y a une réponse à cette question : masque ternaire (et si ça t'emmerde de ne plus pouvoir travailler avec des oppérations booléennes, tu passes à un masque quaternaire, donc la 4° valeur est "RESERVED"

Pour ça, t'as 4 solutions :

• le masque binaire
• la solution du "1 colone par niveau de droit"
• la solution d'une colone numérique indiquant le niveau de droit (le niveau 67 aura par exemple les même droits plus d'autres que le niveau 40)
• la solution d'une table des droits avec libellé des droits + table liant les droits aux groupes d'utilisateurs

Personellement, j'utilise maitenant la derniére même si j'ai pratiqué la troisiéme pendant un temps. Je ne suis pas fan des deux premiers mais certains le sont comme t'as pu voir page précédante. En bref, à toi de choisir en fonction de tes besoins et de tes affinités.
 

D'un autre côté, tu donne l'impression de chercher à prouver qu'on a une solution inférieure et tes arguments sont réfutable tout aussi facilement que les notres.
Bon, je m'arrête là cgo2 à raison, ca tourne au troll vu qu'on est tous borné sur la non supériorité de l'adversaire et qu'on a tous l'impression que l'autre cherche à prouver sa supériorité.

 
J'ai vu ton lien, mais je ne comprend pas en quoi un masque (qua)ternaire est une réponse, parceque :
- j'ai déjà une solution avec les masques binaires (relis mon message)
- l'autre solution présentée dans ce topic m'interresse, alors je demande comment faire ça *sans* masque.

 
Merci pour cette réponse mais visiblement j'ai mal posé ma question... Comment faire, avec la dernière solution (qui a le vent en poupe dans ce topic), pour dire "Si un utilisateur a le droit de modifier un message ALORS il DOIT avoir le droit de lire un message".
 
Actuellement j'utilise la première, et je stocke certains droits sur plusieurs bits pour gérer ce cas.

C'est le genre de trucs que tu forces à l'enregistrement des droits, soit dans l'appli (genre cocher la case modifier coche la case lire) soit carrément avec un trigger...(soit les deux, ce qui est encore mieux.)

(ce qui soit dit en passant est plus facile à gérer le jour où tu rajoutes une nouvelle permission qui doit être impliquée par une permission existante.)

 
Ok, effectivement ça correspond à ce que j'imaginais. Mais le soucis c'est que du coup ça oblige à rajouter pas mal de choses, notamment, je suppose, une table indiquant quel droit dépend de quel autre (sur laquelle, par exemple, le trigger irait taper pour vérifier la cohérence des droits).
 
Avec un système de masque binaire, comme je l'ai expliqué, ceci est géré sans avoir besoin de rien ajouter, simplement en définissant des droits sur plusieurs bits...

Ca c'est le probléme de la 4éme méthode si on reste dans un mode binaire.
La seule solution que j'ai trouvé pour gérer ça au niveau de la base, c'est de mettre plusieurs choix à certains droits. En numérique, ca donne par exemple 0, 1, 2 ou 3 pour le droit "message forum" soit "rien, lecture, écriture, moderation" en sachant que je considére qu'une personne à le droit de faire une action à partir du moment où elle a le niveau de droit correspondant ou un niveau supérieur.
Pour les cas du genre "participer mais pas créer" ou "créer mais pas participer", je le gére simplement en faisant deux droits différents.
 
C'est la méthode que j'ai trouvé, il y en a peut être d'autres que je n'ai pas vu.
 
PS : Avant que certains ne viennent me titiller sur ce point je précise que j'ai une table des libellé de droit dans la base (autodocumentation comme il disait ) ce qui me permet d'avoir le libellé affiché dans la partie admin ou quand je fais des requettes  sans perdre en lisibilité. (certe au prix d'une jointure quand il y a besoin)
 
EDIT : correction orthographique

 
ça dépend comment tu considères la chose.
Pour moi stocker ces relations entre les droits dans la base n'a pas d'intérêt dans la majorité des cas. Le seul cas où j'envisagerais de le stocker c'est sur une appli devant gérer une quantité de droits conséquente et comportant un bon nombre de relations de ce genre.
Sinon tu te contentes de l'implémenter au niveau appli/triggers, et même si tu l'oublies il n'y a pas mort d'homme, de toute manière, c'est simple à ajouter par la suite, contrairement à ta solution qui suppose une connaissance exhaustive des droits à attribuer à l'avance...

 
Ca me plait bien, mais au niveau du code ça n'est pas plus lourd ? (je sors un peu du contexte uniquement bd). Par exemple, pour l'action "créer", tu fais comment ? Tu es obligé de vérifier si l'utilisateur à (par exemple) :
"créer seulement"
ou "créer et modifier"
ou "créer et modifier et supprimer"
ou "créer mais pas participer"
etc.
 

au niveau appli tu peux faire exactement la même chose quelle que soit la solution dans la base, il suffit de générer les bonnes requêtes ensuite...

Si tu sais que tel droit est soumis à tel autre de maniére logique et compréhensible par l'utilisateur, alors il vaut mieux utiliser une liste déroulante ou des "boutons radios" que des cases à cocher dont on force parfois la valeur et qu'on grise pour empécher les modifs. Par expérience, je peux te dire que tu finiras toujours par tombera sur quelqu'un qui viendra te dire "je ne comprendra pas, je ne peux pas décocher telle case".
Sinon, je suis d'accord. C'est une solution.

Ce n'était qu'une suggestion d'UI...on peut faire ce qu'on veut, de ce coté là...
(les checkboxes montrent mieux le parallèle avec la structure de la base, juste.:D)

 
Non parceque si j'ai bien compris, dans un cas le droit "créer" est unique (soit un bit, soit un id selon la solution utilisée), alors que dans la solution que propose omega2 le droit "créer" peut être contenu par plusieurs droits comme "créer et participer", "créer mais pas participer", etc. D'où une plus grande complexité au niveau du test, non ?

Je teste simplement si "niveau du droit">="valeur du droit permettant de créer"
Aprés, s'il n'a pas le droit de "participer" (mauvais choix de nom, j'aurais du dire "droit de répondre" ) aux discutions déjà ouverte, c'est un autre probléme qui ne joue pas sur le droit de création. (sinon autant faire un nouveau niveau de droit plustôt que de le diviser en deux)

Tu ne feras pas les mêmes tests, c'est tout. Mais lui ne va récupérer qu'une ligne dans la base pour toutes ces nuances.
Au lieu d'associer une valeur à un droit il associe une valeur à une combinaison de droits, c'est tout.

D'accord.. Je vais prendre l'exemple d'un système de message extrement basique, qui contient les permissions suivantes :
- créer un message
- modifier mon message (nécessite "créer un message" )
- modifier n'importe quel message (nécessite "créer un message" et "modifier mon message" )
 
Si j'ai bien compris avec la solution d'omega2 c'est :
- créer un message = 1
- modifier mon message = 2 (2 > 1 donc il a aussi le droit 1)
- modifier n'importe quel message = 3 (3 > 1 donc il a aussi les droits 1 et 2)
 
C'est bien ça ?
 
Si oui, il y'a des choses que je fais actuellement avec mes masques binaires et que je ne comprend pas comment faire avec votre méthode :
 
- Comment faire pour gérer des droits totalements différents (une autre partie de l'appli qui n'a rien à voir avec la gestion des messages) ? Vu que les id de la db s'incrémentent, ils seront supérieurs à ceux là, alors qu'ils ne doivent pas être liés.
 
- Comment faire pour gérer un droit "peut modifier tous messages *sauf* le mien" ?

 
Je dirais plutôt qu'il n'y a qu'une entrée dans sa table des droits, qui vaut 1 si on peut seulement créer, 2 si on peut aussi le modifier, 3 si on peut aussi le modifier.
 

 
Je ne comprends pas le lien avec l'id. Un id ne contient pas d'info, sa seule fonction est d'être unique.
 

ajouter une valeur 4 qui correspond.

Désolé, effectivement, gt trop parti dans mon troll pour lire convenablement ta question, méa culpa
 
Donc, si j'ai bien compris.
 
T'as un droit "LIRE" et un droit "ECRIRE".
Tu veux créer un "droit" "MODIFIER", qui est en fait le cumul des deux (LIRE + ECRIRE) c'est bien ça ?
 
Alors justement, tu parles de la solution en masqie binaire :
 
Lire = 1 (01)
Ecrire = 2 (10)
Modifier = 3 (01 + 10 = 11)
 
"Modifier" qui est un droit "composé", peut être assimilé à un "modèle".
 
Donc il suffit de l'adapter à la solution des "lignes".
 
Exemple :
 
RIGHTS
----------
USER_ID
ITEM_ID
RIGHT_CODE
 
Ces trois champs font partie de la PK.
 
=> Cette table permet de lister pour tous les couples (user_id, item_code) la liste des right_code.
 
Tu veux mettre donc le "modèle" MODIFIER...
 
Il te suffit donc de faire une nouvelle table :
 
RIGHTS_MODEL
-----------------
MODEL_CODE
RIGHT_CODE
 
Jeu d'exemple :
 

 
 
Je veux modifier les droits de l'utilisateur 1 sur l'item 1 afin d'ajouter le droit "MODIFIER" :
 

DELETE RIGHTS WHERE USER_ID = 1 AND ITEM_ID = 1 AND RIGHT_CODE IN (SELECT RIGHT_CODE FROM RIGHT_MODEL WHERE MODEL_CODE = 'MODIFIER');
INSERT INTO RIGHTS (USER_ID, ITEM_ID, RIGHT_CODE) VALUES (SELECT 1, 1, RIGHT_CODE FROM RIGHT_MODEL WHERE MODEL_CODE = 'MODIFIER');

(on peut aussi faire le insert en une passe en rajoutant un not exists mais bon, autant faire en deux fois dans une transaction c'est plus facilement maintenable)

Troll : Ceci dit, là encore, on voit que le masque est plus facile...
 
UPDATE RIGHTS SET RIGHTS_MASK = RIGHTS_MASK | 3 WHERE USER_ID = 1 AND ITEM_ID = 1;
 
(et pas de table supplémentaire )

 
Tout à fait, c'est exactement ça ! Ton idée n'est pas mal mais...
 

 
... je suis d'accord. Les arguments en faveur de la méthode "par ligne" m'ont donné à reflechir, mais au final, sur ce point précis, toutes les solutions proposées me paraissent toutes plus lourdes et complexes (tables supplémentaires, triggers, etc.) que la solution que j'utilise actuellement à base de masque binaire. Donc malgré tous les défauts qu'on peut lui trouver (c'est vrai que c'est pas lisible sans doc, que c'est pas "pur" dans une db, etc), c'est la solution que je préfère pour le moment.

MagicBuzz 1 - Les autres 0
 

Ok lol.
 
Mets en résolu, qu'on arrête ce troll immense.

Heureusement que la question portait pas sur les calendriers au final

 
t'aurais fait le test de connard prétentieux, par hasard?

C'est bien ça.
 

Là, ca dépend de ce que t'entend par "peut modifier tous messages *sauf* le mien".
Si c'est "peut modifier tous les messages sauf ceux des admins" ou "sauf ceux des modérateurs", alors t'as deux solutions :
 - mettre en place un niveau intermédiaire qui se situera entre "peut modérer tous les messages et peut modifier ses messages à lui" (donc entre les niveaux lecture et modération si on reprend les terme que j'avais utilisé plus haut) Ca nécessitera quand même d'avoir un "si (posteur est admin et droit >= n+2) ou (posteur est modo et droit >= n+1)" ou ((posteur est ni admin ni modo et droit) >= n) alors"
 - Mettre en place une régle dans le programme pour empécher qu'on puisse modérer les messages de quelqu'un situé plus haut dans la hiérarchie du site ou du forum (ce qui nécessite de gérer une sorte de hiérarchie)  ou d'empécher de modérer une personne qui a des droits de modération de même niveau ou plus élevé sur un droit donné. En tout cas ca n'a plus rien à voir avec la base de donné. A noter qu'avec cette solution, sauf si tu te bases sur les droits de modération, tu ne peux pas dire que "le modo X peut modérer l'admin Y alors que l'admin Y n'a pas le droit de modérer les modos"  
 
Si c'est "peut modifier tous les messages sauf ceux de Toto" ou "peut modifier tous les messages sauf le message numéro 123456", là il faut partir dans un systéme de gestion des exceptions. Ca n'est plus une simple question de niveau de droit et ca s'apparente d'avantage aux "listes noires" de certains forums du moins d'un point de vu fonctionnement.
 
PS : Comme on peut mettre 256 niveaux de droits dans un bit, (en comptant le "pas de droit" ) il est conseillé de sauter des numéros avec ce systéme afin de pouvoir insérer des droits intermédiaires sans avoir à tout décaler ce qui risquerait de poser de gros problémes.
 

Je ne vois pas le rapport avec les id, c'est normal? En fait, les id sont censé servir uniquement à la manipulation d'une ligne précise de la table. Ca serait donc une erreur de mettre les niveaux de droits en id. En plus il faudrait se rappeler de la liste de tous les niveaux de droit utilisé quelque soit le bout du programme afin d'essayer d'en trouver un de libre. C'est 1000 fois trop prise de tête pour être gérable.
 
En dehors de ça, comment fait tu ce genre de chose avec ton systéme? Tu rajoutes des bits à n'en plus finir même quand c'est deux parties du logiciel qui n'ont aucun rapport ou bien tu géres deux enregistrement indépendants l'un de l'autre?
Certe avec un systéme de masque tu peux gérer dans un même enregistrement la création d'une discution, la lecture, la participation et la modération de celles déjà ouvertes mais pour autant même avec un systéme de masque il serait débile de mélanger à la fois l'administration de la boutique en ligne et le droit de poster sur le forum.
 
De mon côté c'est pareil mais en encore plus séparé. Dés que deux droits ne sont pas dépendant l'un de l'autre, je les sépare en deux enregistrements. Comme dit plus haut, il y a un droit à deux niveaux (je le droit ou je l'ai pas) sur l'ouverture d'une discution et un autre qui s'occupe de la lecture, la participation et la modération du forum. En fait, pour reprendre ta remarque sur les identifiants, même si on les utilisait comme niveau de droit, (ce qu'il ne faut surtout pas faire) comme on a le droit lancement d'une discution qui est dans un autre enregistrement, on n'aurait aucun risque de voir apparaitre spontanément des droits de modération pour tout le monde et ce même si le droit "lancement d'une discution" correspondait à un id supérieur à celui de la modération.

Pas la peine, je sais que je le gagne à coup sûr

Juste pour rajouter mon grain de sel
 
Les deux gestions de droits ayant leur intérêt... une cohabitation des deux serait envisageable...
 
un système de masque pour ce qui est droit de type gestion de fichiers.
un système différent pour ce qui est des droits d'accés.
 
M'enfin vla ma conclusion (et finalement ce que je serait t'enté d'utiliser si j'avais à gérer tout ça)