Modifications entre les versions 6 et 50 (s'étendant sur 44 versions)
⇤ ← Version 6 à la date du 2006-10-17 15:18:20 →
Taille: 11192
Éditeur: SebastienLanteigne
Commentaire:
← Version 50 à la date du 2008-02-21 22:09:51 → ⇥
Taille: 4051
Éditeur: localhost
Commentaire: converted to 1.6 markup
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
[[TableOfContents]] 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:
(Page en cour de rédaction)
Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI)		  * Responsable : ThomasNoël
 * Développeur principal : OusmaneWilane
 * Participants : JeanChristopheAndré, JérômeSantini, SebastienLanteigne... ''et tout le monde intéressé !''
Ligne 6: Ligne 7:
 * Responsable : SébastienLanteigne
 * Participants : SebastienDornano, CédricProtière, JeanChristopheAndré, ThomasNoël, JérômeSantini... ''et tout le monde intéressé !''

= Historique du projet =

 * Discussions à Rabat lors de la réunion DRI. Ebauche du cadre du projet : AncienWiki:ReunionDri2005CompteRenduSIGCampus (ancien wiki)
 * Entre temps, aucun temps libre dans les équipes respectives pour commencer le projet.
 * Discussions sur la liste tech sur la nécessité de pas laisser tomber ce projet...
 * La fin de mission de SébastienLanteigne comme responsable technique de l'antenne de Port-Vila (et du CNF associé), son intérêt pour le projet, nous a permis de le conserver "à contrat" pour réaliser le projet.

= 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 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 ver les ressources internes

== Phase 4 : Déploiement ==
 * À définir		 <<TableOfContents>>
Ligne 35: Ligne 10:
== Mise à jour (et FAQ) ==
  * Ou en est le projet ?
Après un retour assez difficile à Montréal j'ai finalement configurer 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éployer aujourd'hui, de gérer les usagers du CNF de PV. 		= Objectifs du projet =
Ligne 39: Ligne 12:
Il intègre certaines idées retenus lors de mon passages dans différent CNF. Notamment la gestions des groupes et la création de pièces comptable comme présenté à Tunis. Une collecte des informations d'usagers plus pousser que celui de Port Vila mais moindre que celle de l'IFAG à Sofia. De plus le test basé sur python et Django intègre automatiquement le suivit de transactions comme évoquer par Svetan à Sofia et Jérome à Dakar.  . '''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é.
Ligne 41: Ligne 18:
Bien qu'un certains retard existe en raison du changement de technologie (le développement en PHP était prévu à l'origine). Le calendrier reste bon. Nous pouvons d'ailleur prendre un peu d'avance sur le déploiment de serveur de tests. Puisque le développement sera fait avec Django nous pouvons déjà déployer le premier test sur quelques serveurs. La procédure est disponible sur la page ["Django"]. De plus il est possible* de télécharger le serveur de tests préconfigurer pour VMware. Lire aussi la sous-page sur l'[[/Besoins| expression des besoins]] qui présente quelques autres aspects. Ajoutez-y vos demandes.
Ligne 43: Ligne 20:
  * Technologie choisi ?
Python, Django, MySQL 		= Le quotidien du projet =
Ligne 46: Ligne 22:
  * Comment développent-on un application pour un CNF sans CNF?
On le virtualise. Dans le bût de recréer les installations présentent dans nos CNF, l'application est développer sur un serveur Debian GNU/Linux 'Sarge' 3.1 présent dans un réseau virtuel sous Vmware serveur.		  * 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]]
Ligne 49: Ligne 25:
== Besoins ==
Suite aux visites faite dans différentes CNF. Certains éléments communs étant directement lié à la gestion des usagers font surface. Nottament:		 = Vue générale =
Ligne 52: Ligne 27:
=== Besoins de fonctionnement ===
  * Suivit des opérations : L'application doit offrir un suivit des opérations sur la base. Ajout, modifications, suppressions, etc. (Ce suivit est intégré dans Django)		 Le système se décompose en trois parties :
Ligne 55: Ligne 29:
=== Besoins ===
  * Création de comptes d'usagers : Évidement il s'agit d'un besoin essentiel à tous nos CNF. Par contre dans certains cas aucun outils (ou des outils pas très ergonomique pour les personnels non technique) ne sont offert. (Besoin présent partout)		  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 58: Ligne 37:
  * Suivit 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.  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 60: Ligne 43:
  * Gestions de groupes : Il ne s'agit pas ici des groupes Unix mais bien de groupes administratif nous permettant de diviser nos utilisateurs de façon plus logique. Ce besoins est présent dans beaucoup de système notamment celui de Tunis. Jérome à Dakar aimerais reprendre cette idée pour pouvoir gérer l'accès aux salles par groupe. (À étudier et intégrer)
Ligne 62: Ligne 44:
  * Statistiques : Tous nos CNF ont besoin d'une forme ou autre de statistiques.
    * Inscriptions : À intégrer
    * Fréquentation : À modulariser		  Parfois avec un schéma on voit mieux:: {{attachment:gestion-utilisateurs-campus.png}}
Ligne 66: Ligne 46:
  * Suivit comptable : Il s'agit ici de générer des pièces comptable directement exploitable. Par exemple une facture à chaque création de compte ou un compte-rendu hebdomadaire ou mensuel des entrés d'argent liées à la création de comtpes. Évoquer par plusieurs dont Cédric Protière à Cotonou. Un rencontre est prévue avec Mme. Nathalie Houle, qui rentre d'une visite de certains CNF, est prévue le mardi 17 octobre à ce sujet. (source de ce schéma : [[attachment:gestion-utilisateurs-campus.dia]])
Ligne 68: Ligne 48:
La rencontre aec Mme. Houle 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. De plus la création de suivit comptable journalier, hebdomadaire ou mensuel est désirable. = Documentations =
Ligne 70: Ligne 50:
Le CNF de Tunis me présentait, lors de mon passge, un application utilisé à cet effet. Malheureusement l'application en question n'est pas intégrer au système de gestion de comptes présente au CNF.  * La documentation détaillée du code est ici : [[/Code]]
 * La documentation d'installation et d'intégration... reste à écrire : [[/MiseEnPlace]]
Ligne 72: Ligne 53:
=== Autres besoins ===
  * Gestions de bibliothèques : Certains CNF ont une sélection d'ouvrage offert aux usagers. À mon avis les outils existant, tel PMB, offre des possibilités intéressant dans ce domaines. La création d'un autre outil est sans doutes inutiles.		 = Calendrier =
Ligne 75: Ligne 55:
  * Contrôles des accès web : Encore là les outils existant sont à explorer. Voir SQUID, Squidguard, dansguardian, etc.

  * Réservation : Poste, salle, etc. (Modulariser)
 
== Première proposition de base ==
=== Table user : ===
Contient toute l'information qui nous sert à identifer une personne.

Commentaires :
-Un champ photo?
{{{
+-------------+--------------+------+-----+------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+------------+----------------+
| u_id | int(11) | | PRI | NULL | auto_increment |
| nom | varchar(200) | | | | |
| prenom | varchar(200) | | | | |
| employeur | varchar(200) | | | | |
| profession | varchar(200) | | | | |
| adresse | varchar(200) | | | | |
| rue | varchar(200) | | | | |
| ville | varchar(200) | | | | |
| pays | varchar(200) | | | | |
| code_postal | varchar(200) | | | | |
| tel | varchar(200) | | | | |
| tel_tr | varchar(200) | | | | |
| cell | varchar(200) | | | | |
| email | varchar(75) | | | | |
| email_tr | varchar(75) | | | | |
| email_2 | varchar(75) | | | | |
| naissance | date | | | 0000-00-00 | |
+-------------+--------------+------+-----+------------+----------------+
}}}

=== Table groupe : ===
Elle contient les groupes ou catégories d'abonnements.
{{{
+-------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+----------------+
| id | int(11) | | PRI | NULL | auto_increment |
| nom | varchar(100) | | UNI | | |
+-------+--------------+------+-----+---------+----------------+
}}}

=== Table compte : ===
Contient l'information du compte de l'utilisateur. Ce sont les information normalement présentent dans les fichiers /etc/passwd et /etc/shadow. De plus elle contient également le domaine et l'alias de l'utilisateur.
{{{
+--------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+------------------+------+-----+---------+-------+
| user_id | int(11) | | PRI | 0 | |
| login | varchar(200) | | UNI | | |
| passwd | varchar(200) | | | | |
| uid | int(10) unsigned | | | 0 | |
| gid | int(10) unsigned | | | 0 | |
| gecos | varchar(200) | | | | |
| homedir | varchar(200) | | UNI | | |
| minimum | varchar(200) | | | | |
| maximum | varchar(200) | | | | |
| warn | varchar(200) | | | | |
| inact | varchar(200) | | | | |
| expire | varchar(200) | | | | |
| lastchg | varchar(200) | | | | |
| shell | varchar(200) | | | | |
| flag | smallint(6) | | | 0 | |
| email_domain | varchar(200) | | | | |
| email_user | varchar(200) | | | | |
| active | tinyint(1) | | | 0 | |
+--------------+------------------+------+-----+---------+-------
}}}

=== Table abonnement : ===
Contient les données d'abonements (la transaction).
Comentaires :
-Peut être ajouter un champ création? (pour la création d'abonnements avant leur date de début)
{{{
+-----------+---------+------+-----+------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+---------+------+-----+------------+----------------+
| id | int(11) | | PRI | NULL | auto_increment |
| user_id | int(11) | | | 0 | |
| debut | date | | | 0000-00-00 | |
| fin | date | | | 0000-00-00 | |
| groupe_id | int(11) | | | 0 | |
+-----------+---------+------+-----+------------+----------------+
}}}		 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).

Sommaire

  1. Objectifs du projet
  2. Le quotidien du projet
  3. Vue générale
  4. Documentations
  5. Calendrier

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'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

gestion-utilisateurs-campus.png

(source de ce schéma : 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)