Report des contrôles inputs & métiers du legacy concernant le endpoint /modules

[Lucas-C]

TDD:

• se baser sur le code & les tests legacy pour créer des BDDs testant ces contrôles
• les implémenter

[Lucas-C]

BDDs ajoutés :

  Scenario: forbid creation of a module with a same name but different letter case
    Given an existing module
    And a module to create with the same name and version but different case
    When I try to create this module
    Then the module creation is rejected with a conflict error

  Scenario: get the detail of an existing module with the wrong letter case
    Given an existing module
    When I get the module detail with the wrong letter case
    Then the module detail is successfully retrieved

[Lucas-C]

BDD ajouté dans get-modules.feature :

Scenario: get the detail of an existing module with the wrong letter case
Given an existing module
When I get the module detail with the wrong letter case
Then the module detail is successfully retrieved

[Lucas-C]

Je travaille à implémenter le LADR suivant:

# Casse des identifiants dans l'API REST

Voici les règles en vigueur en termes de casse des identifants (d'application, module, template...) :
- lors de création (`POST`) d'entités, Hesperides est **sensible** à la casse,
mais interdit la création d'entité ayant un nom identique mais une casse différente
- lors de consultation (`GET`), modification (`PUT`) ou suppression (`DELETE`) d'entités, Hesperides est **insensible** à la casse.

J'ai tenté de transfomer les queries dans MongoModuleRepository afin qu'elles ignorent la casse du nom de module. Néanmoins:

• ça impacte beaucoup de code (quasi-toutes les méthodes de cette classe)
• j'ai eu des difficultés à l'implémenter car :
  • FakeMongo ne supporte pas les suffixes IgnoreCase & AllIgnoreCase cf. Feature request: support for IgnoreCase & IgnoreCaseAll SpringData methods fakemongo/fongo#363
  • combiner une expression SPeL et le filtre $regex est source de bugs: cf. https://jira.spring.io/browse/DATAMONGO-2119

Donc je cherche désormais à rendre l'index insensible à la casse, ce qui est possible avec MongoDB: https://docs.mongodb.com/manual/core/index-case-insensitive/

[Lucas-C]

Le support des "collation" qui offrent cette fonctionnalité n'est disponible qu'à partir de la v2.0.0.M3 de Spring ... cf. spring-projects/spring-data-mongodb@0b169d5 :(

[Lucas-C]

On en reparle la semaine prochaine avec l'équipe, mais voilà nos options à ce stade :

• passer en Spring Boot 2 + Axon 3.4 (pas très sec) pour avoir le support des collations et donc des indexs insensibles à la casse
• contribuer à FakeMongo pour y ajouter le support des méthodes IgnoreCase. D'après ce que j'en comprends, côté SpringData l'implémentation s'est faite avec une $regex: DATAMONGO-770 - Add support for case-insensitive queries. spring-projects/spring-data-mongodb#78
• se passer des méthodes auto-générées de SpringData et faire des requêtes explicites en Java avec $regex
• ajouter un champ supplémentaire moduleNameLowercase à nos documents qui servira de clef mais permet de conserver le champ avec la casse respectée en parallèle

[Lucas-C]

Histoire de ne chasser qu'un lièvre à la fois, et comme convenu en daily, ce sujet est déporté ici : #371

Je vais déjà terminer la vérification des autres contrôles effectués par le legacy

[Lucas-C]

Vérifications des contrôles d'input faits sur l'API /modules:

• POST /modules
  • cas où query params manquants/vides, mais pas tous -> lève une IllegalArgumentException
    • BDD: ajouté dans copy-modules.feature
    • report contrôle: déjà présent
• PUT /modules: pas de contrôles
• GET /modules : pas de contrôles
• GET /modules/{module_name}: pas de contrôles cf. note [1]
• GET /modules/{module_name}/{module_version} : pas de contrôles cf. note [1]
• GET /modules/{module_name}/{module_version}/{module_type}
  • une erreur MissingResourceException(moduleType + " is not a valid module type. Choose either workingcopy or release") est levée en cas de module_type invalide
    • BDD: ajouté dans get-modules.feature
    • report contrôle: déjà présent mais code d'erreur différent : 400 au lieu de 404 → pas grave
• DELETE /modules/{module_name}/{module_version}/release : pas de contrôles cf. note [1]
• GET /modules/{module_name}/{module_version}/release/model : pas de contrôles cf. note [1]
• GET /modules/{module_name}/{module_version}/release/templates : pas de contrôles cf. note [1]
• GET /modules/{module_name}/{module_version}/release/templates/{template_name} : pas de contrôles cf. note [1]
• DELETE /modules/{module_name}/{module_version}/workingcopy : pas de contrôles cf. note [1]
• GET /modules/{module_name}/{module_version}/workingcopy/model : pas de contrôles cf. note [1]
• POST /modules/{module_name}/{module_version}/workingcopy/templates: je ne rajoute pas de tests validant le comportement en cas de "body" invalide → l'intérêt est faible, et ça demanderait un important "refactoring" dans org.hesperides.tests.bdd.modules.ModuleClient
• PUT /modules/{module_name}/{module_version}/workingcopy/templates : idem
• GET /modules/{module_name}/{module_version}/workingcopy/templates : pas de contrôles cf. note [1]
• DELETE /modules/{module_name}/{module_version}/workingcopy/templates/{template_name}
  • MissingResourceException("Parent module not found") peut être levé
    • BDD: présent dans templates/delete-module-templates.feature
    • report contrôle: déjà présent
• GET /modules/{module_name}/{module_version}/workingcopy/templates/{template_name} : pas de contrôles cf. note [1]
• POST /modules/create_release
  • cas où module_name / module_version manquant -> lève une IllegalArgumentException
    • BDD: 2 ajoutés dans release-modules.feature
    • report contrôle: ajouté
• POST /modules/perform_search
  • IllegalArgumentExceptionlevée en cas de query param terms vide ou manquant
    • BDD: ajouté dans search-modules.feature
    • report contrôle: ajouté
• POST /modules/search -> ressource non reportée dans nouvelle version

Note [1] : pour beaucoup de ressources, en théorie des IllegalArgumentException pourraient être levées en cas de @PathParam vides dans le code legacy (via l'appel checkQueryParameterNotEmpty), mais en pratique d'après mes tests c'est impossible :

• /rest/modules/ est équivalent à /rest/modules (sans slash)
• pareil pour /rest/modules/ (avec un espace à la fin de l'URL)
• /rest/modules// lève une erreur 500 NotFoundException -> idem sur v3

Le mapping des exceptions était le suivant :

• IllegalArgumentException -> HTTP 400 : OK, reporté
• MissingResourceException -> HTTP 404 : OK, transformé en ModuleNotFoundException -> HTTP 404 via classe parente

[Lucas-C]

RAF: partie "contrôles métiers", avec par exemple ce cas:
https://github.com/voyages-sncf-technologies/hesperides/blob/fix/3.0.3/src/main/java/com/vsct/dt/hesperides/templating/modules/event/ModuleDeletedCommand.java#L48
(vérifier que les templates sont bien supprimés avec le module)

[Lucas-C]

Vérifications des contrôles métiers faites sur l'API /modules:

• POST /modules
  • cas "from" -> MissingResourceException si module non trouvé
    • BDD: présent dans copy-modules.feature
    • report contrôle: déjà présent
  • DuplicateResourceException si module existe déjà
    • BDD: 2 présent dans create-modules.feature & copy-modules.feature
    • report contrôle: déjà présent
• PUT /modules
  • peut lever une erreur MissingResourceException("Cannot update because module working copy %s does not exists")
    • BDD: présent dans update-modules.feature
    • report contrôle: déjà présent
  • peut lever des IncoherentVersionException / OutOfDateVersionException (HTTP 412) : rassemblés en OutOfDateVersionException associé au code HTTP 409
    • BDD: présent dans update-modules.feature
    • report contrôle: déjà présent
• GET /modules : pas de contrôles métier
• GET /modules/{module_name} : pas de contrôles métier
• GET /modules/{module_name}/{module_version} : pas de contrôles métier
• GET /modules/{module_name}/{module_version}/{module_type} : pas de contrôles métier
  • peut lever une erreur MissingResourceException("Could not find module info for " + moduleKey)
    • BDD: présent dans get-modules.feature
    • report contrôle: déjà présent
• DELETE /modules/{module_name}/{module_version}/release
  • peut lever une erreur MissingResourceException(moduleKey + " does not exist")
    • BDD: présent dans delete-modules.feature
    • report contrôle: déjà présent
• GET /modules/{module_name}/{module_version}/release/model : pas de contrôles métier
• GET /modules/{module_name}/{module_version}/release/templates : pas de contrôles métier
• GET /modules/{module_name}/{module_version}/release/templates/{template_name}
  • peut lever une MissingResourceException("Could not find template...")
    • report contrôle : déjà présent
• DELETE /modules/{module_name}/{module_version}/workingcopy : pas de contrôles métier
• GET /modules/{module_name}/{module_version}/workingcopy/model : pas de contrôles métier
• POST /modules/{module_name}/{module_version}/workingcopy/templates
  • peut lever un DuplicateResourceException("Cannot create template " + templateData + " because it already exists")
    • BDD: ajouté dans create-module-templates.feature
    • report contrôle : déjà présent
• PUT /modules/{module_name}/{module_version}/workingcopy/templates
  • peut lever une MissingResourceException("Cannot update template " + templateData + " because it does not exists")
    • BDD: présent dans update-module-templates.feature
    • report contrôle : déjà présent
• GET /modules/{module_name}/{module_version}/workingcopy/templates : pas de contrôles métier
• DELETE /modules/{module_name}/{module_version}/workingcopy/templates/{template_name}
  • peut lever une MissingResourceException("Impossible to delete template %s because it does not exist")
    • BDD: présent dans delete-module-templates.feature
    • report contrôle : déjà présent
• GET /modules/{module_name}/{module_version}/workingcopy/templates/{template_name}
  • peut lever une MissingResourceException("Could not find template...")
    +BDD présent dans get-module-templates.feature
    • report contrôle : déjà présent
• POST /modules/create_release
  • peut lever une erreur MissingResourceException("There is no module " + fromModuleKey + " to build " + newModuleKey)
    • BDD: présent dans release-modules.feature
    • report contrôle : déjà présent
  • peut lever un DuplicateResourceException("Module " + newModuleKey + " already exists")
    • BDD: ajouté dans release-modules.feature
    • report contrôle: déjà présent
• POST /modules/perform_search : pas de contrôles métier