mathiasm a écrit:

- Les propriétés guest et valeurs par défaut de vraient pour moi apparaitre dans la colonne propriétés et non user.

Perso, je préfères l'avoir dans la colonne user mais ca ne me derangerait pas plus de voir l'info dans propriétés.
Visuellement, c'est mieux dans la 1ere colonne mais le therme proprièté est très bien trouvé.
Si on le met dans la colonne proprièté, il faudrait un artifice visuel.

mathiasm a écrit:

- A l'heure actuelle, le statut guest et générique sont identiques. Seule la propriété [guest] fait qu'il n'y a pas besoin de s'authentifier. Ou non ?

Le générique a accès aux paniers mais c'est un bug...
En fait de base, pas de diff, mais en BSF(1.8), il y a des fonctions (is_guest, is_generic) permettant aux plugins et autres de faire des actions spécifiques.
Par exemple, un invité n'aura les mêmes pages ajoutés par pwg stuff qu'un user généric.

Pour moi, un invité, c'est impersonnel et non durable.
Un générique, c'est un sésame donné à tes gens connus et fait pour durer (ou du moins quantifier dans le temps).

mathiasm a écrit:

rub a écrit:

mathiasm a écrit:

- Les propriétés guest et valeurs par défaut de vraient pour moi apparaitre dans la colonne propriétés et non user.

Perso, je préfères l'avoir dans la colonne user mais ca ne me derangerait pas plus de voir l'info dans propriétés.
Visuellement, c'est mieux dans la 1ere colonne mais le therme proprièté est très bien trouvé.
Si on le met dans la colonne proprièté, il faudrait un artifice visuel.

Non, juste à bouger les lignes 826-829 après la 837 dans admin/user_list.php

J'ai pas bien compris pourquoi tu as mis cette réponse!?

mathiasm a écrit:

rub a écrit:

mathiasm a écrit:

- A l'heure actuelle, le statut guest et générique sont identiques. Seule la propriété [guest] fait qu'il n'y a pas besoin de s'authentifier. Ou non ?

Le générique a accès aux paniers mais c'est un bug...
En fait de base, pas de diff, mais en BSF(1.8), il y a des fonctions (is_guest, is_generic) permettant aux plugins et autres de faire des actions spécifiques.
Par exemple, un invité n'aura les mêmes pages ajoutés par pwg stuff qu'un user généric.

Pour moi, un invité, c'est impersonnel et non durable.
Un générique, c'est un sésame donné à tes gens connus et fait pour durer (ou du moins quantifier dans le temps).

Si je te suis, et qu'on utilise is_guest tout le temps, guest pourrait très bien être défini comme status=generic et properties contient guest ? Ce qui permet de se passer du statut guest, qui n'a pas de sens, puisqu'on se base sur la propriété.
J'appuie aussi cet argumentaire en disant qu'affecter le statut guest à un utilisateur lui permet de se loguer, avec un mot de passe, en plus! Ce qui est contraire aux specs fournies.
Après réflexion, quel que soit le profil utilisé, l'utilisateur ayant la propriété guest doit voir tous ses droits suspendus, non? J'avais mis generic car c'est le plus proche du statut réel (pas de "personnaliser", pas de mot de passe).

Attention pour moi, les spécifications dont tu parles ne soit plus valables depuis qu'on a passé le user guest comme un vrai user.

Par contre, il faut faire évoluer les 2 statuts pour bien les différencier.

Comme par exemple, pas de connexion directe possible pour un guest (ou pourrait aussi par un proprièté qui bloque la connexion d'un utilisateur).


A force de réfléchir, on commence à s'embrouiller et je te rejoins Mathias.
Le pb c'est qu'on une propriété guest et un statut guest.

Pourquoi ne pas:
  o supprimer le statut generic
  o garder que le statut guest/invité
  o changer le therme propriété guest par anonymous user (refonte complète dans le nom des variables, etc)
  o ajouter une propriété "user bloqué" à la connexion

Le statut guest n'afflueant que les restrictions d'accés et la proprité anonymous sur la connexion à l'application.

rub a écrit:

mathiasm a écrit:

rub a écrit:

Perso, je préfères l'avoir dans la colonne user mais ca ne me derangerait pas plus de voir l'info dans propriétés.
Visuellement, c'est mieux dans la 1ere colonne mais le therme proprièté est très bien trouvé.
Si on le met dans la colonne proprièté, il faudrait un artifice visuel.

Non, juste à bouger les lignes 826-829 après la 837 dans admin/user_list.php

J'ai pas bien compris pourquoi tu as mis cette réponse!?

C'est la manip à faire pour déplacer dans propriétés.

rub a écrit:

mathiasm a écrit:

rub a écrit:

Le générique a accès aux paniers mais c'est un bug...
En fait de base, pas de diff, mais en BSF(1.8), il y a des fonctions (is_guest, is_generic) permettant aux plugins et autres de faire des actions spécifiques.
Par exemple, un invité n'aura les mêmes pages ajoutés par pwg stuff qu'un user généric.

Pour moi, un invité, c'est impersonnel et non durable.
Un générique, c'est un sésame donné à tes gens connus et fait pour durer (ou du moins quantifier dans le temps).

Si je te suis, et qu'on utilise is_guest tout le temps, guest pourrait très bien être défini comme status=generic et properties contient guest ? Ce qui permet de se passer du statut guest, qui n'a pas de sens, puisqu'on se base sur la propriété.
J'appuie aussi cet argumentaire en disant qu'affecter le statut guest à un utilisateur lui permet de se loguer, avec un mot de passe, en plus! Ce qui est contraire aux specs fournies.
Après réflexion, quel que soit le profil utilisé, l'utilisateur ayant la propriété guest doit voir tous ses droits suspendus, non? J'avais mis generic car c'est le plus proche du statut réel (pas de "personnaliser", pas de mot de passe).

Attention pour moi, les spécifications dont tu parles ne soit plus valables depuis qu'on a passé le user guest comme un vrai user.

Par contre, il faut faire évoluer les 2 statuts pour bien les différencier.

Comme par exemple, pas de connexion directe possible pour un guest (ou pourrait aussi par un proprièté qui bloque la connexion d'un utilisateur).


A force de réfléchir, on commence à s'embrouiller et je te rejoins Mathias.
Le pb c'est qu'on une propriété guest et un statut guest.

Pourquoi ne pas:
  o supprimer le statut generic
  o garder que le statut guest/invité
  o changer le therme propriété guest par anonymous user (refonte complète dans le nom des variables, etc)
  o ajouter une propriété "user bloqué" à la connexion

Le statut guest n'afflueant que les restrictions d'accés et la proprité anonymous sur la connexion à l'application.

Je ne comprends pas le dernier point "user bloqué". Cela revient à la propriété anonymous. De mon point de vue, il ne peut y avoir qu'un seul utilisateur avec la propriété anonymous, et c'est celui défini dans le $conf['guest_id']

Le plus simple AMA, est de garder guest pour l'accès anonyme (tel que c'est depuis la 1.3) et supprimer le statut guest introduit en 1.7, qui ne correspond à rien. On garde alors le generic, qui a du sens.

VDigital a écrit:

C'est effectivement un peu le bazar, mais je suis convaincu saura nous remettre dans le droit chemin.
8-)

Il manque quelques mots, là, non ? :-)) On dirait du rub ;-)

rub a écrit:

mathiasm a écrit:

Je ne comprends pas le dernier point "user bloqué". Cela revient à la propriété anonymous. De mon point de vue, il ne peut y avoir qu'un seul utilisateur avec la propriété anonymous, et c'est celui défini dans le $conf['guest_id']

Par exemple, le user toto me pose des problèmes (il paie pas pour une galerie commerciale), je lui bloque l'accès proprement à la galerie.

Dans ce cas, il me parait plus correct de le mettre dans un groupe qui lui interdit l'accès aux images. En plus, ça permet d'afficher un message stipulant que l'accès a été restreint volontairement et que ce n'est pas un problème technique.

Franchement, je comprends ce que tu exprimes, mais je n'en vois pas l'intérêt dans la réalité. Cela complique la mise en oeuvre. On y repensera quand on aura des galeries commerciales.

mathiasm a écrit:

Franchement, je comprends ce que tu exprimes, mais je n'en vois pas l'intérêt dans la réalité. Cela complique la mise en oeuvre. On y repensera quand on aura des galeries commerciales.

C'était juste une idée comme ca... c'est toujours utile de bloquer d'un seul click...