meeting-trigger-2020-03-05.md

@@ -4,30 +4,26 @@ on a des questions interessantes de telecomsudparis et de jonathan et moi sur le
 
 voici les tickets 
 
-\url{https://gitlab.opensides.be/telecomsudparis/Migration-FusionDirectory-OpenLDAP/issues/77}
+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.
-   * 
-
+   * 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
+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 :) ^^
+   * 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 ???)