Projet

Général

Profil

Development #27814

Maarch: implémenter un WS pour envoyer une réponse

Ajouté par Benjamin Dauvergne il y a plus de 5 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
07 novembre 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Sur base du WS Maarch "updateStatus".


Fichiers

Révisions associées

Révision 10c16a0b (diff)
Ajouté par Benjamin Dauvergne il y a plus de 5 ans

maarch: add a webservice for sending a mail response (#27814)

POST /api/mail/response/
{"mail_id": 1234, "content": "response text content"}

Historique

#2

Mis à jour par Pierre Cros il y a plus de 5 ans

  • Statut changé de Nouveau à Rejeté

C'est depuis w.c.s. que l'envoi doit être fait

#3

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

  • Statut changé de Rejeté à Nouveau
#4

Mis à jour par Frédéric Péters il y a plus de 5 ans

Je lis entre les lignes pour ne pas jouer aux statuts, il y aurait appel d'un webservice par w.c.s., ce webservice serait implémenté dans Welco, qui dispose déjà de code et cie pour se connecter à Maarch.

#5

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

Avec un test, qui passe.

#6

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

Ça s'appelle ainsi:

  • URL : {{welco_url}}api/mail/response/
  • Paramètres JSON :
    • mail_id : form_submission_context_external_id (pas sûr du nom de la variable)
    • content : le contenu qu'on souhaite voir dans historyMessage sur Maarch
#7

Mis à jour par Frédéric Péters il y a plus de 5 ans

'djangorestframework>=3.3, <3.4',

La limitation <3.4 est justifiée par quoi ? (côté chrono on a < 3.7, pour encore tourner en 1.8)

Je serais pour garder les erreurs 500 à de l'imprévu.

Ça a été testé avec Publik ? (je pense surtout à la signature automatique des appels qui peut avoir lieu)

#8

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

Je vais tester avec 3.7, j'ai pris la ligne du setup.py de combo qui elle même devait venir initialement d'authentic.

Non pas testé avec Publik, je compte sur la configuration de REST_FRAMEWORK['DEFAULT_AUTHENTICATION_CLASSES'] venant de debian_config_common.py pour faire le job, à ma connaissance on ne teste pas nos APIs avec Publik, si je prends chrono en exemple.

#9

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

Voilà:
  • rest_framework <3.7
  • erreurs 500 retirés
  • plus de tests sur les cas d'erreur
#10

Mis à jour par Frédéric Péters il y a plus de 5 ans

à ma connaissance on ne teste pas nos APIs avec Publik, si je prends chrono en exemple.

Je ne parle pas de test automatisé, juste en local, tester de bout en bout.

#11

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

Frédéric Péters a écrit :

à ma connaissance on ne teste pas nos APIs avec Publik, si je prends chrono en exemple.

Je ne parle pas de test automatisé, juste en local, tester de bout en bout.

Ah, j'ai pas Publik en local.

#13

Mis à jour par Serghei Mihai il y a plus de 5 ans

Benjamin Dauvergne a écrit :

Non pas testé avec Publik, je compte sur la configuration de REST_FRAMEWORK['DEFAULT_AUTHENTICATION_CLASSES'] venant de debian_config_common.py pour faire le job, à ma connaissance on ne teste pas nos APIs avec Publik, si je prends chrono en exemple.

Pour qu'elle s'applique il faut rajouter 'rest_framework' dans installed_apps.

Testé en local et ça fonctionne.

#15

Mis à jour par Serghei Mihai il y a plus de 5 ans

  • Statut changé de Solution proposée à Solution validée
#16

Mis à jour par Benjamin Dauvergne il y a plus de 5 ans

  • Statut changé de Solution validée à Résolu (à déployer)

Voilà poussé taggé.

#17

Mis à jour par Frédéric Péters il y a plus de 5 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF