|
|
|
Hello,
|
|
|
|
|
|
|
|
on a des questions interessantes de telecomsudparis et de jonathan et moi sur les triggers, on va faire une reunion demain matin sur ce sujet
|
|
|
|
|
|
|
|
voici les tickets
|
|
|
|
|
|
|
|
\url{https://gitlab.opensides.be/telecomsudparis/Migration-FusionDirectory-OpenLDAP/issues/77}
|
|
|
|
|
|
|
|
* J’aurai tendance à voir ça comme externe à FD, dans son trigger il peut en fonction du cas faire l’action qu’il souhaite (y compris planifier une tâche dans un truc de gestion de tâches différées). J’ai ptet pas compris le besoin.
|
|
|
|
* Idem, si ça doit etre un batch d'info (ou info déjà rentré) je dirais plus un sysème de cron que par FD si c'est une modification qui se fait a une certaine date, il peut faire un trigger qui le fait que pour cette info en vérifiant la date si besoin.
|
|
|
|
*
|
|
|
|
|
|
|
|
* le probleme est du a nos trigger synchrone, je pense au webservice mais restera comment declencher a une date
|
|
|
|
*
|
|
|
|
|
|
|
|
* FD par définition ne peut pas lancer des trucs à des dates précises, en tant qu’appli web.
|
|
|
|
* C’est pour ça que pour moi c’est pas le boulot d’FD ce qu’il demande ya plein d’outils qui font déjà ça, c’est arrivé qu’on en fasse des sur-mesures pour des trucs précis.
|
|
|
|
*
|
|
|
|
|
|
|
|
* Je suis assez d'accord sur la définition même du trigger, c'est d'être lancé suite à une action si c'est du différé il pourrait très bien faire un crontab sur la machine FD qui utilise le même script du trigger par exemple (il devra juste recupéré les attribut passé manuellement, mais je vois aucun cas ou ça devrait être différé avec des informations qu'on passe)
|
|
|
|
*
|
|
|
|
|
|
|
|
* on pourrait imaginer un scheduler en php mais c'est pas a l'ordre du jour
|
|
|
|
\url{https://gitlab.opensides.be/telecomsudparis/Migration-FusionDirectory-OpenLDAP/issues/76}
|
|
|
|
|
|
|
|
* L’idée c’est de pouvoir désactiver un trigger temporairement?oui
|
|
|
|
* Ce serait plus trop des trigger du coup, y faudrait soit ajouté un état "actif/pas actif" ou alors voir le besoin exacte (par exemple si ça doit etre activer en fonction d'autre chose)
|
|
|
|
* dans leur cas il vont avoir des trigger mais qui ne seront utilise que dans des contexte de rentree scoalire ou autre, ou alors ils voudront en desactiver certains pour test ou autre je pense que c'est une fonctionalite interessante de pouvoir desactiver temporairement certains triggers sans devoir les effacer
|
|
|
|
* Un statut par trigger me semble le plus simple à faire, je sais pas ce qu t'en penses mcmic si niveau code c'est facilement faisable sans devoir tout casser?c'est ca que je veux :) ^^
|
|
|
|
* Faut voir a priori il suffit d’ajouter l’info d’une manière ou d’une autre dans le hook, a priori un champ en plus à la fin (actuellement ça stock tab|mode|command, on passerait à tab|mode|active|command ptet? Je voudrais laisser la possiblité d’avoir des | dans la commande, à voir.)ok je ferait un ticket
|
|
|
|
Reflexion benoit et jonathan
|
|
|
|
|
|
|
|
- Appliquer par ordre alphabétique (par tab ???)
|
|
|
|
- Pas de suivi de hook (si hook 1 échoue, hook 2 est quand même fait) => meme avec nbCheckErrors
|
|
|
|
|
|
|
|
* Les deux questions sont très liées, les triggers sont indépendants puisqu’ils n’ont pas d’ordre défini.
|
|
|
|
* Pour moi, si vous avez 2 tâches qui sont dépendantes (elles ont un ordre, ou l’une doit tourner que si l’autre réussit, …), il faut les lancer depuis le même trigger.
|
|
|
|
* Le souci est que ça risque de faire des duplications ou chose très lourdes, dans notre cas on créait le compte gitlab et ensuite on envoyait un mail. On peut mettre les 2 ensembles mais on perd toute l'idée de spliter les actions. (On pourrait suremet les lancer sous la forme ./script1.sh \&\& ./script2.sh aussi mais ça me semble un peu moche, mais a tester peut être).
|
|
|
|
* Tu peux organiser ton code comme tu veux tant que tu sors une commande à lancer pour FD, ça me choque pas du tout d’avoir un script user-post-hook.sh qui lance create-gitlab-stuff.sh et si ça marche send-mail-info.sh.
|
|
|
|
* Faudra juste le précise en doc ça me sembe pas déraisonnable non plus mais juste a précisé (l'ordre d'affichage est alphabetique je crois du coup ce sera l'ordre afficher ^^)pour moi ca represente un probleme fonctionel et ca casse un partie de la puissance de fd, obliger les gens retourner en shell pour faire tourner deux trigger interdependant est contre productif (user mode speaking)
|
|
|
|
Les triggers sont par définition des scripts (shell ou autre).
|
|
|
|
On peut commencer à rajouter des questions d’ordre et compagnie mais c’est un puit sans fond les possibilité de dépendances interscript sont immenses ça me parait bien plus sérieux de mettre un seul trigger qui peut agencer les choses comme il le souhaite.
|
|
|
|
|
|
|
|
Est-ce que quelque chose comme "truc.sh \&\& truc1.sh" fonctionnerait dans fd?
|
|
|
|
Je suis pas sûr, à tester mais pour moi ça reste moins clean qu’un script qui documente bien ce qu’il fait
|
|
|
|
|
|
|
|
il y a deja le probleme du passages des erreurs d'un trigger a l'autre mais je vais mettre un exemple en dessous pour expliciter le probleme
|
|
|
|
|
|
|
|
Le passage d'erreur d'un hook pourrait être interessant je penses, par exemple si on un hook sur user en cas d'erreur on a quelque chose de similaire a nbError qui peut etre tester pour dans un autre hook qui est sur le même type d'objet (mais c'est peut-être plus complexe que nbError du coup).
|
|
|
|
|
|
|
|
Je ne comprends pas l’intérêt de mettre plusieurs trigger sur le même couple objet/situation, pour moi FD pourrait même l’interdire. (en tous cas ça me choque pas que dans ce cas ils soient considérés indépendants et pas ordonnés)
|
|
|
|
|
|
|
|
Ca permettrait d'avoir une solution pour pas devoir faire un script séparé et de joué sur les nom et les erreur comme on peut le faire avec le nbError de fd pour vérifier si tout sait bien passé.
|
|
|
|
|
|
|
|
Par exemple je penserais a un truc du genre
|
|
|
|
|
|
|
|
1-creation-compte-gitlab.sh %nbErrorHook%
|
|
|
|
2-envoi-de-mail %nbErrorHook%
|
|
|
|
|
|
|
|
On pourrait vérifier si nbErrorHook vaut 0 (si on peut passer un tab en string on pourrait meme faire nbErrorHook["user"] pour avoir le type concerné par exemple)
|
|
|
|
|
|
|
|
Ah tu parles d’autre chose là c’est des hooks sur des onglets différents qui doivent interagir?
|
|
|
|
|
|
|
|
Non non les 2 sur les users, je me dis juste que ça peut etre plus dificile de gerer le nbErrorHook par type du coup même un tableau pour chaque type de hook ça reste bien aussi. Mais ça pourrait service pour d'autres cas sans souci du coup.
|
|
|
|
|
|
|
|
- Message d'erreur hook affiché meme si désactiver
|
|
|
|
|
|
|
|
* Pas clair, quel message d’erreur, quand quoi est désactivé?
|
|
|
|
* A voir si c'est toujours le cas, il me semble que c'était quand on demandait pas de debug pour le hook mais qu'il l'affichait quand meme.- Message de reussite / création dans le form en cas d'erreur (ou popup)
|
|
|
|
|
|
|
|
* Vous avez un message de réussite alors qu’il y a une erreur?
|
|
|
|
* C'était pour register ou on créer le compte et on avait "inscription réussi" et puis le popup d'erreur surement car on avait en premier le checkhook d'envoi de mail et puis le checkhook de création du compte gitlab qui faisait une erreur. Ca me semble assiez lié à la question sur le suivi des hooks (si un ou l'autre échoue etc)
|
|
|
|
- Message d'erreur (pour hook) imbuvable
|
|
|
|
=> filtrage du message d'erreur
|
|
|
|
|
|
|
|
* Normalement c’est vous qui écrivez l’erreur que vous voulez dans le trigger non?
|
|
|
|
* Pour cette question et les deux au dessus c’est très dépendant du type de trigger, si c’est du check c’est fait pour pouvoir bloquer la sauvegarde avec une message d’erreur clair, si c’est du post c’est en théorie pas interactif, sauf erreur inattendue.
|
|
|
|
* C'était du check mais avant la réecriture de la gestion des erreurs, il me semble que maintenant ça va cette partie la.
|
|
|
|
*
|
|
|
|
#Interactions entre les triggers et le workflow de sauvegarde
|
|
|
|
|
|
|
|
##Check
|
|
|
|
Les checkhooks sont lancés dans la phase de check, c’est celle qui vérifie que le champ mail contient bien un email, etc…
|
|
|
|
Ils sont lancés même si d’autres checks échouent, mais ils peuvent utiliser nbCheckErrors pour savoir si d’autres erreurs sont survenues.
|
|
|
|
Ils peuvent afficher un message d’erreur s’ils détectent une erreur, en affichant ça sur stdout (de mémoire)
|
|
|
|
Si ils sortent une erreur, la sauvegarde est interrompue comme par tout autre check échoué.
|
|
|
|
Note: Quand ils sortent une erreur de validation pour l’utilisateur, ils ne doivent pas donner un code d’erreur, s’il donne un code d’erreur celui-ci est affiché puisque c’est considéré comme un crash/bug.
|
|
|
|
|
|
|
|
##Pre
|
|
|
|
|
|
|
|
* Les pre hook sont lancés avant la sauvegarde dans le LDAP.
|
|
|
|
* Si ils échouent (code d’erreur) la sauvegarde est annulée.
|
|
|
|
*
|
|
|
|
##Post
|
|
|
|
|
|
|
|
* Les post hook sont lancés après la sauvegarde dans le LDAP
|
|
|
|
* Si ils échouent (code d’erreur), l’erreur est affichée mais la sauvegarde ne peut plus être annulée.
|
|
|
|
* Je suppose que le cas où vous aviez un formulaire réussit + un message d’erreur c’était un post hook.
|
|
|
|
* On pouvait reproduire avec le check aussi il me semble, mais c'est vrai que je suis plus 100% sur
|
|
|
|
|
|
|
|
nos cas utilisation des onglet user, samba, supann, supannresourceetatdate
|
|
|
|
|
