Fonctionnalité 1 : Envoi d'un panier de commandes aux CRB correspondants
Soumission de liste d'accessions pour soumission de commande aux CRB correspondants
portail RARe
Dans leTâches identifiées
-
Possibilité de sélectionner des accessions, unitairement via checkbox, ou avec multi-sélection (ie. touche SHIFT pour facilement sélectionner des accessions consécutives) Done https://forgemia.inra.fr/urgi-is/data-discovery/-/merge_requests/268 (multi-sélection sortie du scope) -
Possibilité de sélectionner toutes les accessions visibles dans une page. Done https://forgemia.inra.fr/urgi-is/data-discovery/-/merge_requests/283 -
Possibilité de sélectionner toutes les accessions d'un résultat de recherche ? Avec boite de confirmation en cas d'un grand nombre d'accession . Abandonné après discussions -
Possibilité de vider le panier. Done https://forgemia.inra.fr/urgi-is/data-discovery/-/merge_requests/284 -
Affichage du comptage du nombre d'accessions sélectionnées. Done https://forgemia.inra.fr/urgi-is/data-discovery/-/merge_requests/270 -
Ajout d'un paramètre de configuration d'un endpoint (URL + token d'application) pour soumettre le panier des accessions sélectionnées, envoyant la liste des brcName
,accessionProvider
+providerContact
(+identifier
?) + accessionname
(csv à , ou 5 colonnes), cf. format soumission. Done https://forgemia.inra.fr/urgi-is/data-discovery/-/merge_requests/271 et https://forgemia.inra.fr/urgi-is/data-discovery/-/merge_requests/277
Format de soumission
Voir si le format demeure ainsi ou si il évolue en fonction de #2
# brcName;accessionProvider;providerContact,identifier,name
CoArCol;CoArCol;colcbgp@inrae.fr;CAC_EPER0001;EPER0001
CoArCol;CoArCol;colcbgp@inrae.fr;CAC_EPER0007;EPER0007
Colisa;Colisa;colisa@inrae.fr;T16 _ EC _ 5;T16
Colisa;Colisa;colisa@inrae.fr;T2796 _ EC _ 5;T2796
TCC;TCC;tcc-carrtel@inrae.fr;TCC2a;TCC2a
TCC;TCC;tcc-carrtel@inrae.fr;TCC13;TCC13
Forest Tree;Biogeco;contact@biogeco.inrae.fr;accIdentifier;accName
Dans une application rare-basket
Application à développer, code source à déposer dans le projet courant.
Tâches
-
Mise en place de la stack de l'application, sur le même principe que pour RARe : basée sur Spring Boot + NPM + SGBD à déterminer1 Done !1 (merged) !2 (merged) -
Mise à disposition d'une API sécurisée (dés lors que l'API permet l'envoi automatique d'e-mail, il faut contrôler l'accès pour éviter toute tentative de spam/phishing) permettant de soumettre des commandes prenant en entrée une liste de type, au choix parmi (non exhaustivement) : Done via keycloak !23 (merged) - Via une API key implémentée maison : https://stackoverflow.com/questions/48446708/securing-spring-boot-api-with-api-key-and-secret
- Via un token JWT (ressources : https://blog.ippon.fr/2017/10/12/preuve-dauthentification-avec-jwt/ ou encore https://www.linkedin.com/pulse/api-security-key-deadlong-live-distributed-token-value-joseph-george/)
- Via des outils dédiés2 : Gravitee.io et/ou Keycloack, cf. mise en place d'une environnement de test avec un docker-compose : https://github.com/gravitee-io/Tool-In-Action-2018.
-
Affichage d'un formulaire de commande d'accessions par le demandeur précisant : Done !15 (merged) !16 (merged) !17 (merged) !18 (merged) - nom
- adresse
- type de demandeur
- quantité demandée par accession
- objet de la demande (à quoi serviront les ressources: détermine en partie le type de MTA)
-
La validation du formulaire active l'envoi d'e-mails à chacun des contacts de BRC associés aux accessions (avec le demandeur en copie pour qu'il ait une trace de l'e-mail) <= si un récap de la commande est envoyé au préalable au client, il n'est pas nécessaire de le mettre en copie de chaque e-mail envoyé aux CRB, uniquement en reply-to, cf #3 (comment 20779) Done !9 (merged) -
En parallèle de cet envoi d'e-mail(s), enregistrement en base de toutes les informations renseignées, accessibles uniquement aux responsables de CRB, en préparation des pré-commandes, dont le mécanisme sera traité dans #4 Done -
Prévoir une gestion RGPD compatible permettant à chaque demandeur d'obtenir des informations relatives à ses demandes : lister publiquement les types d'informations personnelles stockées, et leur usage dans l'application. Voir #14 (closed) pour plus de détails
-
Le choix du SGBD doit prendre en compte notamment les fonctionnalités de #5 : si l'on peut utiliser Kibana pour disposer d'un environnement permettant de générer des tableaux de bord facilement à moindre coût, c'est préférable.
↩ -
À privilégier peut-être, en prévision des authentifications pour la gestion des commandes par BRC, cf. #4
↩