Modifications entre les versions 31 et 49 (s'étendant sur 18 versions)
⇤ ← Version 31 à la date du 2006-11-10 16:28:30 →
Taille: 20925
Éditeur: SebastienLanteigne
Commentaire:
← Version 49 à la date du 2006-12-15 15:32:07 → ⇥
Taille: 4042
Éditeur: JérômeSantini
Commentaire: lien vers la page greffon postfix
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI) Ce projet a pour but d'écrire un système gestion des utilisateurs d'une implantations AUF (CNF, CAI, bureau, antenne... ou toute autre implantation où il y a des utilisateurs).
Ligne 3: Ligne 3:
 * Responsable : SebastienLanteigne
 * Participants : JeanChristopheAndré, SebastienDornano, ThomasNoël, CédricProtière, JérômeSantini... ''et tout le monde intéressé !''		  * Responsable : ThomasNoël
 * Développeur principal : OusmaneWilane
 * Participants : JeanChristopheAndré, JérômeSantini, SebastienLanteigne... ''et tout le monde intéressé !''
Ligne 8: Ligne 9:
= Discussions, propositions =

 On peut parler ici : ["/Discussion"]
Ligne 14: Ligne 12:
 . '''Objectifs du projet''' : unifier nos systèmes d'authentification et nos outils de suivi des utilisateurs des CNF[[FootNote(Il serait même envisageable d'utiliser ce système sur n'importe quel serveur gérant un ensemble d'utilisateurs, à condition que le noyau dur des fonctionnalités soit le plus léger possible.)]] ;  . '''Objectifs du projet''' : unifier nos systèmes d'authentification et nos outils de suivi des utilisateurs des implantations AUF ;
Ligne 20: Ligne 18:
= Idées générales = Lire aussi la sous-page sur l'[:/Besoins: expression des besoins] qui présente quelques autres aspects. Ajoutez-y vos demandes.

= Le quotidien du projet =

 * Le développement du code de l'application se passe sur un Trac/Subversion ici : http://trac.sn.auf.org/guia (serveur hébergé à Dakar avec parfois quelques soucis de routage ou d'électricité en ce moment).
 * Les discussions ont lieu sur la sous-page ["/Discussion"]

= Vue générale =
Ligne 24: Ligne 29:
 Une base de données:: elle décrit l'ensemble des utilisateurs et des abonnements associés. Elle doit avoir un schéma de base simple, correspondant au noyau dur du système, mais également autoriser une intégration simple de modules d'extension.  Le noyau:: il s'agit d'une base de donnée et un ensemble de fonctions permettant d'y accéder.
  * la base de données décrit l'ensemble des utilisateurs et des abonnements associés. Elle a un schéma de base simple, correspondant au noyau dur du système. Elle autorise une intégration simple de modules d'extension (greffons) via des champs ''extra'' sur ses objets. Voir /SchemaBase.
  * l'accès à la base est écrit en Python/Django. Chaque objet de la base est donc visible sous la forme d'un objet Python disposant de méthodes permettant de le gérer. L'appel à ces méthodes effectue les actions nécessaires sur la base de données. Là encore, chaque méthode peut être surchargée par des greffons.
 
 Des interfaces::
  * dans un premier temps une interface Web, rapide et ergonomique, permettant d'effectuer des actions sur la base. Django fourni une interface d'administration calculée automatiquement à partir de la définition des objets. Il faut la faire un peu évoluer pour la rendre plus ergonomique.
  * puisqu'il est écrit en Django, le noyau est accessible directement en Python. D'autres interfaces sont donc programmables, telle qu'une interface en ligne de commande.
Ligne 26: Ligne 37:
 Un moteur de gestion:: de quoi remplir et gérer cette base de données, notamment :
  1. une interface Web, rapide et ergonomique
  1. une interface en ligne de commande pour permettre une gestion « système »
  1. --(plus tard, une application native pour Gnome ou KDE)--[[FootNote(La tendance est à l'inverse, c'est à dire la migration de tous les outils vers des technologies web, et je doute qu'il y ait un retour en arrière de si tôt !)]]
 Cette application sera adaptable en fonction des contraintes locales. Par exemple elle sera capable, via des extensions (surcharges), de synchroniser les données avec d'autres systèmes (authentification, messagerie, etc.).		  Des greffons (modules d'extension, ''plug-ins''):: ils sont chargés, à partir d'informations fournies par le noyau, de gérer les aspects «métier», par exemple :
  * vers une base de données MySQL d'authentification (["/Greffons/NssMySQL"])
  * vers une base MySQL pour la messagerie (["/Greffons/Postfix"]-MySQL)
  * pour la gestion de fonctionnalités additionnelles : saisie, suivi et statistiques sur les commandes de documents primaires ; gestion de la caisse, via une gestion de reçus et un état de caisse mensuel
  * attachement d'informations diverses et variées autour des utilisateurs : leurs commandes, leurs emprunts, leurs dates d'anniversaire, leurs passions, ...
Ligne 32: Ligne 43:
 Des modules d'extension:: tout ce qu'il faut pour s'adapter aux besoins locaux, pas exemple :
  1. pour l'intégration au niveau du système d'exploitation :
   1. extraction des informations vers le système d'authentification local, par exemple :
    1. vers les fichiers {{{/etc/passwd}}} et {{{/etc/shadow}}}, pour un système avec ou sans NIS
    1. vers une base de données MySQL d'authentification
   1. extraction des informations vers le système de messagerie local, par exemple :
    1. extraction des informations vers les fichiers {{{/etc/aliases}}}, {{{/etc/postfix/virtual}}}, etc, pour la messagerie
    1. une base de données MySQL pour la messagerie
   1. extraction des informations vers un annuaire LDAP
   1. etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs
  1. pour la gestion de fonctionnalités additionnelles :
   1. saisie, suivi et statistiques sur les commandes de documents primaires
   1. gestion de la caisse, via une gestion de reçus et un état de caisse mensuel
  1. attachement d'informations diverses et variées autour des utilisateurs :
   1. leurs commandes, leurs emprunts, leurs dates d'anniversaire, leurs passions, ... enfin tout ce qui n'est pas interdit au nom du respect de la vie privée, c'est à dire finalement plus grand chose.
Ligne 52: Ligne 48:
= Description plus détaillée = = Documentations =
Ligne 54: Ligne 50:
== Le logiciel de gestion de la base ==  * La documentation détaillée du code est ici : ["/Code"]
 * La documentation d'installation et d'intégration... reste à écrire : ["/MiseEnPlace"]
Ligne 56: Ligne 53:
En utilisant un système comme Django, on simplifie la programmation (validation des données, interfaçages). Une fois l'ensemble des fonctions de gestion définies (l'API), elle est disponible directement via Python, on peut donc l'utiliser dans de nombreux cas : outils en ligne de commande, scripts, cron, etc. = Calendrier =
Ligne 58: Ligne 55:
La programmation objet permet de proposer des extensions via des surcharges des fonctions.

L'idée est donc d'avoir un système Django/Python qui proposera toute l'API de gestion. Ensuite au niveau des applications on n'aura qu'à appeler l'API, sans jamais accéder directement à la base de données (pas de requête SQL directe).

=== Définition de l'API ===

L'API est l'ensemble des fonctions qui vont permettre de faire toutes les opérations nécessaires sur la base de données. Par exemple (non-contractuel) :
 . {{{utilisateur::ajouter(nom, prénom, age, genre, organisme, login, mot_de_passe)}}} pour ajouter un utilisateur
 . {{{utilisateur::abonner(login, service, date_début, date_fin)}}} pour abonner un utilisateur à un service

Il faut donc définir l'ensemble des fonctions.

Chaque fonction sera ''surchargeable'' afin d'être adaptée aux conditions locales. Exemple de surcharges possibles :
 * une surcharge ''NSS-MySQL'' permettant de mettre à jour une table NSS-MySQL en parallèle : à chaque ajout/modification/suppression d'un abonnement, on met à jour une table MySQL à part, dédiée à l'authentification ;
 * une surcharge ''Postfix'' pour le système de messagerie afin de mettre à jour en temps réel des tables pour Postfix ;
 * une surcharge ''mkdir'' pour créer le répertoire d'un utilisateur sur un serveur distant (via ssh) lors de sa création
 * etc.
Un ensemble de surcharges sera proposé par défaut recouvrant le maximum de besoins. Chaque surcharge disposera d'un fichier de configuration de base.

<!> Pour l'instant nous ne savons pas encore quelle forme concrète va prendre cette programmation des surcharges. Idéalement, un répertoire « extensions » dans lequel on placerait des fichiers Django/Python (''.py''). Ça serait pratique.

== Les systèmes d'extraction ==

À partir d'un système comme Django, on peut extraire les données assez facilement via des ''templates''. Pour la plupart des extractions il ne sera pas nécessaire à l'administrateur système de savoir programmer en Python.

Chaque système d'extraction disposera d'un fichier de configuration par défaut. Par exemple pour un système qui générera le fichier {{{/etc/passwd}}} via une extraction, on indiquera le ''shell'' par défaut. Ce shell par défaut pourra être éventuellement écrasé pour tel ou tel utilisateur s'il existe des informations spécifiques pour cet utilisateur (voir plus loin la notion de champ ''extra'' dans la base de donnée).

== Schéma de la base de données ==

<!> Pour l'instant rien n'est vraiment fixé. C'est pourtant un point capital qu'il faut régler RAPIDEMENT !

Quelques idées générales :
 * des utilisateurs, des groupes et des abonnements qui permettent de dire que tel utilisateur est dans tel groupe de telle à telle date
 * la base n'est pas destinée à être utilisée telle quelle pour l'authentification ou la gestion système : des ''backends'' sont disponibles pour créer, à partir de cette base, les données système nécessaires (fichiers ''passwd+shadow'', base MySQL-auth, arbre LDAP, htpasswd, etc).
 * par défaut la base ne contient pas de données purement "système" : ces données (comme le shell, la homedir, etc) sont calculées par les backend, éventuellement en fonction de conditions locales (exemple: homedir du type /home/a/n/antoine ou encore /home/auf/antoine) ou de spécificités de l'utilisateur (par exemple : un attribut ou appartenance à un groupe `compte_systeme` lui donnerait un shell utilisable)
 * un mécanisme de champ « extra » permet d'étendre les tables en associant des variables à un utilisateur, un groupe ou autre (merci JérômeSantini pour cette chouette idée) <!> notion à préciser pour l'implémentation, mais l'idée est d'avoir une structure souple et non figée
 * la gestion des organismes d'appartenance est organisée, éventuellement de façon hiérarchique (par exemple université->faculté->département, mais attention au risque de manque de souplesse). Ainsi, si une personne est de tel département, on sait qu'elle est aussi de telle faculté et de telle université.

Voir :
 . /PropositionThomas
 . /PropositionSebastien
 . /PropositionTini

Et combiner les idées ici:
 . /PropositionBase

<!> Question : ça serait pas mal, vu la configuration du monde universitaire actuel, qu'un abonné puisse être rattaché à plusieurs organismes :

<!> Réponse :
  * C'est fait dans la proposition de Thomas (triplet { utilisateur, organisme, fonction }).
  * C'est également fait dans le modèle combiné sous forme de fiche. Un usager peut avoir plusieurs fiches universitaires et/ou professionnelles et par conséquent être rattaché à un ou plusieurs organisme.


= Calendrier Prévisionnel =

== Phase 1 ==
 * 23 août – 6 Septembre : Sébastien rentre de Port-Vila à Montréal en passant par le CAI de Sofia, le CNF de Tunis et le CNF de Dakar, histoire de compléter les besoins fonctionnels et l'expression des besoins avec la réalité de terrrain de Campus très différents du sien et différents les uns des autres. Voir : AncienWiki:SebastienLMissionSystemGestion (ancien wiki) pour le suivi.
 * 11 septembre : SebastienLanteigne s'installe à Montréal dans l'équipe informatique pour la réalisation du projet
 * 11 septembre – 15 septembre : Vidéconférences et compilation des données

== Phase 1,5 ==
 * le plus tôt possible : Validation d'une première version de la structure de la base de données

== Phase 2 : Développement ==
 * 18 septembre – 6 octobre : Nettoyage du code existant
 * 9 octobre – 27 octobre : Adaptation et création de nouveaux modules
 * 30 octobre – 10 novembre : Déploiement de serveurs de tests

== Phase 3 : Test, déboguage et documentation ==
 * 13 novembre - 15 décembre : déboguage et transfert du développement vers les ressources internes

== Phase 4 : Déploiement ==
 * À définir

= Documentation =

La documentation suivante est en cours d'écriture/adaptation/à faire :

 * Django sur apache2 avec mod_python (DjangoModPython)
  * Installation multiple (DjangoInstallMultiple)
 * importer un application dans Django (DjangoAppImport)
 * Authentification d'un poste client sur MySQL (["AuthMySQLClient"])
 * Autre docs (à définir)

== Mise à jour (et FAQ) ==
 Où en est le projet ?:: Après un retour assez difficile à Montréal j'ai finalement configuré mon environnement de travail et monté un test largement basé sur la configuration du CNF de Port Vila. Le test en question est fonctionnel et permettrait, s'il était déployé aujourd'hui, de gérer les usagers du CNF de Port Vila. Il intègre certaines idées retenus lors de mon passages dans les différents CNF. Notamment la gestion des groupes et la création de pièces comptable comme présenté à Tunis. Une collecte des informations sur les usagers plus poussée que celle de Port Vila mais moindre que celle de l'IFAG à Sofia. De plus le test basé sur python et Django intègre automatiquement le suivi des transactions comme évoqué par Svetan à Sofia et Jérome à Dakar.
 Bien qu'un certain retard existe en raison du changement de technologie (le développement était prévu en PHP à l'origine). Le calendrier reste bon. Nous pouvons d'ailleurs prendre un peu d'avance sur le déploiement de serveurs de tests. Puisque le développement sera fait avec Django nous pouvons déjà déployer les premiers tests sur quelques serveurs. La procédure est disponible sur la page ["Django"]. De plus il est possible de télécharger un serveur de tests pré-configuré pour VMware.

 Technologie choisie:: Python, ["Django"], MySQL

 Comment développe-t'on une application pour un CNF sans CNF ?:: On le virtualise. Dans le bût de recréer les installations présentes dans nos CNF, l'application est développée sur un serveur Debian GNU/Linux "Sarge" 3.1 présent dans un réseau virtuel sous VMware serveur.
 Est-ce que je peux voir où on en est ?:: Oui. Un modèle est visible sur http://osti.auf:8000/admin/ . Le modèle actuellement en place n'est peut être pas à jour mais je vais essayer de charger la dernière version lorsqu'il y aura des changements nottable.

= Expression des besoins =

Suite aux visites faites dans différents CNF. Certains éléments communs étant directement liés à la gestion des usagers font surface. Notamment :

== Besoins de fonctionnement ==

 * Suivi des opérations : L'application doit offrir un suivi des opérations sur la base : ajouts, modifications, suppressions, etc. (Ce suivi est intégré dans Django)
-- CédricProtière : d'après la démo, il semblerait que chaque admin puisse mettre en place des groupes d'utilisateurs de l'outil et de spécifier les niveaux de pouvoir qu'il souhaite. Je trouve que c'est très appréciable et correspond aux besoins qu'on peut avoir.
De plus, lors de la visio avec Sébastien, nous avions abordé le fait que les utilisateurs du CNF doivent pouvoir modifier eux-même certains paramètres :
 * Paramètres modifiables par tous
    * Nom d'affichage (ThomasNoël : pas d'accord, trop d'abus... on a pas mal d'étudiants pas sérieux ;) )
    * Coordonnées personnelles (téléphone, adresse, ...) (TN : idem)
    * Mot de passe
    * Formuler une demande à l'administrateur (pour changer un paramètre non modifiable par lui, par exemple) : -- TN : ça c'est bien, mais bon, on verra... pas super prioritaires. La personne s'adressera à l'accueil qui fera la modif et basta. Pas la peine de programmer un truc pour ça maintenant.
 * Paramètres non modifiables
    * NOM Prénom
    * Adresse email
    * identifiant Unix
    * alias email

== Besoins ==

 * Création de comptes d'usagers : Évidement il s'agit d'un besoin essentiel à tous nos CNF. Par contre dans certains cas aucun outil (ou des outils pas très ergonomique pour les personnels non technique) n'est offert. (Module de base)
 * Suivi d'usagers : À ce niveau le passage à l'IFAG m'a montré un système très poussé, peut être même un peu trop, l'idée est sans doute à reprendre. (À étudier et intégrer)
 * Gestions de groupes : Il ne s'agit pas ici des groupes Unix mais bien de groupes administratif nous permettant d'organiser nos utilisateurs de façon plus logique. Ce besoin est présent dans beaucoup de systèmes notamment celui de Tunis. Jérome à Dakar aimerait reprendre cette idée pour pouvoir gérer l'accès aux salles par groupe. (À étudier et intégrer)

<!> Commentaire: CédricProtière : je suis également preneur des groupes UNIX : lorsqu'un utilisateur fait partie d'un groupe "administratif", il doit être possible de le mettre aussi dans un groupe UNIX du même nom (ou du nom UNIXifié). On peut éventuellement séparer ces deux notions, mais celle de groupe UNIX me paraît essentielle (faire partie du groupe ''foad'' ne suffit pas pour pouvoir utiliser Windows, par exemple...) -- ThomasNoël : à faire via la notion d'abonement à des groupes. au niveau de l'extraction ça sera transformé en certains groupes Unix, si besoin.

 * Statistiques : Tous nos CNF ont besoin d'une forme ou une autre de statistiques.
  * Inscriptions : (À intégrer)
  * Fréquentation : (À modulariser)

<!> Commentaire: CédricProtière : + toutes les statistiques demandées par l'AUF (nombre de sites web, nombre de revues commandées, nb de mails reçus/envoyés...) devraient pouvoir être consultées/modifiées (avec états par mois, trimestre, année) - prévoir à ce propos un module d'upload des infos sur le wiki ou sur une bdd auf centrale (afin d'automatiser totalement les statistiques ou de permettre de remonter ou consulter plus facilement ces infos)
<!> JC : prévoir plutôt un module d'extraction ; le reste se fera plus simplement via des scripts. -- ThomasNoël : tout "betement" des templates Django... ils permettent de faire très très facilement ce genre de synthèse, même par des gars qui ne savent pas programmer en Django. Ca ressemble à des templates spip, d'ailleurs.
<!> Seb : Est-ce qu'on peut définir la liste exacte des stats demander par l'AUF ? -- ThomasNoël : voir déjà ce qui est demandé aux CNF par SQI, y'a pas mal de trucs.


 * Suivi comptable : Il s'agit ici de générer des pièces comptables directement exploitables. Par exemple une facture (ou plutôt un reçu) à chaque création de compte ou un compte-rendu hebdomadaire ou mensuel des entrées d'argent liées à la création de comptes (et à leur renouvellement). Évoqué par plusieurs dont Cédric Protière à Cotonou. Une rencontre, à ce sujet, a eu lieu avec Mme Nathalie Houle à son retour de mission. Celle-ci me confirme plus ou moins les demandes de la compta à ce sujet. Ils veulent être en mesure de générer, sur demande, des reçus pour les abonnements[[FootNote(Ça fonctionne déjà comme ça à Hanoï.)]]. De plus la création de suivi comptable journalier, hebdomadaire ou mensuel est désirable. Le CNF de Tunis me présentait, lors de mon passage, une application utilisée à cet effet. Malheureusement l'application en question n'est pas intégrée au système de gestion de comptes présente au CNF.
<!> Question : CédricProtière : en quoi consistent les propositions de Mme HOULE ? je crois que nous pouvons participer ici à l'allègement de Coda !
<!> Note de JC : pas de Coda, car on n'y entre pas de si petites sommes une par une, mais effectivement le travail de la comptable via un état de caisse automatisé.
<!> Réponse: En un simple rapport montrant les nouveaux abonnements pour une période donné. Montrant l'abonement, sa durée et le prix payé. Très semblable au rapport fait par le système de Jérome à Dakar.

== Autres besoins ==
 * Gestions de bibliothèques : Certains CNF ont une sélection d'ouvrage offert aux usagers. À mon avis les outils existant, tel PMB, offrent des possibilités intéressantes dans ce domaine. La création d'un nouvel outil est sans doute inutile. Par contre une liaison (synchronisation ?) entre les deux bases d'utilisateurs pourrait être intéressante.
 * Contrôle des accès web : Encore là les outils existant sont à explorer. Voir Squid, Squidguard, dansguardian, etc. Sinon il suffit de se baser sur l'authentification système, Apache proposant par exemple un module d'authentification via PAM. -- ThomasNoël : je suis contre le contrôle a priori et surtout quand il se base sur une "morale". Ce qui nous gène ce sont les gens qui sur-utilisent les services et empechent le système de marcher. Le reste... pas génant. -- SebastienLanteigne : C'est pas toujours morale. Dans certains cas nous avons une obligation légale de le faire. Par exemple à Vanuatu où la pornographie est illégale et où fournis un accès (direct ou indirect) à un tel contenu est également illégale. Mais bon, ce n'est plus de la gestion d'usagers mais bien du contrôle d'accès et les outils pour ça existe déjà.
 * contrôle des impressions/photocopies: (À voir) --CédricProtière : est-il possible de comptabiliser le nombre d'impressions (mieux : de pages imprimées) par utilisateur ?
-- ThomasNoël : pour ça, faudrait surtout trouver comment contrôler vraiment les impressions. Depuis 10 ans que je joue avec des imprimantes réseaux, j'ai jamais rien vu de costaud non surbidouillé...
-- Sébastien Lanteigne: Oui. Correctement, non. Le problèmes c'est la gestion des bourrages, les pages blanches, etc. Analyser le log ça donne des résultats mais quand une impression de 10 pages bloque à la deuxième page on retrouve quand même 10 pages dans le log. Comme le dis Thomas c'est 'borderline' bidouille.

 * --(Réservation : Poste, salle, etc. (À modulariser) --CédricProtière : à coupler avec agenda partagé iCal (la réservation de salle étant l'agenda de la salle). Je suis à la recherche d'un serveur iCal, pas encore trouvé à ce jour malgré les nombreuses contrib existantes. Aide bienvenue !)-- JeanChristopheAndré : cela dépasse largement le sujet ici. -- ThomasNoël : mmmh, la réservation des salles et la prévision des formations, pas vraiment, c'est un gros boulot répétitif. Avec la notion d'abonnement générique on pourrait imaginer abonner des gens à un groupe représentant une formation et/ou une salle. Ce que je veux dire c'est que la base de donnée a un format qui permettra de gérer cela (plus tard), et donc oui, si y'a qqun pour programmer un truc de reservation, on pourra !
----		 Voir la sous-page ["/Calendrier"]

Ce projet a pour but d'écrire un système gestion des utilisateurs d'une implantations AUF (CNF, CAI, bureau, antenne... ou toute autre implantation où il y a des utilisateurs).

TableOfContents

Objectifs du projet

  • Objectifs du projet : unifier nos systèmes d'authentification et nos outils de suivi des utilisateurs des implantations AUF ;

  • Résultats attendus :

    • faciliter le travail des gestionnaires en automatisant le plus grand nombre de tâches répétitives, longues ou complexes, progressivement (via l'ajout de nouveaux modules) ;

    • simplifier le travail de tous en factorisant les soucis : les problèmes ne seront plus locaux, ils seront plus simples à résoudre si tout le monde fonctionne un peu de la même façon au départ ;

  • Contraintes : l'existant est très varié (NIS, passwd, LDAP, Samba, ...) et il faut donc prévoir toutes sortes de particularités locales (services purement locaux, campus intégré, etc.), d'où l'importance de la modularité.

Lire aussi la sous-page sur l'[:/Besoins: expression des besoins] qui présente quelques autres aspects. Ajoutez-y vos demandes.

Le quotidien du projet

  • Le développement du code de l'application se passe sur un Trac/Subversion ici : http://trac.sn.auf.org/guia (serveur hébergé à Dakar avec parfois quelques soucis de routage ou d'électricité en ce moment).

  • Les discussions ont lieu sur la sous-page ["/Discussion"]

Vue générale

Le système se décompose en trois parties :

Le noyau
il s'agit d'une base de donnée et un ensemble de fonctions permettant d'y accéder.

  • la base de données décrit l'ensemble des utilisateurs et des abonnements associés. Elle a un schéma de base simple, correspondant au noyau dur du système. Elle autorise une intégration simple de modules d'extension (greffons) via des champs extra sur ses objets. Voir /SchemaBase.

  • l'accès à la base est écrit en Python/Django. Chaque objet de la base est donc visible sous la forme d'un objet Python disposant de méthodes permettant de le gérer. L'appel à ces méthodes effectue les actions nécessaires sur la base de données. Là encore, chaque méthode peut être surchargée par des greffons.
Des interfaces
  • dans un premier temps une interface Web, rapide et ergonomique, permettant d'effectuer des actions sur la base. Django fourni une interface d'administration calculée automatiquement à partir de la définition des objets. Il faut la faire un peu évoluer pour la rendre plus ergonomique.
  • puisqu'il est écrit en Django, le noyau est accessible directement en Python. D'autres interfaces sont donc programmables, telle qu'une interface en ligne de commande.
Des greffons (modules d'extension, ''plug-ins'')
ils sont chargés, à partir d'informations fournies par le noyau, de gérer les aspects «métier», par exemple :
  • vers une base de données MySQL d'authentification (["/Greffons/NssMySQL"])
  • vers une base MySQL pour la messagerie (["/Greffons/Postfix"]-MySQL)
  • pour la gestion de fonctionnalités additionnelles : saisie, suivi et statistiques sur les commandes de documents primaires ; gestion de la caisse, via une gestion de reçus et un état de caisse mensuel
  • attachement d'informations diverses et variées autour des utilisateurs : leurs commandes, leurs emprunts, leurs dates d'anniversaire, leurs passions, ...
Parfois avec un schéma on voit mieux
attachment:gestion-utilisateurs-campus.png

(source de ce schéma : attachment:gestion-utilisateurs-campus.dia)

Documentations

  • La documentation détaillée du code est ici : ["/Code"]

  • La documentation d'installation et d'intégration... reste à écrire : ["/MiseEnPlace"]

Calendrier

Voir la sous-page ["/Calendrier"]

Projet/GUIA (dernière édition le 2008-02-21 22:09:51 par localhost)