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!

Pas tout à fait d'accord.
Je fais un rappel sur ma vision des groupes (qui est celle utilisé dans les permissions des systèmes de fichiers):
il ne vaut pas les voir comme un ensemble de users, mais comme une clé d'accès. Le groupe (clé) est donc associé à des catégories (portes). Ensuite tu mets les users dans les groupes (i.e. tu leur donnes les clés que tu veux qu'ils aient).
Partir à l'envers devient effectivement vite générateur de bazar: Mettre les gens dans des groupes (amis, famille, ...) et ensuite leur affecter des droits => Cata assurée. Ces groupes peuvent servir a regrouper des gens pour les retrouver plus facilement, mais surtout pas à gérer les permissions.
Pour reprendre l'analogie avec Linux, les groupes décrivent des fonctions (apache, root,...), pas des regroupements logiques (compta,prod,direction)
C'est un peu hors sujet, mais ça permet de justifier le fait de n'avoir que les groupes et pas les users pour gérer les permissions.

Donc, pour revenir à ce qu'a dit rub:
Tu as "au pire" 2 groupes par categories (high, no_high). En théorie, si tu en es à gérer ce genre de choses, c'est que tu as un nombre d'usagers assez important; il est donc plus simple de gérer par groupe, surtout avec la fonction filtre de la page d'admin des groupes.
Si tu as mis les categories publiques en high, pour le guest, il suffit de créer un groupe, "permissionné" sur toutes les cat publiques avec high=false.le mettre dans les groupes no_high.=> ça implique donc que ce soit un user comme-les-autres-sauf-la-perso
(+1, VDigital, t'es pas tout seul pour le guest réel ;-).

rub a écrit:

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

Et pourquoi devraient-ils être équivalents? Au départ les droits étaient succincts, il est donc normal que les deux granularités soient identiques. Mais je ne vois pas de raison pour que ça soit/devienne une règle (au contraire).

vimages a écrit:

Si vous voulez des photos de vos voitures préférées il suffit de me demander  ! se sera avec plaisir !

j'veux bien une 'tite porsche colorée, si t'en croises.

mathiasm a écrit:

...
il ne vaut pas les voir comme un ensemble de users, mais comme une clé d'accès. Le groupe (clé) est donc associé à des catégories (portes). Ensuite tu mets les users dans les groupes (i.e. tu leur donnes les clés que tu veux qu'ils aient).

Ok avec toi...

mathiasm a écrit:

...
...Mettre les gens dans des groupes (amis, famille, ...) ... Ces groupes peuvent servir a regrouper des gens pour les retrouver plus facilement, mais surtout pas à gérer les permissions.

Ok avec toi mais créer des groupes (amis, famille, ect...) peut avoir du sens... mais effectivement pour gérer uniquement les permissions, ca peut être la cata... en fait, je pense aussi que la gestion d'un site famille ou la famille, la belle-famille, les amis, les collegues ont un accés très précis aux photos peut-être un vrai casse-tête... bref on s'éloigne...

mathiasm a écrit:

...
Pour reprendre l'analogie avec Linux, les groupes décrivent des fonctions (apache, root,...), pas des regroupements logiques (compta,prod,direction)

Toujours ok...

mathiasm a écrit:

...
C'est un peu hors sujet, mais ça permet de justifier le fait de n'avoir que les groupes et pas les users pour gérer les permissions.

Effectivement, c'est hors-sujet et je comprends tres bien ton point de vue... mais, le problème, c'est ca c'est un autre soucis que l'on décrit... Je suis d'accord avec vous 2 sur le guest et le user et je pense même qu'il faudrait approndir la gestion des permissions (cf ce topic, il me semble)... mais pour la version que j'aurais pas le temps de m'attaquer à ce chantier... (à vous alors!?)... C'est pourquoi, je reste dans la logique actuelle...

mathiasm a écrit:

...
Si tu as mis les categories publiques en high, pour le guest, il suffit de créer un groupe, "permissionné" sur toutes les cat publiques avec high=false...

Petit hic, comment associer une catégorie publique à un groupe? Impossible pour le moment...

mathiasm a écrit:

...
Et pourquoi devraient-ils être équivalents? Au départ les droits étaient succincts, il est donc normal que les deux granularités soient identiques. Mais je ne vois pas de raison pour que ça soit/devienne une règle (au contraire).

Cf au dessus, je reste dans la pratique actuelle
Mais ca serait bien pour la version 1.7.0 de revoir les permissions, le guest, le publique et le user/groupe...

vimages a écrit:

Si vous voulez des photos de vos voitures préférées il suffit de me demander  ! se sera avec plaisir !

Ca, c'est bien sympa ;-)

rub a écrit:

mathiasm a écrit:

...
Si tu as mis les categories publiques en high, pour le guest, il suffit de créer un groupe, "permissionné" sur toutes les cat publiques avec high=false...

Petit hic, comment associer une catégorie publique à un groupe? Impossible pour le moment...

Tu fais l'inverse: tu mets toutes tes cat. en privée, tu mets un group global all_read_high, et tu ne l'affectes pas à guest. Mais on s'égare et je m'enferre. On verra en 1.7

rub a écrit:

mathiasm a écrit:

...
Et pourquoi devraient-ils être équivalents? Au départ les droits étaient succincts, il est donc normal que les deux granularités soient identiques. Mais je ne vois pas de raison pour que ça soit/devienne une règle (au contraire).

Cf au dessus, je reste dans la pratique actuelle.

Oui, mais la pratique que tu décris est-elle dans la logique de l'application, ou est-ce un hasard si perm(user)=perm(group)???

rub a écrit:

Mais ca serait bien pour la version 1.7.0 de revoir les permissions, le guest, le publique et le user/groupe...

+1

Tout d'abord, concernant les dev effectués, j'ai fait ce que j'avais prévu sauf le fait d'interdire à certains users de ne pas pouvoir affecter un status ("Status NON affectable par l'interface") et le fait que le webmaster soit unique (la, j'ai changé d'envie).

Concernant le adviser, je trouve que c'est une bonne idée!
Un peu tard... mais non... ;-)

Ce que je peux faire rapidement:
  o Ajout du status adviser
  o Status affectable uniquement par le webmaster
  o Ajout d'une function is_adviser

Par contre, pour faire que de la consultation, je ne pourrais pas être exhaustif (ca demande beaupoup de boulot, pas dur mais long).
Je peux commencer à faire certains trucs mais pour le reste, je laisse le reste des dev aux autres? Ce qui me permettra de me concentrer sur le pwg_high et surtout sur la fin de la notification par mail.
Même si tout n'est pas fait la 1ere brique sera la!

Après reflexion, je ne pense pas qu'il faille mettre un status "adviser" car par rapport à ce qui a été fait ca ne correspond pas trop à la logique. (adviser peut consulter admin mais ne peut aussi "que" consulter en normal).

On pourrait peut-etre créer une prorité adviser/read_only pour chaque user, comme ca on peut créer des advisers pour chaque status.

Qu'en penses-tu VDigital?

VDigital a écrit:

Attention, de ne pas faire trop compliqué...

Au contraire, ca permettra de mettre "moins" de tests.

Je pars sur ca, alors...

Desole d'intervenir aussi tardivement. A propos de l'acces a pwg_high, vous vous prenez trop la tete sur un besoin relativement simple de vimages. Pour vimages, un champ pwg_high_enabled dans #user_infos suffit. Ce serait beaucoup plus simple a gerer que via les groupes, qui n'ont ete concu que pour factoriser la gestion des permissions. Je ne suis pas contre une etude d'amelioration de la gestion des permissions, mais par pitie, on attend la branche 1.7 pour cela, et on laisse la notion de groupe tranquille en branche 1.6.

A mon avis, la desactivation de l'acces a pwg_high va interesser tres peu de monde, inutile de faire quelque chose de complique pour un besoin aussi simple. N'oubliez pas que le code doit etre maintenu... Rub, ce post est une recommandation que je te conseille de suivre, mais je te laisse decider.