Modifications entre les versions 2 et 50 (s'étendant sur 48 versions)

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).

Responsable : ThomasNoël
Développeur principal : OusmaneWilane
Participants : JeanChristopheAndré, JérômeSantini, SebastienLanteigne... et tout le monde intéressé !

Sommaire

Objectifs du projet
Le quotidien du projet
Vue générale
Documentations
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

(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

-  ⇤ ← Version 2 à la date du 2006-10-02 12:02:54 → 
  Taille: 5650
  Éditeur: ThomasNoël
  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:
-[[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:
-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 5:
+Ligne 7:
- * Responsable : SébastienLanteigne
 * Participants : SebastienDornano, CédricProtière, JeanChristopheAndré, ThomasNoël, JérômeSantini... ''et tout le monde intéressé !''
+<<TableOfContents>>
-Ligne 8:
+Ligne 9:
-= Historique du projet =
 Ligne 10:
- * 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.
+= Objectifs du projet =
-Ligne 15:
+Ligne 12:
-= Calendrier Prévisionnel =
+ . '''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 17:
+Ligne 18:
-== 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
+Lire aussi la sous-page sur l'[[/Besoins| expression des besoins]] qui présente quelques autres aspects. Ajoutez-y vos demandes.
-Ligne 22:
+Ligne 20:
-== 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
+= Le quotidien du projet =
-Ligne 27:
+Ligne 22:
-== Phase 3 : Test, déboguage et documentation ==
 * 13 novembre - 15 décembre : déboguage et transfert du développement ver les ressources internes
+ * 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 30:
+Ligne 25:
-== Phase 4 : Déploiement ==
 * À définir
+= Vue générale =
-Ligne 33:
+Ligne 27:
-détails du projet... à suivre....
+Le système se décompose en trois parties :
-Ligne 35:
+Ligne 29:
-= Prototype/Exemple de base (base de Port Vila) =
{{{
TABLE CLIENT (Information de l'usager)
+--------------+--------------+------+-----+---------+-------+
| Field        | Type         | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+-------+
| uid          | int(11)      |      | UNI | 0       |       |
| nom          | varchar(50)  | YES  |     | NULL    |       |
| prenom       | varchar(50)  | YES  |     | NULL    |       |
| username     | varchar(64)  |      | PRI |         |       |
| organisme    | varchar(100) | YES  |     | NULL    |       |
| profession   | varchar(100) | YES  |     | NULL    |       |
| telephone1   | varchar(20)  | YES  |     | NULL    |       |
| telephone2   | varchar(20)  | YES  |     | NULL    |       |
| fax          | varchar(20)  | YES  |     | NULL    |       |
| courriel     | varchar(100) | YES  |     | NULL    |       |
| inscription  | date         | YES  |     | NULL    |       |
| categorie_id | smallint(1)  | YES  |     | NULL    |       |
| point_id     | smallint(1)  | YES  |     | NULL    |       |
| prenom_nom   | smallint(1)  | YES  |     | NULL    |       |
+--------------+--------------+------+-----+---------+-------+
}}}
+ 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:
-{{{
TABLE SYSTEM (Information du compte d'usager)
+--------------+--------------+------+-----+--------------+-------+
| Field        | Type         | Null | Key | Default      | Extra |
+--------------+--------------+------+-----+--------------+-------+
| username     | varchar(64)  |      | PRI |              |       |
| password     | varchar(40)  |      |     | x            |       |
| uid          | mediumint(5) |      | MUL | 65534        |       |
| gid          | mediumint(5) |      |     | 100          |       |
| gecos        | varchar(50)  |      |     |              |       |
| homedir      | varchar(64)  |      |     | /nonexistent |       |
| min          | int(5)       |      |     | 0            |       |
| max          | int(5)       |      |     | 99999        |       |
| warn         | int(5)       |      |     | 7            |       |
| inact        | int(5)       |      |     | 0            |       |
| expire       | int(5)       |      |     | 0            |       |
| lstchg       | int(5)       |      |     | 0            |       |
| shell        | varchar(32)  |      |     | /bin/bash    |       |
| flag         | int(5)       |      |     | 0            |       |
| email_domain | varchar(32)  |      |     | localhost    |       |
| email_user   | varchar(32)  |      |     | technique    |       |
| make_dir     | tinyint(1)   |      |     | 0            |       |
| active       | tinyint(1)   |      |     | 0            |       |
+--------------+--------------+------+-----+--------------+-------+
}}}
+ 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 84:
+Ligne 43:
-{{{
TABLE STATS_FREQ (Log de fréquentation entrées/sorties)
+----------+----------------------+------+-----+------------+-------+
| Field    | Type                 | Null | Key | Default    | Extra |
+----------+----------------------+------+-----+------------+-------+
| event_id | bigint(20) unsigned  |      | PRI | 0          |       |
| uid      | int(11)              |      |     | 0          |       |
| date     | date                 |      |     | 0000-00-00 |       |
| time     | time                 |      |     | 00:00:00   |       |
| action   | tinyint(1)           |      |     | 0          |       |
+----------+----------------------+------+-----+------------+-------
}}}
-Ligne 97:
+Ligne 44:
-Cette structure de base n'est fournis qu'à titre d'exemple. D'autre tables viendront s'ajouter (groupes, abonnements, etc.)
+ 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]]

WikiTeki / Modifications de « Projet/GUIA »

Objectifs du projet

Le quotidien du projet

Vue générale

Documentations

Calendrier