pixilib / gaelo Goto Github PK

Faut revenir a gerer les execption dans l'hexagone, pour pouvoir gerer les error message quand on en a besoin.
Si une erreur sort de l'hexagone elle fallback en 500

Une fois Orthanc Implementée faire un dump des seriesOrthancID et l'ajouter a l'archive.

• Logger dans tracker les export db

Dans la V1 code dans Scripts / Visit => Block POST

Pour l'utilisateur
Choix du visitGroup si existe plusieurs
Choix de la VisitType a Créer si existe plusieurs

=> Nécéssite une API Study/{studyName}/Patient/{patientCode}/available-visits
Retourne les Visits non crées (par rapport aux visits type dispo dans l'étude)
De Cette API on peut lister les Group / type a afficher dans le front (et on expose leur ID car elles vont etre utilisée pour créer la visite).

Le payload va contenir
Le statut Done / Not Done
La Date de visit si Done
La reason si not done

API de creation Visit
POST sur Study/{studyName}/VisitGroup/{visitGroupID}/VisitType/{visitTypeID}/Visit

Certain elements semblent non fonctionels

Make a Panel in Admin role to check auto import process of all studies (if enabled)

Le password reset de l’admin envoie bien un mail avec un nouveau mot de passe temporaire. Il permet bien de changer le mot de passe. Cependant, une fois redirigée pour se connecter avec le nouveau mdp, il n’est pas reconnu. On obtient un bandeau rouge sans message d’erreur écrit puis des Wrong password – 2 attemps, … et Blocked. => Salim => Plus que des bandeaux rouges (compte ne se bloque pas)

Enlever infos inutiles
Hiérarchie patientCode => visitModality => visitName (statusForm, statusUpload, reviewStatus, stateQuallityControl)

Ne nous manque t'il pas une route PATCH sur user pour que l'user modifie ses data lui meme ?

Reflexion en cours

Il faut avoir un statut patient : Included / Awaiting Inclusion (date d'inclusion à null) / Exited

Pour les exit => liste de raison sur le modèle GaelO v1

Passer le payload de creation de center toujours à un seul Item et ne pas autoriser d'array ?
Nécéssite d'une loop sur le front mais simplifierai le back qui deviendrai plus "restFul"

Le password reset de l’admin envoie bien un mail avec un nouveau mot de passe temporaire. Il permet bien de changer le mot de passe. Cependant, une fois redirigée pour se connecter avec le nouveau mdp, il n’est pas reconnu. On obtient un bandeau rouge sans message d’erreur écrit puis des Wrong password – 2 attemps, … et Blocked.

Probablent lié à l'attempt qui est pas remis a zero

Interdire les espace quand creation study
Mettre en majuscule tous les studyName (souvent ce sont des acronymes)

Creer policies pour creation users dans Study
Checker que le query tag est accessible dans les methode des policies

Les visits sont assignées au premier patient de la liste du tree par défaut

Essayer implementation avec stream saver pour passer de fetch=> telechargement

https://github.com/jimmywarting/StreamSaver.js/blob/master/examples/fetch.html

write import error in tracker

Se pencher sur OHIF/Viewers#1598

Peut etre dans l'array final d'email faire une recherche de mail unique pour eviter d'avoir a envoyer des duplicats pour des utilisateurs qui seraient dans plusieurs listes de roles

Dans le test du Tracker, tu fait un appel d'API pour générer des lignes dans le Tracker et ensuite faire des assertions sur l'API Tracker pour retrouver cette ligne.

C'est une mauvaise idée car si ton API qui te sert a générer des lignes dans le Tracker est cassée pour une raison qui n'a rien a voir avec le tracker ton test sur le Tracker tombe aussi (alors que ta fonction tracker sait bien lire ce qu'il y a dans la table tracker).

Ca devient difficile a debeuger, tu pense que c'est l'API tracker qui est cassée alors que c'est une autre API.

Il faut rester unitaire autant que possible, donc au lieu d'appeler une API pour générer des ligne dans la table Tracker, il faut plutot ecrire dans la BDD des lignes dans la table tracker via les factory.
Comme ca ton test reste unitaire et si il tombe c'est uniquement du a la fonction Tracker.

A terme on pourra faire des test pour verifier qu'en executant une API t'a bien un enregistrement dans Tracker que tu retrouve sur l'API Tracker mais ce sont des tests End To End et pas des tests unitaires / integration.
C'est des test utile pour tester tout l'applicatif mais plus long a excuter et plus dificile a debeuger que les tests unitaire (mais utile pour tester la cohérence de l'ensemble)

Le level patient doit apparaitre meme si y a pas de visite crées (en tout cas pour l'investigateur car il les crée lui meme)

1 Review reference le couple Study et Visit

Dans le Modele de Visit=> Methode pour get les Review qui appartiennent à une study name (Has many avec un filtre sur la study Name)

Nécéssiter de splitter la date visit pour séparer les info stable entre les etude princeps et ancillaire et les information spécifique ? (le review conclusion, peut etre le QC ?!?)

Modele d'import dans GaelO Installation => Import sample

Devenu une modification partielle

If client still connected

Hi.
Thx for awesome project. I would like to use it in our lab.
Can you provide detailed instructions how to run docker version?
I tried docker build, followed by docker run --publish=80:80, but no sucess. Am I missing some critical steps? Is the port exposed correct?

Manque info sur reviewStatus (dépend de la study courante) + nb of series + acquisitionDate (faire evoluter acquition date vers visit date et voir utilité d'afficher le nombes de series dans la table patient)

Cf Dicom sur NC

Je pense qu'il faut mieux fusionner Admin et User dans le meme use case, les deux use cases sont tres semblables.

Le problème principal est que tu dispatch sur tes usescase depuis le controller de laravel, tu te retrouve avec de la logique dans la couche infrastructure (dans le framework) alors que le but de la clean architecture et de déplacer toute la logique dans l'hexagone séparé de ton framework.
Le controlleur doit avoir le minimum de logique, il sert juste à transporter ta requete du framework vers l'hexagone.

Si tu avait 2 routes on aurait fait 2 controlleurs
Ici vaut mieux passer le query param dans le DTO et mettre la logique dans le use case.

Attention aux string 'getTrackerOfRole('Administrator');' utiliser des constantes plutot que des chaines de caractères

Manque la modalité et changer quelque clé, suivre le patron suivant :

{"patientCode":"17017101051001",
"patientFirstname":"F",
"patientLastname":"V",
"patientSex":"M",
"patientDOB":"02-00-1941",
"visitModality":"PT",
"visitDate":"11-10-2020",
"visitType":"PET0",
"visitID":179}

Probleme les utilisateur deactivé ont un email qui peuvent etre en conflit

Fav Ico is missing

Rajouter reviewStatus (study)

=> On a changé les status text des reponse http pour le front
C'était pas une bonne idée car
-> on peut pas faire d'assertion sur les statustext dans les test
->Traefik rewrite les statustext suivant les statustext officiel de HTTP et met "no reason phrase" si http code non connu.

Par contre la bonne practice serait de mettre un payload de la raison du fail dans la réponse http en echec.
C'est la meme facon que quand on output le user ID sur la réponse "password expired"

https://blog.restcase.com/rest-api-error-codes-101/

l'injection DateTime a pas encore completement remplacé l'injection Time

Feeback and reason in the interface
Write failure in tracker

Actuellement l'API creatable-visit est appelé au moment de l'affichage de visit.
Or tu n'en a besoin qu'au moment de créer une visit, tu peux pas le mettre dans componentDidMount du composant de creation de visite ?

@EmilieOLIVIE quand on a une requette qui essaie de crée un centre qui existe déjà, affilié un centre qui existe deja ect c'est une erreur client (4xx) pas une erreur serveur (500).
Le client ne devrait pas demander cette action (refusée par le serveur) mais le serveur aurait été en mesure de la traiter.

https://stackoverflow.com/questions/39636795/http-status-code-4xx-vs-5xx

Investigator : Upload / form
Controller : QC Done / Not Done
Reviewer : Review Done / Not Done

Faire un Join avec les data user pour les exposer au front
et Faire adapation du front

Copy logo in attachement for emails rather then send link to avoid domain name issue when used in reverse proxy

https://stackoverflow.com/questions/3708153/send-email-with-phpmailer-embed-image-in-body

Dans les test eviter de faire plusieurs appels au back (ex déclancher un conflict), sortir chaque appel au back en remettant la BDD a l'état désiré avant l'appel au back.
Ca rend les tests plus explicites

A ce moemnt la déja bloqué je crois, revoir le feedback

L'erreur 500 c'est une erreur interne au backend qui donne aucune information au front.
Si une requette est mal proposée, ou conflit de ressource, ou entity non existant il faut detecter les problemeq dans le back et repondre une réponse qui explique l'erreur pour le front (404 not found, 209 conflict etc ...)

L'erreur 500 c'est une erreur qui ne devrait pas se produire

https://laravel.com/docs/8.x/upgrade

A faire :
https://laravel.com/docs/8.x/upgrade#updating-dependencies
https://laravel.com/docs/8.x/upgrade#seeder-factory-namespaces

Reecrire les factories :
https://laravel.com/docs/8.x/database-testing#creating-factories

Pour les routes Ce probleme risque de se poser (et la nouvelle syntaxe apparait plus propre) : https://www.youtube.com/watch?v=MfE1tnMG6fE&t=127s

A voir avec doc laravel, y a un soucis sur les destinataire des mails