Reprise du message précédent :

 
Code source dispo pour les clients ne veut pas dire source libre
Il avait dit qu'il encodait ses fichiers, mais on aurait pu imaginer que les clients aient à signer un contrat qui les oblige à ne pas divulguer le code source ou un truc du genre.

c'est surtout que joce ne veut pas qu'on lise son algo et ses optimisations durement trouvé, car sinon, le client lit le source pendant quelques temps, puis il se met a coder son propre code en utilisant les astuces de joce
 

 
Oui exact, j'utilise le mauvais terme  
 
Je pensais à ce que dis fabien, il est assez simple de "copier sans copier" comme on recopirait à l'école un devoir de maths en reformulant les réponses du voisins

Me semblait que Joce utilisait IonCube Encoder

oui...

Et bah jveux bien passer des mois à essayer de decrypter le code pour avoir ce forum

 
En fait dans ma tête tous les md étaient hébargés sur le même serveur ce qui aurait empeché d'acceder à la source, mais ça vient de me faire tilt que les gros client ont leur propore serveur...

ben, encore heureux

ioncube encoder

ca accélère

Question à tous : est-ce que vous avez prévu une "catégorie 0" comme sur les forum MD ? (catégorie modos+)
 
Si oui, comment l'avez-vous géré ? (sdtructure de tables en fait)

ben une catégorie comme les autres avec des droits d'accès spécifiques dans mon cas

Non, je n'ai pas prévu de catégorie "zéro". Ca sera une simple catégorie avec un attribut visibilité à false (donc cachée pour l'utilisateur standard), et visible pour d'autres.
 
edit: bon ben voilà, comme souk

Parce qu'on a prévu (avec KangOl) de faire une catégorie gérée dans le même jeu de tables que les catégories ordinaires mais avec des droits d'accès spécifiques. Seulement mon idée première était de faire un jeu de tables spécifique pour cette catégorie (à la manière des messages privés).
 
Alors je ne sais pas quelle est la meilleure solution ...

Ben la plus simple: tu laisses l'admin gérer les droits d'accès et basta
 
Je suis OK pour des tables spéciales pour les messages privés parce que c'est géré différemment. Mais pas pour une "cat zéro", car c'est juste une cat avec un droit d'accès particulier. Là est la nuance

 
 
Je gere une notion de profil pour mes categories. Donc, la cat admin est une cat comme les autres. Les droits ne sont pas donnés au 'simple' utilisateur.

Hmmm Ok apparement tout le monde se rejoint sur le fait qu'il ne faut pas séârer la catégorie 0 du reste mais juste gérer ses droits d'accès.

moi je fais un truc du genre:
 
if($cat==0) fonction_qui_verifie_si_modo();
 
sinon, j'affiche la cat normalement.

franchement tu fais un groupe modos auquel tu attribues un droit en écriture sur la fameuse cat et basta quoi
 
et pour les droits de modération, tu fais au cas par cas

Oui à condition de vérifier par la suite si c'est une catégorie VIP¨(et le cas échéant de faire les tests qui s'imposent).

Ben disons que si on respecte une éthique de programmation simple, avec une réutilisation, et des méthodes souples, c'est le moyen à long terme qui est le plus efficace.
Cf. mon forum (v4) qui gere les catégories selon les niveaux de droits, et la v5 qui gère selon les groupes d'utilisateurs (sont inclus admin, modos, etc..)

Oui mais le problème des groupes est que l'on ne peut pas mettre un meme user dans différents groupes (modos et admin par exemple) sans redondance, ce qui peut s'avérer lourd ...
 
D'un autre coté, je suis plutot contre les levels utilisateurs (utilisés dans la V4 du Sky-O-Mtic). J'ai donc pensé à faire des tables "$config_modo", "admins" et "supadmins" et tout ce qui ne fait pas partie de ce groupe reçoit suivant le cas une variable "temporaire" de utilisateur ou visiteur (suivant login effectué ou pas).

Dans le portail que je dévellope (truc polyvalent sur lequel je peux gréffer des modules), j'ai une table "users", une tables "groupes", une table "user-groupe" (un user peut appartenir à plusieurs groupes, et un groupe peut contenir plusieurs users), une table "droits", et une table groupes-droits (un groupe a plusieurs droits, et un droit peut etre acquis par plusieurs groupes), ca me permet de faire de la gestion de droits par groupes, en ayant autant de groupe que je veux, autant de types de droits que je veux, et c super souple
 
Par contre c'est un peu lourd à traiter car pour un user il faut vérifier tous ces groupes et tous les droits de ces groupes, ca fait plusieurs requetes (on peut alléger ca avec des jointures ? )

C'est justement pour ça sue je souhaite éviter les groupes d'utilisateurs.

sisi on peut  Enfin perso je ne mets pas de contrainte à ce niveau là. Lors de la vérification des privilèges, le forum ira chercher le plus haut privilège pour une catégorie donnée. Mieux encore, cette information spécifique est stockée dans la table users pour éviter un traitement complexe quand c'est possible (genre l'admin puisque par définition, il a accès à tout).

Je ne suis pas encore à l'implémentation des groupes (c'est pour beaucoup plus tard), mais je ferais bien d'examiner ça tout de suite

C'est marrant mais j'etais en train de me poser la question ces jours ci (si j'allais mettre des groupes ou pas), on ne parle pas bcp mais on cogites tous de notre cotés

klr, moi aussi y a une paire de semaine je me suis posé cette mème question.
 Faut il des groupes ou pas sur mon forum ?

Moi perso je suis opposé aux groupes et préfère avoir des tables séparées et utiliser des sortes de variables temporaires (en fait des var $is_supadmin = (true|false) et ainsi de suite suivant le level supposé). Je pense qu'indiquer le level en dur quelquepart n'est pas une bonne idée ... Sauf peut être pour un supadmin mais un meme utilisateur peut être admin de plusieurs configs de forums tout en étant non admin par ailleurs (idem pour les modos dans une config particulière).

Question subsidiaire: qui définit des classes personnalisées d'utilisateurs? Genre supadmin, admin, sous-admin, super modo, modo, petit modo...
(oui, je vais le faire)

Moi j'aurai 4 pseudo levels (pas de niveau en dur) définis par des résultats de requêtes (pour les supadmins, admins modos ou utilisateurs simples, si existence de cookies, sinon c'est un simple visiteur).

ah, moi j'avais défini admin, modo, utilisateur, lecteur (qui inclut le visiteur). Je ne vois pas la nécessité de définir 2 types d'admin

j'imagine que le supadmin a son utilité dans le cas de multiforums, c'est lui qui gere tout, les admins sont cantonnés à un seul forum j'imagine nan ?

Tout sdimplement que j'aurai un script multi-configs (comme les MD et le Sky-O-Matic V4).
Mais je n'aurai plus de super-modo (dont je ne vois pas l'intérêt autre que la praticité).

Moi j'ai supadmin / admin / super moderateur / moderateur / mediateur / posteur / invité
plus les groupes perso.

De mon coté, le forum fait parti de tout un site. Donc les profils sont pour le site.
 
J'ai defini un certain nombre de profils allant de simple intervenant, aux supadmin en passant par les modos, admins.
 
Au final, en fonction du profil, j'initiale un tableau de droits d'intervention au debut d'execution du script. Du coup, je n'ai plus de notion de profils par la suite, mais une notion de droits.
Pour definir les droits, j'ai une table avec par profil, ce qui est accessible comme action. Du coup, s'il me faut un nouveau type de droits, j'ajoute ca dans la table, modifie en 2 secondes ma fonction de recuperation/attribution de droits, et le tour est joué.

 
C'est globalement ce que j'ai

Ca facilite les evolutions, on ne se prend pas la tete avec des tests à ralonge sur les profils pour savoir qui à le droits.

Ah oui, en effet. Je pensais au début faire une application multi-forums puis j'ai laissé tomber par manque d'intérêt. Et puis je crois que ça nuirait à l'architecture que j'ai choisie en fait

Mêmes droits que les modos, sauf qu'ils ne peuvent pas donner de sanctions.