Development #29514
planitech : gestion des utilisateurs
0%
Description
De #29136 : "le réservant (non pris en compte)". Et pour cause on passe pour l'instant un contractorExternalIdentifier
fantaisiste.
Après un peu d'exploration de l'API et de la GUI Planitech voilà mon plan.
- restriction des démarches utilisant ce connecteur à des usagers connectés
- nouveau endpoint getorcreateuser qui passe en contractorExternalIdentifier l'uuid de l'utilisateur connecté (passé en paramètre de la requête), plus nom prénom mail.
- en interne ce endpoint tape dans un cache utilisateurs pour vérifier l'existence de l'utilisateur
- tout appel a createcreservation doit être précédé d'un appel getorcreateuser pour assurer l'existence de l'utilisateur dans planitech
- l'appel à createcreservation gagne un paramètre uuid qu'il positionne sur le contractorExternalIdentifier
Ça permettrait d'avoir un affichage bien propre dans Planitech, avec un utilisateur associé à chaque réservation, de croiser les infos Planitech Publik, et c'est pas bien compliqué.
Dans Planitech il y a de l'isolation au niveaux des utilisateurs : l'utilisateur technique (qui a les droits de connexion à l'API) ne voit que les utilisateurs métiers qu'il a créé lui même.
Le plan alternatif était d'avoir un utilisateur unique auquel Publik rattache toutes les réservations qu'il fait, moche, pas de recoupement avec Publik, etc ...
Fichiers
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
Idéalement on ne devrait pas passer l'identifiant Publik à Planitech mais utiliser un pseudonyme, soit un hash de l'uuid, soit générér un nouvel uuid et conserver dans un modèle le lien uuid Publik -> uuid Planitech.
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
- ne pas ajouter de nouveau endpoint
- avoir un modèle pour se souvenir de la création des utilisateurs
- passer systématiquement à createreservation nom, prénom, email, uuid; à charge pour ce endpoint de voir si l'utilisateur existe ou pas de l'autre coté (le modèle du point précédent devrait faciliter les choses) et d'en faire la création si besoin
Mis à jour par Emmanuel Cazenave il y a environ 5 ans
Benjamin Dauvergne a écrit :
Idéalement on ne devrait pas passer l'identifiant Publik à Planitech mais utiliser un pseudonyme, soit un hash de l'uuid, soit générér un nouvel uuid et conserver dans un modèle le lien uuid Publik -> uuid Planitech.
Pour des considérations de sećurité j'imagine ?
Pour la simplification du endpoint j'y avais pensé et j'hésite, si un autre client nous demande des créer toutes les réservations avec un utilisateur unique ou autre, il faudrait refaire ...
Mis à jour par Emmanuel Cazenave il y a environ 5 ans
- Fichier 0001-planitech-create-users-under-the-hood-29514.patch 0001-planitech-create-users-under-the-hood-29514.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
J'ai tout fait comme t'as dit Benj, c'est quand même bien plus commode d'utilisation.
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
- ajouter un index d'unicité sur (resource, name_id)
- réécrire ça:
+ try: + pairing = Pairing.objects.get(resource=self, name_id=post_data['name_id']) + except Pairing.DoesNotExist: + pairing = Pairing.objects.create( + resource=self, + name_id=post_data['name_id'], + external_id=uuid.uuid4().get_hex() + ) + params = { + "externalUserIdentifier": pairing.external_id, + "name": post_data['last_name'], + "firstName": post_data['first_name'], + "mail": post_data['email'] + } + try: + data = self._call_planitech(self.requests.post, 'createPerson', params) + if data.get('creationStatus') != 'OK': + raise APIError("Person creation failed: %s" % data.get('creationStatus')) + except APIError: + pairing.delete() + raise
en ça
+ with atomic(): + pairing, created = Pairing.objects.get_or_create(resource=self, name_id=post_data['name_id'], + defaults={'external_id': uuid.uuid4().get_hex()}) + if created: + params = { + "externalUserIdentifier": pairing.external_id, + "name": post_data['last_name'], + "firstName": post_data['first_name'], + "mail": post_data['email'] + } + data = self._call_planitech(self.requests.post, 'createPerson', params) + if data.get('creationStatus') != 'OK': + raise APIError("Person creation failed: %s" % data.get('creationStatus'))
On est sûr que des appels concurrents ne vont pas foirer, et le with atomic() devrait garantir qu'on ait un lock implicite sur la ligne, en gros soit on crée le truc et si l'appel à l'API marche ça reste, soit on récupère une ligne existante et ça implique que l'appel l'API a fonctionné (grâce à atomic).
Mis à jour par Emmanuel Cazenave il y a environ 5 ans
- Fichier 0001-planitech-create-users-under-the-hood-29514.patch 0001-planitech-create-users-under-the-hood-29514.patch ajouté
Yes beaucoup plus propre, merci (pourtant je connais atomic
, où avais-je la tête).
Et tant qu'à faire une deuxième contrainte unique_together
sur ('resource', 'external_id')
.
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
- Statut changé de Solution proposée à Solution validée
Emmanuel Cazenave a écrit :
Et tant qu'à faire une deuxième contrainte
unique_together
sur('resource', 'external_id')
.
Yep bonne idée, les contraintes en base ça me fait plaisir.
Ack.
Mis à jour par Emmanuel Cazenave il y a environ 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit bb8fee662b54718e72104c1ff3cea854ae9a2532 (HEAD -> master, origin/master, origin/HEAD) Author: Emmanuel Cazenave <ecazenave@entrouvert.com> Date: Wed Jan 9 17:25:01 2019 +0100 planitech: create users under the hood (#29514)
Mis à jour par Frédéric Péters il y a environ 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Statut changé de Solution déployée à Fermé
planitech: create users under the hood (#29514)