problème de modele

[ygrekconsutling]

Lorsque je télécharge le modèle de base de forme de contrôle et que je le reupload ensuite, a chaque fois que je veut commencer un point de contrôle en allant dans le détail d'une tache planifié et que je clique sur télécharger le modèle prérempli je me retrouve avec un fichier word (docx) corrompu Debian, Apache2, php 8.2

[dbarzin]

Y a-t-il une erreur dans les logs (storage/logs/laravel.log) ? Avec quoi ouvres-tu le fichier (OpenOffice, Word...) ? Peux-tu poster le modèle et le fichier corrompu ici ?

[ygrekconsutling]

Au niveau des logs rien de nouveau, j'ai seulement les local debug lié à l'injection des mesures de tests liés aux référentiels J'ouvre le fichier avec Word 2019 lorsque je tente de l'ouvrir avec libre office (depuis /storage/templates/) j'ai une erreur qui me permet d'ouvrir le document en lecture seule mais semble quand même que le document soit cassé, (il manque des infos)

En théorie le modèle ressemble a ceci: et le fichier généré ressemble a ceci: (avec libre office sur debian directement sinon impossible de l'ouvrir)

le modèle et le fichiers corrompu sont là: corupted.docx modele de controle.docx

en décortiquant un peu l'archive docx, j'ai pu remarquer que la version de libre office utilisé était celle par défaut installé sur ma version de debian (2022/7.xx) autrement dit c'est assez bien, j'ai du coup lancé un coup de

sudo apt-get remove --purge "libreoffice*" sudo apt-get clean sudo apt-get autoremove

suivi d'une installation propre de la dernière version de sorte a ce que le server ne puisse proposer que la toute dernière version (24+) bien entendu, la version référencée est celle utilisée pour la création du modèle et non celle utilisée pour modifier le fichier, j'ai regardé également au niveau des droits mais l'utilisateur www-data a bien rwx sur le dossier et sont contenu :/ Je sèche un peu là

Au final j'ai réussi a trouver une solution, en comparant les deux fichiers je remarque que le "plantage" se trouve autour de ${attributes}, je décide donc de simplement le faire sauter en retirer ce qui en fait une variable, et hop! le fichier se génère correctement

par contre les observations ne se reprennent pas automatiquement DANS le fichier, il faut les copier coller, je pense que le template de base ne prend pas le replace de ${observations} de base, j'ai pas testé de le rajouter mais bon ça sent juste le petit commit pour modifier le fichier de template de base, je n'ai pas vu passer de liste d'attributs possibles qu'on peut mettre dans ce template de contrôle :/

merci pour le retour

[dbarzin]

Merci pour cette analyse. Deming n'utilise pas Libre Office ni Open Office pour générer les fichiers, mais la librairie PHPOffice. Le problème ne vient pas de là.

De mon côté, j'arrive à générer une fiche de contrôle à partir du modèle fourni : control-5.04-20240520.docx

Peux-tu essayer de supprimer les variables dans le modèle pour identifier celle qui pose un problème puis sans doute le texte dans cette variable qui génère un document invalide.

Il n'était pas prévu de mettre le champ observations dans le modèle bien que cela ne pose pas de problème. L'idée étant que les observations sont à mettre directement dans le document.

Si tu souhaites aller plus loin, le code à modifier se trouve dans app/HTTP/Controllers/ControlController.php dans la fonction template()

[ygrekconsutling]

c'est exactement ce que j'ai fait en supprimant la variable attribute du modèle comme j'ai mis en note en dernier paragraphe et pour les observations en fait je me disais que comme ça se rempli de toute manière sur l'interface, pourquoi ne pas les remettre directement dans la fiche a remplir

[dbarzin]

As-tu identifié dans ce champ qui pose ce problème ?

[ygrekconsutling]

non, je n'ai pas encore eu le temps de m'y mettre, je regarderais ça tout a l'heure. J'ai quand même tenté une install sur un autre serveur au cas où et sans tenter de toucher au modèle de base, la generation se fait bien directement sans encombres, je vais mettre un gros try catch sur le fichier et quelques debugger pour tracer d'où ça vient

[ygrekconsutling]

Oups l'habitude de l'anglais dans git :/ J'ai pu trouver la cause en comparant les deux version du serveur 1 et serveur 2, le second a un champs attribut qui apparait dans le détail d'un point de contrôle et le premier server n'en fait même pas mention, j'ai voulu dump la variable ligne 1243 et je me suis retrouvé avec une string vide, du coup j'imagine qu'il y a eu un problème au niveau de l'installe ou de l'init mais je vois vraiment pas ou ça peut arriver, y a pas tellement de place pour un oubli dans la procédure. Il faudrait peut être ajouter un peu plus de contrôle si jamais la valeur est vide comme c'est le cas pour l'écran de visualisation lui même où le titre attributs lui même n'apparait pas si il n'y a pas de données à afficher. Avec un référentiel custom j'imagine qu'oublie de mettre les attribut planterais automatiquement la génération de ce modèle dans les points de contrôle en question