feat(alert-cli): ajout des nouvelles contributions + correction pour les anciennes contributions #1150
Conversation
|
Kudos, SonarCloud Quality Gate passed!
|
| @@ -38,7 +38,7 @@ export const getContributionAnswerById = gql` | |||
| } | |||
| cdtn_references { | |||
| document { | |||
| cdtnId: cdtn_id | |||
| cdtn_id | |||
There was a problem hiding this comment.
Pourquoi ? 😢
c'est pas mal de transformer en camelcase dans le graphql pour éviter le snakecase dans le code.
There was a problem hiding this comment.
Je l'ai fait de la sorte pour plusieurs raisons :
- Pour la cohérence au niveau des données au sein de la même query. On est globalement sur du snake_case, c'est bizarre d'avoir un seul champ mappé manuellement de la sorte
- Il faudrait gérer cela directement au niveau d'Hasura, et non du code, comme ce qu'on a fait sur les messages blocks
- Dans le cas où on a pas le mapping côté Hasura, on envoie des données en snake_case et on récupère des données en camelCase
| contributions.forEach((contribution) => { | ||
| const kaliReferences = contribution.kali_references.map((ref) => ({ | ||
| dila_cid: ref.kali_article.cid, | ||
| dila_container_id: contribution.agreement.kali_id, |
There was a problem hiding this comment.
Tu ne récupères pas l'agreement sur la kali_reference dans la requête GraphQL, c'est normal ?
There was a problem hiding this comment.
D'ailleurs agreement n'est pas le typage, ça ne plante pas sur le type typescript ?
There was a problem hiding this comment.
L'agreement est référencé à deux endroits, donc autant prendre celui qui est à la racine, car la donnée est identique. En sachant que d'un point de vue métier les données sont identiques
fix #1139