---
# System prepended metadata

title: Stabilisation du projet RERO-ILS

---

# 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).
