Absence de fichiers dans fiche bazar

Support Bazar
#1

Je rencontre un soucis sur des fiches bazar contenant un champ de type fichier.
L’identifiant du champ contient une lettre majuscule « fichierRessource » qui est maintenant automatiquement renommé « fichierressource » tout en minuscule
En conséquence toutes les anciennes fiches qui possèdent un fichier enregistré avec l’identifiant de champ « fichierRessource » n’affichent plus leur fichier joint.

Il y avait une issue ouverte sur la question mais je ne vois pas si elle avait donné lieu à un correctif

#2

Le problème est assez complexe à gérer selon moi via update et je trouve aussi que ça peut être compliqué de bien gérer la compatibilité sans contrainte de casse.
On pourrait imaginer ceci.
Pour les champs bazar officiels :

  • en lecture : si la valeur n’est pas trouvée, on vérifie s’il existe une clé similaire dans les données avec une casse différente et ainsi on rend toujours une valeur
  • en écriture : lors de l’enregistrement, normalement la clé sera automatiquement mise à jour

Ceci ne permettra pas de résoudre les soucis pour que les recherches de type query fonctionnent quelque soit la casse.

#3

Merci @j9rem pour la proposition, mais ca me semble un peu complexe comme logique et du coup ce sera encore plus dur d’identifier pourquoi on a des pb de query…
Après réflexion, je pense que le soucis est assez rare puisque pour le reproduire il faut :

  • un wiki créé avant 2020
  • un formulaire qui contient des identifiants de champ qui ont été modifiés et dans lesquels des majuscules ont été utilisées (peu de personnes font ca en réalité)
  • modifier le formulaire, car le passage des identifiants en minuscules n’est enregistré qu’au moment de la sauvegarde des formulaires

Ces 3 conditions sont rarement réunies, et je n’avais pas en tête que c’est lié au form builder et pas modifiable facilement donc si il faut une usine à gaz pour contourner le pb, mieux vaut agir en local avec un update en sql des identifiants de champ

#4

Merci @MelanieM pour ton retour.
Et j’avoue que les solutions vont chercher finalement à résoudre des cas assez rares. Donc on ne va pas plus loin.

#5

Le problème a été résolu grâce au tools pour renommer les champs, merci pour le dépannage @j9rem
Peut être que ce tools serait utile à d’autres en le diffusant dans une extension ?

#6

On pourrait par exemple utiliser la fonctionnalité proposée par cette branche https://github.com/YesWiki/yeswiki/tree/feat/bazar-rename-field

zone de test : Testing : BazarRepair (attention zone avec visibilité exceptionnellement ouverte aux non admins)

Qu’en penses-tu @mrflos de cette interface qui semble convenir à @MelanieM ?

#7

Hello @j9rem ,

Oui c’est une bonne feature de pouvoir renommer les champs, mais a mon avis, pas besoin de passer par une interface au même niveau que tout le cœur de bazar.

Il faudrait plutot que cela soit invisible a l’usager, mais que si l’on modifie le nom d’un champ dans le formbuilder de bazar, que la fonction des renomage de champs s’occupe de faire cette mise a jour des données pour les fiches existantes.

Par contre, je pense que les images et fichiers nécessiteraient aussi des vérifications…

#8

@mrflos je suis embêté car dans l’état actuel de YesWiki, il n’y a pas de stockage de l’information pour détecter le renommage d’un champ. Il n’est pas possible de déclencher automatiquement le renommage d’un champ.
De plus, le renommage d’un champ est à l’initiative de l’administrateur et il peut y avoir tellement de cas possibles du fait que nous utilisons plein d’options et la possibilité de saisir via texte le template du formulaire qu’il nous faudrait une analyse sémantique poussée pour détecter l’intention de l’administrateur et faire le renommage comme demander.

Pour éviter ce genre de traitement complexe, est-ce que nous pouvons garder l’idée d’un processus non automatique où l’administrateur contrôle ce qui va être fait pour éviter les pertes d’informations ?

Est-ce que ça te va si c’est dans une page dédiée via l’action {{bazarrepair}} ?

Concernant les fichiers images et fichiers, je ne vois pas de quelle vérification tu parles. Pourrais-tu être plus précis ?

#9

Oui biensur, tu peux faire cela dans une extension et comme cela les rares personnes ayant le soucis pourront passer par là.
En ce qui concerne le coeur de YesWiki, il me semble qu’il faudra à un moment ou un autre s’occuper de l’intégrité des données apres modif du formulaire bazar, j’essayerai de regarder de mon coté si c’est envisageable pour une version yeswiki 4.5.

Si un champ image bf_toto crée une image dans files, et que le champ est ensuite renommé bf_tata, les images précédemment crées garderont dans leur nom bf_toto ce qui n’est pas très logique.

#10

@mrflos certes mais ce n’est quasiment pas visible pour l’utilisateur et ca n’empêche pas le fonctionnement correct du lien pour télécharger le fichier donc à mon humble avis ce n’est pas nécessaire de passer de l’énergie à renommer les fichiers

#11

Ah je proposais de l’intégrer dans le coeur et non dans une extension car ça peut être utile à tout le monde mais en le mettant en discret (il faut connaître le nom de la page et/ou de l’action pour s’en servir).

Est-ce que ça pose un souci ?

Pour les fichiers et images, effectivement, le renommage empêchera la suppression définitive des fichiers depuis la fiche (ce qui n’est pas très grave en soi) et modifiera le nom affiché pour le fichier (car le nom du champ aura changé).
Je ne suis pas sûr que ce soit gravissime pour le moment.
Est-ce que sans les fonctionnalités que tu proposes, nous pouvons déjà intégrer l’outil de renommage des champs dans le coeur pour aider les admins ?

#12

Non, je préférerais que des actions de maintenance spécifiques soient plutôt disponibles en dehors du cœur, dans une extension, l’idée serait de proposer dans la 4.5 juste des ameliorations d’interface bazar et des réglages d’import/export, puis de ce concentrer sur la bascule vers ectoplasme.

Créer une extension maintenance avec des utilitaires comme tu proposes, aussi la suppression de pages a la volée, et par la suite les passages a markdown me semble faire sens : en cas de soucis, on pourrait l’installer pour régler un problème, puis remettre comme avant une fois le soucis réglé

#13

OK je mets ça dans une extension maintenance avec les outils de multideletepages et je pousse en direct les commits nécessaires dans le cœur pour permettre les connexions aux services (comme EntryManager)

#14

C’est quoi les commits pour permettre les connexions aux services?
Faut pas rajouter de routes api, c’est au niveau de l’extension qu’il faudra les mettre, hein

#15

juste dans EntryManager des petits correctifs sur le truc pour renommer les champs
Mais aucun controller

#16

Le but c’est de ne pas complexifier le cœur de YesWiki, si je regarde ta PR, et que ta proposition est de rajouter les constantes RESTRICTED_FIELD_NAMES Comparing doryphore-dev...feat/bazar-rename-field · YesWiki/yeswiki · GitHub , c’est pas possible c’est trop de bruit pour le coeur de yeswiki.
Si tu veux faire des choses comme ca, je t’invite a faire une classe qui hérite d’EntryManager dans l’extension et y faire ce que tu voudras, ou d’ajouter les constantes à l’action bazarrename mais pour le cœur, l’idée c’est de n’y toucher que si cela ne rajoute pas des choses compliquées et apporte une fonctionnalité générique.