V8.0.0 mergée dans master

Les sujets de cette catégorie concernent le développement du logiciel MedshakeEHR.
marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: V8.0.0 mergée dans master

Message non lu par marsante »

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 :

Code : Tout sélectionner

mysql_upgrade -u root -pvotremotdepasseroot 

je suis en v8.0.0 ^^

Avatar de l’utilisateur
Bertrand
Messages : 177
Inscription : 21 juil. 2020, 18:08
Localisation : Dans le grand bain
Contact :

Re: V8.0.0 mergée dans master

Message non lu par Bertrand »

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.

MedShakeEHR : Le Logiciel Médical Modulaire Libre
http://www.medshake.app/

MedShake : communauté médicale bien fraîche (et un peu secouée) !
https://www.medshake.net/

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: V8.0.0 mergée dans master

Message non lu par marsante »

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 :lol:

Code : Tout sélectionner

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
Avatar de l’utilisateur
Bertrand
Messages : 177
Inscription : 21 juil. 2020, 18:08
Localisation : Dans le grand bain
Contact :

Re: V8.0.0 mergée dans master

Message non lu par Bertrand »

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.

MedShakeEHR : Le Logiciel Médical Modulaire Libre
http://www.medshake.app/

MedShake : communauté médicale bien fraîche (et un peu secouée) !
https://www.medshake.net/

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: V8.0.0 mergée dans master

Message non lu par marsante »

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.

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: V8.0.0 mergée dans master

Message non lu par marsante »

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

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: V8.0.0 mergée dans master

Message non lu par marsante »

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

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: V8.0.0 mergée dans master

Message non lu par marsante »

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

Avatar de l’utilisateur
Bertrand
Messages : 177
Inscription : 21 juil. 2020, 18:08
Localisation : Dans le grand bain
Contact :

Re: V8.0.0 mergée dans master

Message non lu par Bertrand »

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.

MedShakeEHR : Le Logiciel Médical Modulaire Libre
http://www.medshake.app/

MedShake : communauté médicale bien fraîche (et un peu secouée) !
https://www.medshake.net/

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: V8.0.0 mergée dans master

Message non lu par marsante »

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 :oops: .
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.

Répondre