Itération 3 - Wysiwyg - Visuel

[Nicoloye]

Créer un visuel en WYSIWYG Pouvoir sélectionner une zone dans l’image qui a été mise en ligne.

L'attendu fonctionnel ici est-il de pouvoir réaliser un cropping de l'image directement dans l'éditeur wysiwyg ? Le type de contenu Visuel gère son image dans un champ en dehors du wysiwyg, mais il est possible de lui adjoindre un widget de cropping sans problème.

d’ajouter, de positionner et de redimensionner une image (en passant par un éditeur visuel WYSIWYG permettant de modifier les images de la banque d’images ou des images uploadées

Ce point peut être problématique selon la gestion de droits qu'on veut mettre en place au niveau des fichiers. Si on considère que tous les utilisateurs ont accès à toutes les images uploadées sur le serveur pour insertion n'importe où dans ce cas pas de problème.

de légender une image ou un média vidéo

Cela sera possible via des templates prédéfinis qui pourront être insérés dans le wysiwyg.

d’insérer un média (vidéo) par simple sélection dans la base de données média ou par simple mention de l’URL (pour les vidéos sur Youtube, Vimeo, Dailymotion, etc.)

Attention aux contraintes d'hébergement de fichiers vidéos, c'est volumineux et pas forcément adapté à un player web, l'hébergement sur des plateformes dédiées est recommandé sans maîtrise de ces aspects.

[Issenmann]

à confirmer par Bastien : pour le 1er point, nous avions effectivement en tête du cropping. Pour l'insertion de média, à discuter selon les contraintes soulevées par Nicolas?

[bzg]

L'attendu fonctionnel ici est-il de pouvoir réaliser un cropping de l'image directement dans l'éditeur wysiwyg ?

Oui.

Si on considère que tous les utilisateurs ont accès à toutes les images uploadées sur le serveur pour insertion n'importe où dans ce cas pas de problème.

Les utilisateurs ne peuvent modifier que les visuels:

• dont ils possèdent les droits ou
• si le champ "Droits d'auteur" indique "Domaine public" ou
• si le champ SA-ND-NC contient soit CC-by, soit CC-by-sa, soit CC-by-sa-nc

Attention aux contraintes d'hébergement de fichiers vidéos, c'est volumineux et pas forcément adapté à un player web, l'hébergement sur des plateformes dédiées est recommandé sans maîtrise de ces aspects.

Oui, nous n'avons pas prévu l'hébergement de vidéos, il faut juste que le fait de coller un lien vers une vidéo permette d'insérer la vidéo.

[Nicoloye]

Le système de permission au niveau de la gestion des fichiers n'est pas aussi avancé que cela, d'où mon alerte.

La gestion des copyrights au niveau du système de permissions va être très complexe à implémenter, ça implique de modifier le système de permissions natif de Drupal pour intégrer cette notion. Chantier très lourd en perspective

[bzg]

OK. C'est un besoin identifié dès la première version du cahier des charges: avoir un environnement avec des droits différents et permettre aux utilisateurs de "remixer" des contenus en fonction de leur compatibilité d'utilisation.

Ne pas hésiter à décrire le problème technique - s'il faut modifier la structure des champs des types de contenu pour faciliter les règles de droits sur les nodes, pas de souci.

[Nicoloye]

Le fait d'avoir des droits différenciés a toujours bien été identifié, mais là les descriptif détaillé met en avant un système de permissions qui est très atypique au regard des systèmes de permissions standards qu'on peut trouver sur des CMS. Là le problème technique provient essentiellement du fait que la restriction d'accès est assujettie à des champs contribués sur des contenus.

Le système de permissions de Drupal fonctionne sur des caractéristiques plus macroscopiques comme le type d'un contenu, le rôle d'un utilisateur, etc. Les permissions par défaut par exemple sont du type:

• créer un nouveau contenu de type XXX
• éditer un contenu de type XXX dont je suis l'auteur
• éditer tous les contenus de type XXX
• supprimer un contenu de type XXX dont je suis l'auteur
• supprimer n'importe quel contenu de type XXX

Un chantier est déjà prévu pour étendre ce système pour permettre d'autoriser plusieurs co-auteurs sur un contenu. Il est possible de créer des groupes de permissions pour permettre des permissions plus poussées et assujettir automatiquement les contenus en fonction de nos champs de copyright, simplement ce sera un chantier non neutre en terme de charge de développement car il modifie assez profondément le fonctionnement standard.

Je vais réfléchir à des méthodes techniques de simplification de ce point.

[bzg]

Merci pour les détails, je comprends mieux la contrainte.

Une approche possible: créer un type de contenu "virtuel" qui contiendrait le sous-ensemble des contenus modifiables par tout le monde. Ce type de contenu ne serait pas exclusif d'autres types (d'où "virtuel"), et permettrait de retomber sur le système de permission natif...

Je ne connais pas la plomberie interne, donc c'est just un shoot dans le noir.

[Nicoloye]

OK je vais voir si ça peut m'aider à architecturer les choses sereinement. C'est surtout le côté implémentation dans TinyMCE que j'essaie d'anticiper de ce côté. J'essaie de vous synthétiser quelque chose pour semaine prochaine sur cette problématique.

[bzg]

Parfait, merci !

[Nicoloye]

Juste une rapide note pour synthétiser mes réflexions autour du sujet des permissions.

J'ai relevé les permissions suivantes à ce jour:

• Voir un contenu: tout le monde
• Editer un contenu:
  • Je suis l'un des co-auteurs du contenu.
  • N'importe qui si le contenu est taggué "Domaine public".
  • N'importe qui si le contenu est taggué CC-by, CC-by-sa ou CC-by-sa-nc
• Supprimer un contenu:
  • Je suis l'un des co-auteurs du contenu.
  • N'importe qui si le contenu est taggué "Domaine public".
  • N'importe qui si le contenu est taggué CC-by, CC-by-sa ou CC-by-sa-nc

Je pense qu'il faut ajouter quelques protections pour se prémunir de problèmes:

• La suppression d'un contenu devrait être réservée uniquement aux co-auteurs de celui-ci, même si le copyright est libre sur celui-ci. Sinon on prend le risque d'avoir de la perte de contenu du fait de trolls.
• Le champ co-auteur ne devrait être éditable que par les co-auteurs eux-mêmes, pour éviter l'abus cité précédemment.
• Je me pose la question de limiter aussi l'édition du champ de copyright par les co-auteurs uniquement, qu'en penses-tu @bzg ?

[bzg]

J'ai pas mal retravaillé la formulation des problèmes liés aux droits dans https://github.com/Jardin-des-Sciences/website/commit/d5704f0fbb53264c7ca730313fc78810c3916dbd

L'idée de base est celle-ci: il y a d'une part le problème des permissions (voir, éditer, supprimer), formulable dans les termes de Drupal, et d'autre part le problème de la compatibilité des droits pour les contenus collaboratifs.

Les contenus primaires élémentaires (un visuel, un billet, etc.) ne sont pas collaboratifs, ou alors très peu: un utilisateur me propose de modifier la légende d'une image que j'ai postée, un autre me signale une faute d'orthographe dans mon billet, etc. Ces micro-contributions n'affectent pas les droits du contenu.

Les contenus primaires de type "collection" comme les dossiers et parcours sont eux très collaboratifs, et ce qu'on ajoute dans un dossier dépend des droits des contenus primaires élémentaires susceptibles d'être ajoutés.

Je voulais clairement décrire cette partie collaborative avant de poser la question des permissions dans le détail.

[Issenmann]

Je vais revoir l'ensemble de cette question des droits de mon côté mais je suis réceptive aux derniers points que pose nicolas en terme de précautions supplémentaires à prendre...

[Julie-JDS]

Je reprends cette issue restée ouverte : avons nous des aspects à préciser à présent sur la question des permissions et des précautions à prendre face à des suppressions / modifications intempestives ?