Communauté des utilisateurs de Medshake EHR/EDC

je mets la solution quand même si quelqu'un avait fait la même boulette que moi. Lors de la montée en version de ma distribution je pensais que mariadb était automatiquement mis à jour, mais non il faut faire :

mysql_upgrade -u root -pvotremotdepasseroot 

je suis en v8.0.0 ^^

Bon donc si on résume :

• un problème SQL pour la valeur par défaut sur un champ label : a priori va se représenter
• un problème de conversion yaml avec faux chemin : corrigé.

Il faut donc que je regarde pour gérer ce premier point.
Pas évident, il faudrait agir avant la mise à jour des fichiers ce qui n'est pas prévu dans le process ...

B.

Oui merci beaucoup. Ça va servir au suivant. Je n'ai testé les migrations que de 7.3.2 sans aucun bug, mais peut-être que les utilisateurs ayant commencé par la version 7 sont protégés également.

Je me débats maintenant avec mon propre module. Ça marchait bien pourtant aussi sur les tests d'installation et de mise à jour

Warning
: yaml_parse(): parsing error encountered during parsing: did not find expected key (line 37, column 2), context while parsing a block mapping (line 1, column 1) in
/opt/ehr/class/msYAML.php
on line
42


Fatal error
: Uncaught TypeError: array_key_exists(): Argument #2 ($array) must be of type array, null given in /opt/ehr/class/msForm.php:219 Stack trace: #0 /opt/ehr/controlers/module/osteo/patient/actions/inc-ajax-extractCsForm.php(40): msForm->setPrevaluesAfterwards() #1 /opt/ehr/controlers/module/osteo/patient/actions/patientAjax.php(40): include('...') #2 /opt/ehr/public_html/index.php(147): include('...') #3 {main} thrown in
/opt/ehr/class/msForm.php
on line
219

Je viens de cloner le module pour regarder.
Il semble assez simple.
Visiblement, tu es déjà repassé sur les points essentiels.

S'il y a un problème de yaml, il faut tenter de les éditer dans l'administration pour voir lequel pose problème, mais apparemment, pareils, tu es déjà repassé dessus.

B.

alors je viens d'identifier le premier bug du module de base. J'avais fait mes tests sur debian11 est mariadb 10.4 ou 5. en chargeant une ubuntu 22.04 c'est mariadb 10.6 et je reproduis exactement le même bug. ça risque d'impacter également les utilisateurs de debian 12

Pour le moment j'ai rollback en 7.3.2 (vive timeshift et le btrfs) pour reproduire un environnement de test ubuntu 22.04 et poursuivre les tests de la 8.0.0. Pour mon module j'ai tellement fait d'aller-retour que je vais reprendre ça de la version précédente je pense.

J'ai poursuivi les tests sur l'ubuntu 22.04 fraîches avec mon module et tout fonctionne. Peut-être qu'en poussant plusieurs fois le zip ça a mis le bazar dans le formulaire ou peut-être qu'en partant de la version 6.6 il manque quelque chose. Je vais retester, on touche au but peut-être

Bon même message d'erreur. Sur mon test d'ubuntu j'ai inséré directement la dernière version du module ostéo. Peut être que le problème viens de la mise à jour du module. Je vais reregarder le sql upgrade du module chiro j'ai peut-être loupé quelque chose

Truc étrange sur debian 11, la mise à jour de la version v7.3.2 vers 8.0.0 convertissait les formulaires avec le bon format yml. En faisant la même chose sur ubuntu 22.04 ça ne le fait pas et ça crée une erreur lorsque l'on tente d'accéder au formulaire.

J'ai fait la même chose avec le module chiro ras.

Il doit y avoir un truc sur le module ostéo non compatible avec mariadb 10.6

Erreur car le formulaire est mal converti ou pas du tout ?
Si pas du tout, il est possible que les actions en amont de la conversion ne soient pas réalisées non plus et que le pb de conversion ne soit que la partie visible.

B.

Je viens de trouver, un espace en trop dans l'ancien formulaire sur deux row à la fin après le flow des articulations sur l'ancien formulaire, du coup yaml non permissif, la moulinette ne pouvait pas faire de miracle .
Est-ce que dans ce cas, je peux pousser la mise à jour du formulaire dans le sql upgrade, même si ce n'est pas la procédure habituelle ?

Plusieurs enseignements de mes tests par contre :

Comme je ne sais pas pourquoi la première fois la moulinette avait quand même corrigée l'erreur sur debian 11 j'ai retesté dessus et j'ai tenté une maj 7.3.2 à 8.0.0 en php 7.4. À la déconnexion le logiciel échoue à retrouver la page de login, mais en rafraichissant la procédure suit son cours et pas de bug de BDD comme sur Ubuntu 22.4

Mes images docker sont sur l'image officielle de PHP qui est compilé sur une image Debian 11. Sur ma stack, je suis en PHP 8.1 ou 8.2 mariadb 10.6 et 0 bugs de BDD lors du passage 7.3.2 à 8.0.0 donc le bug est peut-être spécifique à ubuntu et toucher soit la BDD, soit le module php qui communique avec.

Si c'est le module ça pourra impacter le projet de Bugeaud, si c'est la base de donnée ça n'aura pas d'impact.