# Stabilisation du projet RERO-ILS Lors du dernier grooming il a été décidé de passer 80% des story points sur la stabilisation. Ceci comprend: - la résolution des "issues" - le monitoring et infrastructure IT de production En dehors de ces deux points nous devons écrire des nouvelles US non fonctionnelles orientées: - performances - suppression de hacks par (ex. suppression de l'item type pour le mettre au niveau de la holding) - stabilisation du code côté UI ou backend - nettoyage des tests, etc. Afin d'écrire ces US je vous propose de lister des propositions conctètes en mettant votre nom comme sous-titre et de lister des choses qu'il faudrait faire pour stabiliser le code, si possible par ordre de priorité: le plus urgente en premier. Nous débatterons de ces points lors d'une séance durant le sprint 41. Exemple: ## Nom - supprimer les "_" des propriétés privées - changer l'outil de linter pour angular ## Propostions par personne ### Renaud - traiter toutes les dates comme UTC sans notion de timezone. L'affichage de la date correctement formatée (avec notion de timezone) devrait être faite dans Jinja/Angular. - optimisation des indexations :: est-ce quand on met à jour un loan, il faut indexer les contributeurs du document. - operation logs créé en async ? (déjà une ISSUE dans milestone 1.3.0) - Plus de documentation dans les méthodes/tests afin de les appréhendez pus facilement. - Responsive design pour la vue publique - meilleur cloisonnement des ressources/modules si possible (afin d'éviter les circular imports) - Contexte pour les traductions (Babel / ngxtranslate / Weblate compatible ?) ### Benoit - continuer à optimiser le temps de réponse des opérations de circulation (checkout/checkin) - améliorer le temps de chargement dans l'éditeur de document (doc. existant ou importation BnF) ### Bertrand - Ré-écriture de l'initialisation des applications UI (Services: User, Settings, etc…). - Intégrité des données ? Si on supprime une ressource, il faut s'assurer que l'on a rien oublié (en cascade). - Version mobile publique (beaucoup de problèmes d'affichage) - L'utilisateur ne peut pas modifier les données qui se trouvent dans sa(ses) fiche(s) patron (si transfert dans Angular, personnaliser les formulaires.). - Vue globale: Discussion pour savoir si l'on fait des renvois (fonctionnement actuel sur Explore) sur la vue de l'organisation ou si l'on permet les demandes dans cette vue. - __Identification sur ILS devrait se faire avec OAuth__ pour permettre de s'identifier automatiquement sur les services externes (C'est le cas actuellement sur Explore). Pas de système d'identification dans l'application. Etre client __OAuth__. __Pas de login simple__ - OAuth server: avoir un *endpoint* qui maintient la compatibilitié avec la version actuelle et un autre *endpoint* avec de nouvelle spécification (pour coller à rero ils). - Backend: Faire passer tous les appels par l'API et éviter de passer par le bas niveau. - Avoir un API stateless (utiliser Invenio que pour l'API) => JWT ou autre ? - Angular: Splitter les applications (publique, professionnelle) et qu'elles soient autonomes (pas d'intégration dans Invenio) => Plusieurs dockers. - Plus de mélange entre Jinja et Angular. - Améliorer le look de l'application (pour qu'elle soit "vendeur"). - Supprimer ngx-translate pour le module natif angular i18n. - Afficher les exemplaires dans la "brief view" pour pouvoir faire des demandes sans devoir aller dans la vue détaillée (évite des clics) (fonctionnement actuel sur Explore). - Splitter certains services. Ex: Un projet pour le deamon SIP2 (avec interrogation de l'API). L'envoi de mail est assez lent, donc sortir le service (en utilisant les queues, ex: RabbitMq). - Traduction: Faire plusieurs catalogues pour éviter des conflits de chaine. - Traduction: Séparer les chaines publiques et professionnelles (Ex: problème avec les pays, car en admin on a "italie (it)" et cela apparaît dans l'interface publique. Le "(it)" ne devrait pas être présent). - Permettre le login avec le code-barre qui se trouve sur la fiche `lecteur` et pas uniquement le `username`. __Les bibliothèques émettent des cartes avec un code-barre unique pour leur réseau__. ### Aly - Analyser le `invenio-stats` pour voir s'il peut être une solution pour `operation_logs` et `loan_history`. Si non, trouver une autre solution tout de suite. - test unitaires plus rapides (supprimer des tests, réduire le nombre de fixtures ...etc) - Analyser le `circulation` pour voir où se situe exactement le problème (invenio-circulation, class Item ... ?) - Peut-on avoir une ressource représentée par un `table postgres` uniquement? créer un cas, et voir quels `modules` actuels peuvent être représentés par des tables DB. - supprimer le `item_type` de l'item. - supprimer le `location` de l'item. - renommer `item_type` par `circulation_category` everywhere. ### Peter - Un operation log par ressource ou operation log directement dans la ressource. - Utilisation de invenio_record_resource (sera amélioré: indexer, creation pid, serializer, ...). - Suppression du pid dans le json. - Utilisez Cellery directe pour envoyer des emails pour les notifications. ### Seb - Optimisation performances. - Amélioration design, y compris responsive. - Optimisation référencement. - Passage des ressources vers `invenio-records-resources`. - Merge des applications UI en une seule (excepté web component). ### Nicolas - Mise en place d'une instance test et pré-prod pour le go-live. - But: permettre des formations sur une base qui n'affectera pas la production. - Éventuellement ajouter des user/librarians fixes réinitialisables facilement. ### Laurent - Optimiser l'indexation (par exemple, pour 2 millions d'exemplaires, le temps d'indexation est vraiment très long.) - Optimiser le code (nettoyage, logique des méthodes) - Mise en place de scripts (via CLI?) afin de pouvoir faire des corrections de masse. - Passer toute l'interface utilisateur publique en angular. - Rendre l'interface UI plus sexy. - Mettre en oeuvre les "TODO" dans le code. - Nettoyages et optimisation des tests. - Passage en douceur à invenio record ressource. ## Candidats pour des US - 13 [peter] Utilisation de invenio_record_resource (sera amélioré: indexer, creation pid, serializer, ...), faire un spike, le bon timing?. - 10 [seb] Amélioration design (pas l'ergonomie), y compris responsive. - [priorité PO] max 3 points (éventuellement, scinder en 2 US) - 10 [benoit] continuer à optimiser le temps de réponse des opérations de circulation (checkout/checkin), objectif: < 1s - [priorité PO] - 5 [seb] Optimisation générale performances. - 3 [bertrand] Intégrité des données ? Si on supprime une ressource, il faut s'assurer que l'on a rien oublié (en cascade). - 1 [benoit] améliorer le temps de chargement dans l'éditeur de document (doc. existant ou importation BnF), objectif: <= 2s ### Pour plus tard - [renaud] optimisation des indexations : est-ce quand on met à jour un loan, il faut indexer les contributeurs du document. - [laurent] Optimiser le code (nettoyage par ex. item status, logique des méthodes par ex. multiple iteration dans un serializer) ### En cours - [bertrand] Ré-écriture de l'initialisation des applications UI (Services: User, Settings, etc…). - [aly] Analyser le `invenio-stats` pour voir s'il peut être une solution pour `operation_logs` et `loan_history`. Si non, trouver une autre solution tout de suite. (Issue #1725 ouverte et planifiée pour la 1.2.0). Peut-on avoir une ressource représentée par un `table postgres` ou `elasticsearch` uniquement? créer un cas, et voir quels `modules` actuels peuvent être représentés par des tables DB. (par ex. operation logs, loan history) ### PO - [nicolas] Mise en place d'une instance test et pré-prod pour le go-live, idéalement début juin (4 clusters).