Saisies fichiers #4

Open
opened 2 years ago by maieul · 3 comments
maieul commented 2 years ago
Collaborator

Hop,

un ticket de réflexion : il y a plusieurs demande d'avoir des saisis fichiers en champ extra. Par exemple j'ai le cas d'une personne qui souhiaterait associer des fichiers en tant que champ extra d'une réponse.

Ca pose question car c'est potentiellement redondant avec les documents natifs de SPIP. Mais tout de même, parfois plus pertinent (notamment si on veut s'assurer que pour un objet donné il n'y a qu'un fichier).

Bon du coup la question est

  1. Bonne idée/mauvaise idée ?
  2. Si mauvaise idée, faudra documenter explicitement pourquoi on propose pas
  3. Si bonne idée, faudra voir où on stocke le fichier champ extra
Hop, un ticket de réflexion : il y a plusieurs demande d'avoir des saisis fichiers en champ extra. Par exemple j'ai le cas d'une personne qui souhiaterait associer des fichiers en tant que champ extra d'une réponse. Ca pose question car c'est potentiellement redondant avec les documents natifs de SPIP. Mais tout de même, parfois plus pertinent (notamment si on veut s'assurer que pour un objet donné il n'y a qu'un fichier). Bon du coup la question est 1. Bonne idée/mauvaise idée ? 2. Si mauvaise idée, faudra documenter explicitement pourquoi on propose pas 3. Si bonne idée, faudra voir où on stocke le fichier champ extra
Collaborator

Oué, la question se pose souvent, et la réponse n’est pas claire :)
Pourtant je suis quasiment sûr qu’il y aurait tout plein d’usages.

Pour sûr, il me semble qu’il faut créer le fichier dans spip_documents pour avoir toutes les fonctionnalités dessus (taille, miniatures, titre...), sinon avoir simplement un chemin '/config/fichiers/xx' me semble trop limité.

Le champ extra pourrait alors revenir à stocker l’identifiant du document.
Ce qui peut être délicat à gérer c’est pas tant l’upload + mise en document,

  • que la gestion de la suppression / changement de document déjà actif sur le champ (le document est-il utilisé ailleurs ; déliaison ou suppression ?)
  • la gestion des autorisations de voir le document (considéré orphelin) dans la médiathèque car non lié à l’objet via spip_documents_liens ou un <docXX> dans le texte

Et sinon à quoi pourrait correspondre une possibilité d’autoriser plusieurs documents sur un même champ extra

Oué, la question se pose souvent, et la réponse n’est pas claire :) Pourtant je suis quasiment sûr qu’il y aurait tout plein d’usages. Pour sûr, il me semble qu’il faut créer le fichier dans spip_documents pour avoir toutes les fonctionnalités dessus (taille, miniatures, titre...), sinon avoir simplement un chemin '/config/fichiers/xx' me semble trop limité. Le champ extra pourrait alors revenir à stocker l’identifiant du document. Ce qui peut être délicat à gérer c’est pas tant l’upload + mise en document, - que la gestion de la suppression / changement de document déjà actif sur le champ (le document est-il utilisé ailleurs ; déliaison ou suppression ?) - la gestion des autorisations de voir le document (considéré orphelin) dans la médiathèque car non lié à l’objet via spip_documents_liens ou un `<docXX>` dans le texte Et sinon à quoi pourrait correspondre une possibilité d’autoriser plusieurs documents sur un même champ extra
Poster
Collaborator

mais si on met dans la table de document, quel différence avec un document lié avec une liaison typée ?

mais si on met dans la table de document, quel différence avec un document lié avec une liaison typée ?

C'est aussi une demande que j'ai rencontré plusieurs fois. Dans plusieurs de ces cas, je m'en suis pour l'instant sorti avec des rôles de documents, en mode "principaux" donc un seul par type. Mais ce n'est vraiment pas la même chose. De plus il me semble que c'est plus compliqué qu'utiliser les spip_documents (et donc à priori IMG).

Un champ de type fichier :

  • on doit pouvoir définir les formats acceptés
  • on doit pouvoir dire s'il est obligatoire ou pas (ce qui n'est pas possible avec les rôles de document pour l'instant)
  • on doit pouvoir dire si ensuite c'est un contenu public ou pas, et DONC… ne pas l'enregistrer forcément au même endroit !

En effet, un champ fichier peut être utilisé (et c'est 100% des cas que j'ai rencontré) pour uploader des fichiers uniquement personnels, à lire que par les admins/modos : carte d'étudiant, attestion de ceci cela, fiche d'impôt… à aucun moment ces fichiers ne devraient se retrouver dans IMG/ (qui est "permanent accessible" je rappelle). Ce n'est donc pas juste une question d'autorisation PHP, ça ne devrait même pas être dans un dossier si accessible.
Par ailleurs, même pour les fichiers qu'on voudrait public, on peut ne pas vouloir que ça ait un rapport avec la médiathèque (pas trouvable ni choisissable dans d'autres contenus).

C'est pour cela que par défaut, cette fonctionnalité codé dans Formidable stocke ça d'abord dans config/ (permanent inaccessible).

Là pour Champs Extras, je ne sais pas si ça doit toujours être pareil, peut-être que ça pourrait avoir plusieurs "implémentation de stockage", et que dans la config chaque champ fichier, on puisse définir si on veut que ce soit privé ou public (voire en documents médiathèque). Je verrais bien trois possiblités :

  • privé
  • public mais propre à l'objet
  • public et complètement dans la médiathèque, en doc comme les autres
C'est aussi une demande que j'ai rencontré plusieurs fois. Dans plusieurs de ces cas, je m'en suis pour l'instant sorti avec des rôles de documents, en mode "principaux" donc un seul par type. Mais ce n'est vraiment pas la même chose. De plus il me semble que c'est plus compliqué qu'utiliser les spip_documents (et donc à priori IMG). Un champ de type fichier : - on doit pouvoir définir les formats acceptés - on doit pouvoir dire s'il est obligatoire ou pas (ce qui n'est pas possible avec les rôles de document pour l'instant) - on doit pouvoir dire si ensuite c'est un contenu public ou pas, et DONC… ne pas l'enregistrer forcément au même endroit ! En effet, un champ fichier peut être utilisé (et c'est 100% des cas que j'ai rencontré) pour uploader des fichiers uniquement personnels, à lire que par les admins/modos : carte d'étudiant, attestion de ceci cela, fiche d'impôt… à aucun moment ces fichiers ne devraient se retrouver dans IMG/ (qui est "permanent accessible" je rappelle). Ce n'est donc pas juste une question d'autorisation PHP, ça ne devrait même pas être dans un dossier si accessible. Par ailleurs, même pour les fichiers qu'on voudrait public, on peut ne pas vouloir que ça ait un rapport avec la médiathèque (pas trouvable ni choisissable dans d'autres contenus). C'est pour cela que par défaut, cette fonctionnalité codé dans Formidable stocke ça d'abord dans config/ (permanent inaccessible). Là pour Champs Extras, je ne sais pas si ça doit toujours être pareil, peut-être que ça pourrait avoir plusieurs "implémentation de stockage", et que dans la config chaque champ fichier, on puisse définir si on veut que ce soit privé ou public (voire en documents médiathèque). Je verrais bien trois possiblités : - privé - public mais propre à l'objet - public et complètement dans la médiathèque, en doc comme les autres
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.