N'hésitez pas à ajoutez vos commentaires et questions sur cette page.

== Compte-rendu visio 28 nov 2006 ==

Nous avons fait une petite visio rapide : ThomasNoël, JérômeSantini, JeanChristopheAndré, OusmaneWilane (et ZoserBiziki en modérateur ;) ). Ce qu'il en ressort :

 * la notion noyau + plugin semble ok pour tout le monde, notamment le fait que le noyau informera les plugin de tout évenement sur la base (les plugins devront réagir en fonction)
 * applications "métier" à étudier : authentification (NSS, Samba), postfix
 * application métier plus lourde : gestion des commandes de doc primaires. A priori pas trop de soucis car les plugins pourraient être des applis Django (JC nous fournira un accès à son système pour qu'Ousmane voit mieux l'engin)
 * il faut étudier les possibilités "poussées" du coté de la personnalisation du module Admin de Django, afin de voir si on peut un peu améliorer l'ergonomie : définir des mockups pour cela
 * replication des bases : il faut qu'on puisse extraire les infos d'un site afin de les envoyer dans un autre. Tout le monde est ok pour des login du type "login@implantation2" lorsque le login provient d'une base "externe". Il reste à étudier les implications diverses de tout cela au niveau des plugins notamment.
 * interfaces "publiques" : 
  * pour tout ce qui est stat & co : templates Django (il faudra éventuellement API-ser coté Django pour aider à la programmation de ces templates)
  * les utilisateurs devront pouvoir modifier (au moins) leur mot de passe et leur nom_complet

== Compte-rendu visio 5 déc 2006 ==

Nouvelle petite visio rapide : ThomasNoël, JérômeSantini, JeanChristopheAndré, OusmaneWilane.

La discussion a porté sur les soucis de véritication de cohérence entre le noyau et les plugins, ainsi que la cohérence intra-plugin (ouaahh).

 * les plugin doivent informer le noyau en cas de soucis : Ousmane va étudier le fait que les plugin puissent lever des exception
 * quand le noyau reçoit une exception (erreur) en provenance d'un plugin, il renseigne une table "plantages". Le noyau enregistre cependant ses données (par exemple l'utilisateur sera bien créé au niveau du noyau)
 * la table plantage permet ensuite de savoir si un objet noyau a eu des soucis lors de sa gestion par un plugin. Dans ce cas, on pourra relancer la création/modification de l'utilisateur en appelant le/les plugins qui a/ont planté (ou tous les plugin, pour aller plus vite)
 * lorsqu'un utilisateur sera affiché, s'il existe un warning au niveau de la table "plantage", alors un bandeau rouge s'affichera sur la page d'admin qui dira que cet utilisateur n'est pas "fonctionnel"
 * la table "plantage" pourra également être considérée comme une liste d'attente des soucis à régler

Les plugin doivent donc tous proposer une methode "synchro" afin de re-synchroniser un objet du noyau (utilsiateur, groupe, abonnement, etc). 

Cette méthode dans chaque plugin permettra également d'ajouter un plugin en cours de route : lors de son ajout, on déclenchera la synchro sur tous les objets noyau pour qu'ils soient tous prise en compte par le plugin.

Les plugin pourraient éventuellement proposer une méthode "vérification" (sans action de correction) afin de pouvoir faire un "check" de la cohérence... à étudier.


Si on arrive à mettre en place cette technique, on aura un truc beaucoup plus robuste.


== Autres idées ==

Extraites des anciennes discussions :

  * Sebastien est tombé sur http://www.zbyte64.com/code.shtml . Ca serait bien d'export certaines choses directement en format Open Document.
  * Il serait sans doute intéressant d'avoir un module d'exportation MySQL adaptable pour permettre de faire la synchronisation entre différentes bases MySQL. Dans le cas d'un CNF avec une base d'authentification MySQL et une base PMB par exemple : chercher ce qu'est PMB (voir avec Sebastien Dornanon, Port Vila)