Development #24573
Développer un connecteur D-Park
100%
Description
- creation d'un abonnement
- verification qu'une personne est déja abonnée
- appairage/desappairage
- notification de paiement
- envoie de pièces jointes
Révisions associées
misc test: fix make_resource import (#24573)
Historique
Mis à jour par Josué Kouka il y a presque 6 ans
- Tracker changé de Bug à Development
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
- appairage/desappairage
- verification d'adresse
- récuperation des informations d'abonnement
- recherche de d'abonnement
Mis à jour par Emmanuel Cazenave il y a presque 6 ans
A mettre dans contrib au lieu de apps parce qu'on est sur webservice atos one shot devant dpark non ?
Le modèle Pairing est bien seul pour l'instant, j'imagine pour plus tard donc surement à sortir de ce patch ...
A plusieurs endroits, tu renvoies des return {'data': {''result': False, 'reason': ... }} qui ne seront pas vu par wcs comme des erreurs applicatives si je ne m'abuse, c'est bien tout à fait voulu ? Pas mieux de lancer des APIError ?
Mis à jour par Josué Kouka il y a presque 6 ans
Emmanuel Cazenave a écrit :
A mettre dans contrib au lieu de apps parce qu'on est sur webservice atos one shot devant dpark non ?
Ok. (je pensais que ce serait la meme chose que pour Arles)
Le modèle
Pairingest bien seul pour l'instant, j'imagine pour plus tard donc surement à sortir de ce patch ...
C'est pour le stockage de l'appairage.
A plusieurs endroits, tu renvoies des
return {'data': {''result': False, 'reason': ... }}qui ne seront pas vu par wcs comme des erreurs applicatives si je ne m'abuse, c'est bien tout à fait voulu ? Pas mieux de lancer desAPIError?
C'est parce que ce sont des retours qui peuvent etre traités dans un workflow ou une cellule combo afin d'afficher un message explicite à l'usager. Dans le cas d'une demande de renouvellement d'abonnement par exemple les retours du ws peuvent etre:
1. la demande est bien prise en compte (True)
2. la demande est hors delai (False), on se base sur reason pour envoyer un message plus explicite
3. l'abonnement n'est plus valide (False) ...
C'est une exposition des réponses de la logique métier.
Mis à jour par Thomas Noël il y a presque 6 ans
Josué Kouka a écrit :
A plusieurs endroits, tu renvoies des
return {'data': {''result': False, 'reason': ... }}qui ne seront pas vu par wcs comme des erreurs applicatives si je ne m'abuse, c'est bien tout à fait voulu ? Pas mieux de lancer desAPIError?C'est parce que ce sont des retours qui peuvent etre traités dans un workflow ou une cellule combo afin d'afficher un message explicite à l'usager. Dans le cas d'une demande de renouvellement d'abonnement par exemple les retours du ws peuvent etre:
1. la demande est bien prise en compte (True)
2. la demande est hors delai (False), on se base surreasonpour envoyer un message plus explicite
3. l'abonnement n'est plus valide (False) ...
Mmmhh... je comprends pas cette réponse. On a le err:1 des APIError utilisable dans w.c.s. ou Combo ; selon moi y'a pas besoin de rajouter une nouvelle couche.
Mis à jour par Josué Kouka il y a presque 6 ans
Branche à jour en utilisant APIError pour tous les cas d'échec.
J'ai aussi mis le connecteur dans contrib.
Mis à jour par Emmanuel Cazenave il y a presque 6 ans
- Statut changé de Solution proposée à Solution validée
ok
Mis à jour par Josué Kouka il y a presque 6 ans
- Statut changé de Solution validée à Résolu (à déployer)
- % réalisé changé de 0 à 100
commit 3e775c0d07fb07fce87cd1e6ca28a8b162b59f2e (HEAD -> master, origin/master, origin/HEAD, wip/dpark_24573)
Author: Josue Kouka <jkouka@entrouvert.com>
Date: Fri Jun 15 15:07:44 2018 +0200
add DPark connector (#24573)
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Fermé
add DPark connector (#24573)