Piwigo.org

vimages · 2006-02-28 18:37:58

sorry, mais pas d'accord......

rub a écrit:
Voila, je vous laisse le choix:
o Activation pwg_high pour chaque user (ajout d'un champ #pwg_high_enabled dans #user)
o Activation pwg_high pour chaque catégorie (ajout d'un champ #pwg_high_enabled dans #categories)
o Activation pwg_high par "groupe/user" comme les permissions, ajout d'un champ #pwg_high_enabled dans les tables #group_access et user_access)
Je pense que seule la 3e solution a un sens, si on reste dans la philosophie (VDigital je crois) "pas de perm poru les user, que pour les groupes"; ce que je conçois tout à fait.

cf mes propos ci-dessus....... concernant l'usage de cette evolution.... :o)

Dernière modification par vimages (2006-02-28 18:38:19)

VDigital · 2006-02-28 19:22:51

On va tenter de le formuler autrement...
Il faut ajouter une colonne pwg_high_enable (True/False) dans une table.

Tables envisagées:
#_user : Je dis non, cela ne correspond pas au besoin réel (un user peut avoir accès a une pwg_high et pas a une autre).
#_category: Je dis non encore, car il suffit de ne pas mettre de pwg_high dans cette catégorie (en raisonnant simplement catégorie réelle)
#_group_access: Bien sûr, enable par défaut ce qui se rapproche de la situation actuelle.
#_user_access: vous savez tous pourquoi je suis contre.

Il faut cependant une variable globale qui permet d'assurer la continuité avec aujourd'hui.
$conf['check_pwg_high_enable']=false;
On ne contrôle pas la colonne (assumée comme True) et dès lors que l'image haute définition existe, on y accède comme aujourd'hui.
$conf['check_pwg_high_enable']=true;
On contrôle et dès lors que l'image haute définition est autorisée le membre y a accès (c'est surtout qu'il voit qu'il peut cliquer sur l'image).

Ceci dit cela reste fictif bien sûr car le visiteur qui connait la structure des galeries de PWG peut tenter de donner l'URL dans le répertoire high_pwg...

Un peu plus clair? Pas certain.

rub · 2006-02-28 19:39:09

Alors ca, c'est cool, je m'appretais à repondre et hop VDigital répond avec mes réponses ou presque.

Ok, pour la sécurité! Pour les options par défaut bien evidemment!

Par contre,

VDigital a écrit:
#_user_access: vous savez tous pourquoi je suis contre.

Non, pourquoi?

Bref, tres bien résumé...

Bon alors, je pars donc sur la solution la plus compliquée à developper (merci les gars! lol) mais, qui c'est vrai, colle le plus au modéle actuel et permet de gérer la plupart des cas.

Par exemple pour vimages, il suffit pour activer pwg_high d'avoir un group spécial pwg_high et de l'affecter aux users voulus.
En pratique, tu peux dupliquer tes groupes par exemple (gr 1 et gr2 avec même catégorie mais pwg_high différent), tout dépend comme tu fais.

Donc, je vais partir sur :
o Ajout d'un champs dans #_group_access
o Ajout d'un champs dans #_user_access
o Gestion des icones, click, ect...
o Option de valeurs par défault

Pourquoi, #_user_access pour rester cohérent avec #_group_access.

mathiasm a écrit:
attention, cependant: un utilisateur avec un compte generique doit donc connaitre l'@mail du webmaster pour le contacter en cas de perte.

Ca, ca dépend de la config du site!!!

vimages · 2006-02-28 21:39:10

merci beaucoup !!
c'est sympa de bien vouloir intégrer cette fonction. si elle m'interesse personnellement, je suis sur que nombreux sont ceux qui l'utiliseront..

les deux derniers post me paraissent très au point et résulter d'une bonne analyse au côté de laquelle je me range avec plaisir.!

Je précise que sur mon site, l'accés au dossiers "pwg_high" est autorisé et le sera toujours par défaut.
Dans quelques cas seulement j'interdirais de voir ces dossiers.

exemples concrets :
- dans la pratique, tous mes visiteurs étant des clients, ils ont bien évidement le droits de télécharger leurs fichiers "pwg_high".. tels les magazines spécialisés qui ont accès aux reportages sport auto ...
- c'est dans le cas d'un nouveau client, à qui je voudrais montrer des reportages, que je lui interdirait la vue des "pwg_high" , jusqu'au moment ou ..nous serons d'accord pour travailler ensemble.

merci encore!

eric.

rub · 2006-02-28 22:12:12

vimages a écrit:
...
c'est sympa de bien vouloir intégrer cette fonction...

Cool alors si ca te convient!

rub a écrit:
Donc, je vais partir sur :
o Ajout d'un champs dans #_group_access
o Ajout d'un champs dans #_user_access
o Gestion des icones, click, ect...
o Option de valeurs par défault

Pourquoi, #_user_access pour rester cohérent avec #_group_access.

En revenant chez moi, ce soir, dans le métro, je me suis demandé où j'allais casés l'interface de mise à jour des tables #_group_access et #_user_access et je me suis demandé si ca valait le coup de mettre le enabled_pwg_high dans les access! Car faut-il vraiment paramètrer chacune des catégories associées à un groupe? Ne peut-on mettre le champs enabled dans la table #group (et #_user par conséquent)?

Alors?

VDigital · 2006-02-28 22:33:24

rub a écrit:
Ne peut-on mettre le champs enabled dans la table #group (et #_user par conséquent)?

Je n'expliquerai pas pourquoi (inutile) mais banco !!!

mathiasm · 2006-02-28 22:48:58

rub a écrit:
En revenant chez moi, ce soir, dans le métro, je me suis demandé où j'allais casés l'interface de mise à jour des tables #_group_access et #_user_access et je me suis demandé si ca valait le coup de mettre le enabled_pwg_high dans les access! Car faut-il vraiment paramètrer chacune des catégories associées à un groupe? Ne peut-on mettre le champs enabled dans la table #group (et #_user par conséquent)?

Alors?

AMA, ça dépend en partie du plus couteux: si tu le mets dans la table #group, tu vas devoir créer plus de groupes si tu veux une finesse par catégorie. Si tu le mets dans #group_access, tu vas renseigner par défaut plus de champs, mais la finesse est conservée.
D'autre part, je ne connais pas les besoins réels concernant cette fonction, mais les besoins de vimages se satisfont bien d'un remplissage dans #group.

@vimages: mon post était bref et un peu abrupt, mais nous étions a priori d'accord (sauf que rub veut du #user...)

rub · 2006-02-28 23:40:31

mathiasm a écrit:
AMA, ça dépend en partie du plus couteux: si tu le mets dans la table #group, tu vas devoir créer plus de groupes si tu veux une finesse par catégorie. Si tu le mets dans #group_access, tu vas renseigner par défaut plus de champs, mais la finesse est conservée.

Oui, on perd en finesse mais est-ce vraiment nécessaire d'avoir une telle finesse!
Dans tous les cas, ça cadre avec le besoin de vimages et ca me "facilite" les dev. Car qui dit finesse dit interface ergonomique à fond... et sur ce point pas le temps, ni même la bonne idée...
Mais c'est à mettre de coter pour une prochaine fois...

#_group et #_user pour moi, car même si certains sont contre (ha bon), on a garde l'équivalence actuelle du group et user...

Mais je vais arrêter de me répéter, je signe donc pour:
o Ajout d'un champ pwg_high_enabled dans #_groups
o Ajout d'un champ pwg_high_enabled dans #_user_infos
o Gestion des icones, click, ect...
o Option de valeurs par défault

mathiasm · 2006-03-01 00:49:37

rub a écrit:
Oui, on perd en finesse mais est-ce vraiment nécessaire d'avoir une telle finesse!
Dans tous les cas, ça cadre avec le besoin de vimages et ca me "facilite" les dev. Car qui dit finesse dit interface ergonomique à fond... et sur ce point pas le temps, ni même la bonne idée...
Mais c'est à mettre de coter pour une prochaine fois...

Je suis plutot d'accord. si vimages avec son site pro n'a pas le besoin, on a peu de chances de le retrouver ailleurs (et puis s'ils le veullent,ils font le dev, c'est du logiciel libre ;-))

rub a écrit:
Mais je vais arrêter de me répéter, je signe donc pour:
o Ajout d'un champ pwg_high_enabled dans #_groups
o Ajout d'un champ pwg_high_enabled dans #_user_infos
o Gestion des icones, click, ect...
o Option de valeurs par défault

Bon courage

rub · 2006-03-01 11:47:46

Ce matin sous ma douche, je me suis dit "les catégories publics et le pwg_high... comment ca marche?"...

Donc, je propose que pour les catégories publiques le pwg_high est disponible uniquement si le flag #pwg_high_enabled dans #_user_infos est à true.
Pour les catégories privées, deux choix:
o Choix 1: si le flag #pwg_high_enabled dans #_user_infos est à true (même si le user n'a pas accés à la catégorie par son user [donc il a accés par son groupe]) ET que flag #pwg_high_enabled dans #_group est à true alors pwg_high est disponible.
o Choix 2: si le flag #pwg_high_enabled dans #_user_infos est ) true (et si le user a accés à la catégorie grace à son user [peut aussi avoir l'accés par son groupe]) OU que flag #pwg_high_enableddans #_group est à true alors pwg_high est disponible.

C'est à dire que en fait:
=> dans les deux cas:
o le flag #pwg_high_enabled dans #_group sert pour les catégries privées associées au user
o le flag #pwg_high_enabled dans #_user_infos sert pour les catégries privées associées au user
o le flag #pwg_high_enabled dans #_user_infos sert pour les catégries publics
=> et à choisir:
o le flag dans #_user_infos sert aussi globalement pour toutes les catégories (Choix 1)
o le flag dans #_user_infos ne sert pas globalement pour toutes les catégories (Choix 2)

Je vote pour le choix 1. Et vous?

VDigital · 2006-03-01 12:27:18

En résumé, dois-je faire :
- User autorisé ET un groupe l'autorisant suffit
ou
- User autorisé OU un groupe l'autorisant suffit

C'est: ET.
Si tous les groupes auxquels il appartient, ne l'autorisent pas, il ne doit pas y avoir accès.

(
C'est pourquoi je ne gèrerai pas ça au niveau user mais uniquement au niveau des groupes.
Cela réduit légèrement la complexité et l'info ira un jour dans un cache pour des raisons de perf.
La gestion de catégories publiques se ferait plus simplement via une variable de conf, c'est à dire est ce que guest peut savoir qu'une High existe...
)

VDigital · 2006-03-01 12:47:02

Je rappelle deux points:

Pour qu'un user ou n users puissent voir des catégories mais pas les Highs, il suffit de leur faire un nouveau groupe leur donnant les mêmes accès que les groupes existants mais avec pwg_high_enable=false, sans oublier de retirer ces users des groupes existants.

Qu'il faut mettre des index.php dans tous les répertoires pwg_high assurant une redirection pour prévenir de toute exploration non autorisée.

Il faut le dire et le faire.

Créer des groupes ne surcharge pas vraiment l'application, on devrait toujours avoir moins de groupes que de users.

8-)

rub · 2006-03-01 13:38:23

VDigital a écrit:
...
C'est: ET.

On est bien d'accord sur le choix 1 alors!

VDigital a écrit:
(
C'est pourquoi je ne gèrerai pas ça au niveau user mais uniquement au niveau des groupes.
Cela réduit légèrement la complexité et l'info ira un jour dans un cache pour des raisons de perf.
La gestion de catégories publiques se ferait plus simplement via une variable de conf, c'est à dire est ce que guest peut savoir qu'une High existe...
)

Pour la petite parenthése, si on met une variable globale pour le catégories publics, on perd en souplesse à mon avis, car si on a des catégories publiques et qu'on veut pas le pwg_high tout le temps, on va créer plein de groupe et même si c'est supporter dans pwg, ca peut, à la longue être, compliqué à gérer par l'utilisateur car il devra administrer plein de groupes... Mais ce n'était qu'une parenthèse!

Donc, ok je pars sur le choix 1, alors...

VDigital a écrit:
Je rappelle deux points:...
Qu'il faut mettre des index.php dans tous les répertoires pwg_high assurant une redirection pour prévenir de toute exploration non autorisée.

C'est dommage d'ailleurs que c'est pas fait automatiquement ;-) (Rien n'est prévu d'ailleurs? Dans la synchro, ca peut être sympa!)
Mais, bon, ca n'empeche pas d'y acceder directement avec en deduisant l'adresse complete de la miniature, par exemple!

VDigital · 2006-03-01 14:01:39

rub a écrit:
Pour la petite parenthése, si on met une variable globale pour le catégories publics, on perd en souplesse à mon avis, car si on a des catégories publiques et qu'on veut pas le pwg_high tout le temps, on va créer plein de groupe et même si c'est supporter dans pwg, ca peut, à la longue être, compliqué à gérer par l'utilisateur car il devra administrer plein de groupes... Mais ce n'était qu'une parenthèse!

Donc, ok je pars sur le choix 1, alors...

Tu as parfaitement raison...
C'est pourquoi je considère que guest devrait être un user à part entière excepté la personalisation.
(Je me sens un peu seul à défendre ce point de vue).
Mais dans ce cas, le pb est quasiment réglé.
Le sujet n'est pas clos.
Tu peux néanmoins sans problème déjà gérer les droits des groupes.

rub · 2006-03-01 18:22:46

VDigital a écrit:
C'est pourquoi je considère que guest devrait être un user à part entière excepté la personalisation.

Je suis plutot d'accord avec toi mais ca ne change pas le fait de gérer le flag au niveau du #_user...

Piwigo.org

Annonce

#46 2006-02-28 18:37:58

Re: [Evolution] Nouveau type de user...

#47 2006-02-28 19:22:51

Re: [Evolution] Nouveau type de user...

#48 2006-02-28 19:39:09

Re: [Evolution] Nouveau type de user...

VDigital a écrit:

mathiasm a écrit:

#49 2006-02-28 21:39:10

Re: [Evolution] Nouveau type de user...

#50 2006-02-28 22:12:12

Re: [Evolution] Nouveau type de user...

vimages a écrit:

rub a écrit:

#51 2006-02-28 22:33:24

Re: [Evolution] Nouveau type de user...

rub a écrit:

#52 2006-02-28 22:48:58

Re: [Evolution] Nouveau type de user...

rub a écrit:

#53 2006-02-28 23:40:31

Re: [Evolution] Nouveau type de user...

mathiasm a écrit:

#54 2006-03-01 00:49:37

Re: [Evolution] Nouveau type de user...

rub a écrit:

rub a écrit:

#55 2006-03-01 11:47:46

Re: [Evolution] Nouveau type de user...

#56 2006-03-01 12:27:18

Re: [Evolution] Nouveau type de user...

#57 2006-03-01 12:47:02

Re: [Evolution] Nouveau type de user...

#58 2006-03-01 13:38:23

Re: [Evolution] Nouveau type de user...

VDigital a écrit:

VDigital a écrit:

VDigital a écrit:

#59 2006-03-01 14:01:39

Re: [Evolution] Nouveau type de user...

rub a écrit:

#60 2006-03-01 18:22:46

Re: [Evolution] Nouveau type de user...

VDigital a écrit:

Pied de page des forums