Que pour la sélection des albums dans lesquels l'utilisateur peux ajouter des photos devrais être à choix multiple

ddtddt a écrit:

Que pour la sélection des albums dans lesquels l'utilisateur peux ajouter des photos devrais être à choix multiple

Ca complexifie nettement l'ergonomie malheureusement (sauf à avoir le categorySelector de grum, mais il n'est pas dispo dans le core et pas question de mettre GrumPluginClasses en dépendance de Community).

Bon, l'état actuel de ma réflexion, c'est que je vais ajouter une option "[] appliquer aux sous-albums", cochée par défaut.

Mais pas de solution satisfaisante pour ce qui concerne les albums vides pour l'utilisateur, mais pas vide dans l'absolu.

Qui a une opinion sur l'algo que j'ai écrit : la question est de savoir quel niveau de confidentialité donner à une photo en cas de non modération. Si aucune photo dans l'album, alors on prend le niveau de confidentiliaté de l'utilisateur. S'il y a déjà des photos dans l'album, alors on prend le niveau minimum parmi les photos déjà présentes.

rvelices a écrit:

Ou l'utilisateur choisit soit même un niveau plus petit ou egal au sien ?

ça veut dire qu'on -//:---\spam la notion de niveau de confidentialité côté galerie alors que :

1) les utilisateurs ne savent pas ce que c'est
2) les utilisateurs vont découvrir qu'ils sont "contact" alors qu'ils s'attendaient à être "amis"
3) les utilisateurs ne connaissent pas le niveau des autres utilisateurs

:-/

ddtddt a écrit:

Dans ce cas les utilisateurs ne peuvent ajouter que pour tous et au webmaster de modérer l'ajout s'il veux ajouter un niveau de confidentialité ?

oula, ça voudrait dire que tonton Michel, s'il ajoute des photos privées du dernier anniversaire et qu'il n'est pas modéré, tout le monde peut voir ses photos jusqu'à ce que l'administrateur rentre de ses vacances au ski. Pas cool. Mais je me prends peut-être un peu la tête.

Le plus simple serait peut-être de dire "une photo ajoutée par un utilisateur a un niveau de confidentialité 0 en cas de non modération". Si cela ne convient pas à l'administrateur, alors il active la modération.

Pas du tout facile comme probleme... Pour repondre à tous les cas il faudrait refaire le système de permissions actuels (user_permissions + group_permissions)

D'après moi le fonctionnement idéal serait:
- operations sur albums - read, create/modify/delete sub-albums, create/modify/delete photos, modifier les permissions (on peut affiner avec upload/associate photos, ajouter des ommentaires etc...)
- les operations create/modify/delete requierent read
- une permission = un triplet (user|group, operation, album_id)
- IMPORTANT: les albums fils heritent automatiquement toutes les permissions des parents sauf le read
- le webmaster a toujours la permission de modifier les permissions sur la totalité des albums

Maintenant les vraies questions à reflechir ds. un 2eme temps
- comment on implemente l'ergonomie
- comment on "precalcule" les permissions effectives par utilisateur d'une manière efficace
- ce n'est pas trop compliqué ?



On pourrait imaginer par la suite plusieurs ameliorations/declinaisons:
- le webmaster "delegue" tous le droits pour album A au user U (notion de proprietaire d'un album?); alors U sera capable lui même de donner des droits à d'autres utilisateurs pour l'album A ou des sub-albums de A...
- le "modify/delete" photos s'appliquent automatiquement à l'auteur de la photo
- etc...

Dans l'immédiat sur Community, je vais opter pour la série de changements suivants :

1) une photo ajoutée par un utilisateur et non modérée aura comme niveau de confidentialité 0 (= visible par tout le monde)

2) pour une permission d'ajout, nouvelle option "[] appliquer aux sous-albums", cochée par défaut

3) côté formulaire d'ajout utilisateur, la liste des albums de destination ne -//:---\spam que les albums accessibles à l'utilisateur (publics ou privés avec accès explicite pour l'utilisateur) + les albums qui ne contiennent aucune photo dans l'absolu (si l'album contient une photo inaccessible à l'utilisateur, alors l'album n'apparaît pas dans la liste).

Note : ça peut paraître bizarre les albums "vides", mais c'est une demande que j'ai lu plusieurs fois. L'administrateur créé un album vide et dit à ses visiteurs d'y déposer des photos.

La sortie d'un plugin Community fonctionnel et suffisamment stable conditionne la sortie de Piwigo 2.2.0, car l'ajout utilisateur a été supprimé en standard. Il faut donc proposer un plugin Community assez vite après la sortie de Piwigo 2.2.0 (s'il y a une semaine d'écart, ce n'est pas grave, sauf en terme d'annonce)