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...

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.

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 ;-)

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.

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).

Hello,

Y'a-t-il une doc (de moins de septs pages) concernant l'utilisations des statuts ?
Je n'en comprend pas l'utilité.-'autre que celle pour l'admin d'avoir accès au panneau d'administration)

Je vois bien l'intérêt des groupes par contre :-)

vimages a écrit:

pour la présence du signe # c'est normal, audébut, il n'état pas pris en compte, puis zOrglub avait corrigé le tir, il est présent (ex : #12 , #01...) dans les mots clés et donc les tags.   mais je dois faire un trés gros boulot de mise à jour des mots clés...
==> j'ai reçu le mail, je ne vois pas d'erreur.......??

Excellent... Hier soir, j'aurai dû me coucher plus tôt... 8-)
(J'ai pris tes tags pour les éléments du panier...  mdr.)

mais non...  c'est cool comme ça,

c'est complexe tous ces types de users, c'était trop peu évident de les organiser de façon virtuelle, abstraite...  maintenant, c'est en place, on peut les apprivoiser, voir comment ils réagissent...  apprendre à s'en servir, puis trouver des améliorations ou des évolutions, en se basant sur des choses concrètes..

on va refaire un point..  puis noter les souhaits ou les idées qui parraitront bonnes ..? 

cheese    :o)))