Voici ce que je retiens jusqu'à maintenant de cette discussion. Si rub a besoin d'un utilisateur générique, c'est pour

- qu'il ait davantage de droits que le visiteur non connecté
- ne pas obliger les visiteurs à s'enregistrer

Concernant le premier point, il faut regarder du côté de la demande 148.

Pour le second point par contre, c'est indéniable : il faut un utilisateur générique. En conséquence, il faudrait bloquer l'accès à la page profile.php et qu'en parallèle, l'administrateur puisse modifier ce paramétrage. Sur ce dernier point, je vous envoie sur le topic 5098.

Voici une proposition pour les types d'utilisateur :

- type normal (ce que l'on connaît actuellement)
- type special (le webmaster et le guest)
- type générique

Un utilisateur générique aurait accès à une personnalisation allégée : pas de modification du password/email, les changement de paramétrage d'affichage sont propres à la session, il n'y a pas de persistance en base de données. Cela rejoint la demande 81.

Au fond, ce qui m'embête avec cette notion d'utilisateur générique, c'est que l'historique évolué perd tout son sens.

z0rglub a écrit:

Voici ce que je retiens jusqu'à maintenant de cette discussion. Si rub a besoin d'un utilisateur générique, c'est pour
- qu'il ait davantage de droits que le visiteur non connecté
- ne pas obliger les visiteurs à s'enregistrer

Trés bien résumé, ceux sont bien les besoins.

z0rglub a écrit:

Voici une proposition pour les types d'utilisateur :

- type normal (ce que l'on connaît actuellement)
- type special (le webmaster et le guest)
- type générique

Si on prend en compte la notion d'admin, ca nous fait:
  o normal user (0 à n users)
  o normal admin (0 à n users)
  o special webmaster admin (un super admin quoi, l'admin des admin) (1 user obligatoire)
  o guest (jamais admin) (1 user obligatoire)
  o generique (jamais admin) (0 à n users)

Non? J'insiste sur la notion d'admin, car avec trois types, on a 5 possibilités.
Et tant qu'a définir des types, je dirais plutot:
  o type normal
  o type webmaster
  o type guest
  o type generique

Je prefére une séparation du type spécial

z0rglub a écrit:

Un utilisateur générique aurait accès à une personnalisation allégée : pas de modification du password/email, les changement de paramétrage d'affichage sont propres à la session, il n'y a pas de persistance en base de données. Cela rejoint la demande 81.

OK pour générique et bonne idée que la demande 81 qui devrait être applicable aus users genriques et à l'user guest aussi!?

z0rglub a écrit:

Au fond, ce qui m'embête avec cette notion d'utilisateur générique, c'est que l'historique évolué perd tout son sens.

C'est vrai, tout dépend de ce que l'on veut faire avec son site... si on mets des users generiques, je ne pense pas qu'on veuille vraiment un historique détaillé...

VDigital a écrit:

Pour tout le reste, je ne comprends toujours pas l'intérêt.

[...]
Ce que je dis, c'est qu'on sait déjà attribuer un groupe par défaut quand un guest s'inscrit (on crée un connect_group dans default_global, et dans register on ajoute le lien avec user_group), ce n'est pas compliqué.

Justement, le but est de ne pas s'incrire... mais juste de donner un sésame... si tu vas sur la gallerie un guest ne voit rien car c'est des photos de famille...
Mon besoin est de voir des catégories en précisant un sésame d'entrée... En fait, je veux plusieurs guest différents avec sésame... (houuu, c'est pas claire...)

VDigital a écrit:

Ensuite, ce groupe a accès à trois catégories en plus de celles de guest (exemple d'organisation: guest voit 2% des images, groupe par défaut voit 5%, Groupe des membres reconnus voit 50%, Groupe d'actifs (ceux qui commentent) 70%, ceux qui partagent des images 80%, ceux qui reviennent réguilièrement au bout d'un an 100%).

OK mais c'est un contexte ou les s'incrivent (ce que je ne veux pas forcement)...
D'ailleurs pourquoi, je ne veux pas d'inscription:
  o car il y a la moitié des visiteurs qui ne savent pas faire (car le net c'est plus pour leur enfants que pour eux)
  o car il y a la moitié des visiteurs qui trouvent fasitidieux de s'inscrire
  o car il y a la moitié des visiteurs qui sont paranos et ne donnent pas leur email, ect... et donc pas d'inscription
  o et puis il rest la moitié qui prenne le temps de s'inscire (ca nous fait 200% de visiteurs tout ca! ;-)

VDigital a écrit:

La seule chose qui m'interresserait serait d'avoir une notion de la complexité de son mot de passe.

C'est une bonne petite idée, ca!

rub a écrit:

Si on prend en compte la notion d'admin, ca nous fait:
  o normal user (0 à n users)
  o normal admin (0 à n users)
  o special webmaster admin (un super admin quoi, l'admin des admin) (1 user obligatoire)
  o guest (jamais admin) (1 user obligatoire)
  o generique (jamais admin) (0 à n users)

Non? J'insiste sur la notion d'admin, car avec trois types, on a 5 possibilités.
Et tant qu'a définir des types, je dirais plutot:
  o type normal
  o type webmaster
  o type guest
  o type generique

Je prefére une séparation du type spécial

En fait, à relire ma proposition et la tienne, je me demande pourquoi on n'étendrai pas le "status" actuellement existant ? user_infos.status au lieu d'avoir 'guest' et 'admin' comme possibilité aurait :

- webmaster (modifiable uniquement via le fichier de configuration)
- admin
- normal
- generic
- guest (modifiable uniquement via le fichier de configuration)

$user['is_admin'] = ($user['status'] == 'webmaster' or $user['status'] == 'admin') ? true : false;
$user['is_the_guest'] = $user['status'] == 'guest' ? true : false;

Plutôt que de créer une nouvelle notion, on étend une notion existant. Qui en pense quelque chose ?

z0rglub a écrit:

rub a écrit:

Si on prend en compte la notion d'admin, ca nous fait:
  o normal user (0 à n users)
  o normal admin (0 à n users)
  o special webmaster admin (un super admin quoi, l'admin des admin) (1 user obligatoire)
  o guest (jamais admin) (1 user obligatoire)
  o generique (jamais admin) (0 à n users)

Non? J'insiste sur la notion d'admin, car avec trois types, on a 5 possibilités.
Et tant qu'a définir des types, je dirais plutot:
  o type normal
  o type webmaster
  o type guest
  o type generique

Je prefére une séparation du type spécial

En fait, à relire ma proposition et la tienne, je me demande pourquoi on n'étendrai pas le "status" actuellement existant ? user_infos.status au lieu d'avoir 'guest' et 'admin' comme possibilité aurait :

- webmaster (modifiable uniquement via le fichier de configuration)
- admin
- normal
- generic
- guest (modifiable uniquement via le fichier de configuration)

Code:

$user['is_admin'] = ($user['status'] == 'webmaster' or $user['status'] == 'admin') ? true : false;
$user['is_the_guest'] = $user['status'] == 'guest' ? true : false;

Plutôt que de créer une nouvelle notion, on étend une notion existant. Qui en pense quelque chose ?

Je vous adore... dans vos réflexions, j'explique:

Il y en a un qui nous dit "Justement, le but est de ne pas s'incrire... " et "définir des types";
L'autre, gentillement, glisse "je me demande pourquoi on n'étendrai pas le "status" actuellement existant ? user_infos.status"

C'est bien beau tout ça.
Les types vous les mettez dans quelle table? Comment faites-vous le lien entre l'IP lamdba qui visite le site et ce fameux type.
Et user_infos.status, c'est renseigné pour qui... les inscrits.

"Justement, le but est de ne pas s'incrire... "

Allez, on pose le clavier. On réfléchi dix minutes si il faut mais je veux une explication claire.
Pourquoi? La discussion part sur de fausses bases, celles qui pense que quiconque devient différent des autres par le fait de l'existance de "type". Comment lui attribuer "type"?
Sans cette explication, c'est parfaitement inutile. Désolé d'être un peu cassant.

Pas le temps de faire une petite nuit, he hop, une multitude de post!!! ;-)

z0rglub a écrit:

Si tu pouvais créer un topic bien distinct de celui-ci pour parler de ton idée, cela éviterait la confusion entre les 2 besoins.

Oui, car les besoins différents.

z0rglub a écrit:

En fait, à relire ma proposition et la tienne, je me demande pourquoi on n'étendrai pas le "status" actuellement existant ? user_infos.status au lieu d'avoir 'guest' et 'admin' comme possibilité aurait :

- webmaster (modifiable uniquement via le fichier de configuration)
- admin
- normal
- generic
- guest (modifiable uniquement via le fichier de configuration)

Plutôt que de créer une nouvelle notion, on étend une notion existant. Qui en pense quelque chose ?

Bien que non ecrit, c'est que ce que j'avais en tête, etendre le status du user infos...
Je n'avais pas été clair... ;-) pour moi "type générique" signifie "nouveau type de status appélé generic"
Pour+++ pour la proposistion de z0rglub.
Je ne parlerais donc plus de type mais de status pour une meilleur compréhesion.

vimages a écrit:

[...]
un statut intermédiaire d'admin
[... ]

Effectivement, si on part sur le principe d'étendre le principe de status, on peut en definir plein d'autres et même faire un parammétre pour chaque status. Ca va rejoindre ce que VDigital à dit après.
La notion que tu evoques pourrais être le status "stagiaire admin" lol non sérieusement "manager" peut-être...
Pour résumé, les status seront:
- webmaster (modifiable uniquement via le fichier de configuration)
- admin
- normal
- generic
- guest (modifiable uniquement via le fichier de configuration)
- manager (gestion des categories, synchro...)

VDigital a écrit:

Les types vous les mettez dans quelle table? Comment faites-vous le lien entre l'IP lamdba qui visite le site et ce fameux type.

Justemenent, le type n'est pas le bon terme... il faut parler de status (cf au dessus) et pour la table c'est la table user_infos.
Pourquoi, veux-tu faire un lien entre l'ip et le status? C'est pas nécessaire dans ce que je pensais...

VDigital a écrit:

Et user_infos.status, c'est renseigné pour qui... les inscrits.

"Justement, le but est de ne pas s'incrire... "

Allez, on pose le clavier. On réfléchi dix minutes si il faut mais je veux une explication claire.
Pourquoi? La discussion part sur de fausses bases, celles qui pense que quiconque devient différent des autres par le fait de l'existance de "type". Comment lui attribuer "type"?
Sans cette explication, c'est parfaitement inutile. Désolé d'être un peu cassant.

Pas cassant du tout... On réflechit au truc et chacun essaie de comprendre l'autre... et je penses qu'il y a des incompréhension.
Le status seront distribués uniquement par un admin ou un webmaster, un user par defaut sera normal.
Le status géneric sera appliquer sur un user inscrit/créer par un admin/webmaster.

Ma petite explication aussi sur le mot incrire... qui a sens:
  o inscription dans le sens création de user  (appeler maintenant création)
  o inscription dans le sens connexion du site (appeler maintanant identification de connexion)

Moi, ce que je veux:
o c'est que certaines personnes ne créer pas de user mais utilise pour la connexion un peu des users generiques que j'ai mis en place.
o pour les toutes personnes, il doit y avoir une identification de connexion

VDigital a écrit:

[
Les groupes actuellement ne servent a donner que des droits vis à vis des catégories.
Mais en sécurité en général, on peut donner des "Autorités" ou bien d'autres droits à un groupe, il serait stupide d'avoir à rechercher dans une liste de 50 ou 100 membres qui a le droit de créer ceci ou cela / de voir ceci ou cela / de faire ceci ou cela.
Alors qu'il suffit de dire monsieur rub appartient aux groupes:
"généric" / "guest" / "plus" / "droits"
et monsieur vimages:
"guest" / "plus" / "creatif" que ses groupes soit des droits de voir/administrer des catégories ou des droits de faire des actions (ouvrir/fermer l'upload, valider les commentaires du site, etc...).

Je ne veux pas toucher aux groupes, je souhaite qu'on leur donne plus de significations.

Ce que tu decris, c'est uniquement une des façons de mettre en place les nouveaux status.
Mon topic de dépard était dans un premier temps de voir l'aspect fonctionnelle, et la conclusion de l'élargissement des status me semblent la notion à envisager.

Maintenant, d'un point de vue technique, je suis plutot d'accord avec toi. Il est nécessaire peut-être de faire une refonte concernant les droits/autorisations.
Ca rejoint un peu le topic des liens dynamiques.

En fait, voila ce que je penses pour les status, les liens dynammiques, ect....
Problème actuellement, seules les catégories ont des droits/autorisations, ce qui n'est pas suffisant pour faire d'autres "trucs" avec droits comme les nouveaus status, lien dynamiques.
Actuellement, le seul vraiment dynamique paramétrage c'est les catégories et les users mais en limités.
Ma proposition:
  o élargir la notion de group pour permettrent la gestion d'autres choses que catégories ou des users  (liens, ect...)
  o étendre la gestion des status par une configuration par groupes
  o étendre tout ce qui est possible par groupes...
  o tout cela pour qu'au final, pour un user, on est un ensemble controlant un ensemble d'élements différents.

Est-ce que cette proposition m'hérite reflexion encore un fois, car deja lancée sur plusieurs topics qui se rejoignent, je me demandes donc si je dois faire l'étude appronfie des besoins et des spécifations techniques pour cette gestion technique.
(Tout en sachant, que le but n'est pas de faire une usine à gaz mais un site bien modulable/paramétrable tres facilement) d'ou une serieuse études.

Pour résumer:
  o pas de notion de type mais notion de status
  o validation d'une évolution concernant les status (du moins les besoins, les bases techniques sont à définir)
  o faut-il continuer/faire l'étude/reflexion sur une gestion dynamiques/paramétrable avec autorisations?

VDigital a écrit:

Je pense qu'il est temps de faire le design (en tenant compte de tous les besoins):
- tables, liens avec les tables existantes, valeurs de certains champs.
Je pense qu'on pourrait coincer (mais tant que ce design n'est pas établi, on a du mal à raisonner.
Enfin, la réalisation doit se faire par étape, c'est à toi de voir ce qu'il faut mettre à disposition en premier.

C'est noté, des que j'ai le temps donc début janvier, je vais vous présenter ma proposition pour le deisgn et l'architecture technique...
Je penses aussi que cela doit se faire par étapes car ca va impliquer de nombreux changements un peu partout...

samyyy a écrit:

Proposition de solution de bidouille en attendant la Vrai solution technique et propre...

Effectivement, ca peut être un bon moyen pour bloquer temporairement...

samyyy a écrit:

perso mes multi-users sur un seul accès n'ont pas encore changé les motsde passe en place... mais ça peut venir...

Moi, nous plus mais on ne sait jamais...

samyyy a écrit:

Comme je l'ai dit J'ai lu rapidement le topic alors j'espère ne pas avoir été à coté de la plaque...

T'as tout bon!