Development #48010
journal : journaliser les appels aux APIs
0%
Description
Au minimum création, mise à jour et suppression des utilisateurs et des rôles.
Fichiers
Révisions associées
Historique
Mis à jour par Valentin Deniaud il y a presque 3 ans
- Fichier 0001-wip.patch 0001-wip.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
J'ai fait ça mais il y a quand même une grosse similitude entre évènements manager.* et ces nouveaux évènements api.*, est-ce qu'il ne vaudrait pas mieux ajouter un booléen « api » au modèle Event et faire varier l'affichage sur cette base ? Ou je continue sur ma lancée ?
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
Valentin Deniaud a écrit :
J'ai fait ça mais il y a quand même une grosse similitude entre évènements manager.* et ces nouveaux évènements api.*, est-ce qu'il ne vaudrait pas mieux ajouter un booléen « api » au modèle Event et faire varier l'affichage sur cette base ? Ou je continue sur ma lancée ?
Ça me va bien que les évènements backoffice recouvrent aussi l'API.
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
- Statut changé de Solution proposée à En cours
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
Attention quand même coté API on peut avoir des utilisateurs à l'origine des actions (et là ça ressemble au BO au niveau modèle, event.user correspond à l'auteur de l'action) mais aussi des services voir authentic2/authentication.py pour la class d'authentification pour DRF qui gère ça.
Mis à jour par Valentin Deniaud il y a presque 3 ans
- Fichier 0001-api-record-actions-in-journal-48010.patch 0001-api-record-actions-in-journal-48010.patch ajouté
- Statut changé de En cours à Solution proposée
Revoici en réutilisant les évènement manager.
Pour les différencier dans l'interface, je réutilise la colonne Session pour lui faire dire « API », puisqu'elle serait toujours vide sinon. Ça me paraît assez compréhensible.
Benjamin Dauvergne a écrit :
Attention quand même coté API on peut avoir des utilisateurs à l'origine des actions (et là ça ressemble au BO au niveau modèle, event.user correspond à l'auteur de l'action) mais aussi des services voir authentic2/authentication.py pour la class d'authentification pour DRF qui gère ça.
Dans ce cas là je ne m'embête pas et je mets l'utilisateur à None, je pense que c'est compliqué de faire mieux.
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
- Statut changé de Solution proposée à Solution validée
Je ne pense pas utile d'ajouter une colonne booléenne (api) qui sera globalement vide et dont on peut déjà déduire la valeur; ne mettons rien, si on a pas l'origine ça ne sert pas tellement non plus, on verra plus tard.
Mis à jour par Valentin Deniaud il y a presque 3 ans
Benjamin Dauvergne a écrit :
Je ne pense pas utile d'ajouter une colonne booléenne (
api) qui sera globalement vide et dont on peut déjà déduire la valeur; ne mettons rien, si on a pas l'origine ça ne sert pas tellement non plus, on verra plus tard.
Déduire la valeur en affichant « API » si user et session sont vides ? Ça ne va pas bien rendre dans le cas de l'évènement de désactivation auto LDAP.
On s'appuie également sur ce flag pour la recherche.
Mis à jour par Benjamin Dauvergne il y a presque 3 ans
Bon ok, mais il y a un truc qui ne me plaît pas (je pense que c'est l'absence de sujet, si on avait un objet User associé au service qu'on puisse mettre dans la colonne user_id, on aurait pas besoin du flag API on chercherait directement les appels fait par tel ou tel service, gardons ça en mémoire quand on voudra sauvegarder le responsable d'un évènement).
Mis à jour par Valentin Deniaud il y a presque 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 78b07aa49792763a5a2005643e6bafd330671231
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date: Wed May 19 17:29:38 2021 +0200
api: record actions in journal (#48010)Mis à jour par Frédéric Péters il y a presque 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api: record actions in journal (#48010)