|
Taille: 3160
Commentaire: sauvegarde temporaire... suite tout à l'heure
|
Taille: 5420
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 16: | Ligne 16: |
| * on veut gérer des usagers, il faut donc '''une table''' pour les identifier | * on veut gérer des usagers, il faut donc '''une base de données''' pour les enregistrer |
| Ligne 19: | Ligne 19: |
| * on veut pouvoir retrouver les traces des opérations, il faut donc '''une journalisation''' | |
| Ligne 28: | Ligne 29: |
| * on souhaiterait pouvoir gérer les quota d'impression (via CUPS) * on souhaiterait pouvoir gérer les paiements reçus (abonnement, commande de document, remboursement, état de caisse, bilan mensuel) |
|
| Ligne 31: | Ligne 34: |
| = Le noyau dur = | = La base de données = |
| Ligne 33: | Ligne 36: |
| == Les objets de base et leurs relations == | == L'objet « personne » == |
| Ligne 35: | Ligne 38: |
| === L'objet « personne » === ---- <!> '''Ce qui suit ne doit pas être pris en compte : ce sont des notes temporaires !''' <!> |
Il sert à pouvoir identifier un utilisateur dans la « Vraie Vie »™. |
| Ligne 55: | Ligne 54: |
| ||'''commentaire'''||Un commentaire éventuel|| == L'objet « abonnement » == Il sert à enregistrer la durée d'activité d'un utilisateur. ||'''__id__'''||Identifiant unique d'un abonnement|| ||'''id_personne'''||Identifiant de l'utilisateur concerné|| ||'''date_debut'''||Date de début d'activité|| ||'''date_fin'''||Date de fin d'activité|| = Extension de gestion financière = <!> voir le problème de la monnaie ! <!> == L'objet « recu » == Il sert à enregistrer le reçu d'un paiement, que ce soit en crédit ou en débit. ||'''__id__'''||Identifiant unique d'un reçu|| ||'''id_recu_origine'''||Lien vers le reçu d'origine en cas de remboursement après clôture|| ||'''id_personne'''||Identifiant de l'utilisateur recevant le reçu|| ||'''id_implantation'''||Identifiant de l'implantation où est émis le reçu|| ||'''date_saisie'''||Date de saisie du reçu|| ||'''date_valeur'''||Date de valeur du reçu|| ||'''credit'''||Valeur du reçu (perçue)|| ||'''debit'''||Valeur du reçu (remboursée)|| Note : `credit` et `debit` indiquent des sommes dans le même mois ; les remboursements d'un mois sur l'autre devant faire l'objet d'un nouveau reçu pour des raisons de clôture financière mensuelle. Cela permet ensuite de générer un « état de caisse » mensuel qui correspond effectivement au contenu de la caisse à la fin de chaque mois. == L'objet « recu_abonnement » == Il sert à enregistrer le paiement d'un abonnement. ||'''__id__'''||Identifiant unique d'un paiement d'abonnement|| ||'''id_recu'''||Identifiant du reçu pour le paiement|| ||'''id_abonnement'''||Identifiant de l'abonnement concerné|| == L'objet « recu_commande » == Il sert à enregistrer le paiement d'une commande. ||'''__id__'''||Identifiant unique d'un paiement de commande|| ||'''id_recu'''||Identifiant du reçu pour le paiement|| ||'''id_commande'''||Identifiant de la commande concernée|| ---- <!> '''Ce qui suit ne doit pas être pris en compte : ce sont des notes temporaires !''' <!> |
|
| Ligne 57: | Ligne 105: |
| * des objets `personne` * des objets `abonnement` * des objets `groupes` * des objets `comptes` * des objets `reçus` |
* des objets `groupe` * des objets `compte` * des objets `commande` |
Cette page présente ma proposition de version 0. -- JeanChristopheAndré
Introduction
Ma vision des choses :
- le logiciel doit comprendre un noyau dur et des extensions
le noyau dur doit consister en ce qui est indispensable, commun à toutes les situations
les extensions consistant alors en ce qui peut être utile d'ajouter, suivant le contexte
- les extensions doivent donc être modulaires, configurables et pouvoir être (dés)activées, selon les besoins
toutes les informations doivent être dans une unique base de données, source pour tout le reste
Partant de là on peut détailler :
- le noyau dur :
on veut gérer des usagers, il faut donc une base de données pour les enregistrer
on veut confier cette gestion à des non-techniciens, il faut donc une interface web
on veut pouvoir étendre les fonctionnalités, il faut donc définir une API
on veut pouvoir retrouver les traces des opérations, il faut donc une journalisation
les extensions indispensables :
on veut pouvoir générer une base d'authentification ["MySQL"] (avec libnss-mysql-bg)
on veut pouvoir générer une base d'authentification ["Samba"] (dans MySQL ou des fichiers, via pdbedit)
- on veut pouvoir générer une base d'adéls pour ["postfix"] (dans MySQL ou des fichiers)
- on veut pouvoir générer une base de boîtes aux lettres pour ["dovecot"] (dans MySQL ou des fichiers)
les extensions souhaitées :
on souhaiterait pouvoir générer une base d'authentification ["NIS"] (dans /etc/passwd, /etc/shadow et /etc/group)
- on souhaiterait pouvoir générer une base de boîtes aux lettres pour ["courier"] (dans MySQL ou des fichiers)
- on souhaiterait pouvoir intervenir depuis la ligne de commande (pas moi...)
- on souhaiterait pouvoir gérer les quota d'impression (via CUPS)
- on souhaiterait pouvoir gérer les paiements reçus (abonnement, commande de document, remboursement, état de caisse, bilan mensuel)
les extensions possibles :
- on souhaiterait pouvoir générer une base d'authentification ["LDAP"] (mais... finalement non)
La base de données
L'objet « personne »
Il sert à pouvoir identifier un utilisateur dans la « Vraie Vie »™.
id |
Identifiant unique d'une personne |
nom |
Son(ses) nom(s) tel(s) qu'indiqué(s) sur une pièce d'identité |
prenom |
Son(ses) prénom(s) tel(s) qu'indiqué(s) sur une pièce d'identité |
nom_affichage |
Le nom d'affichage souhaité |
genre |
Son genre |
date_naissance |
Sa date de naissance |
adel |
Son adél de contact préférée |
adel_alternative |
Son adél de contact alternative (en cas d'injoignabilité sur la précédente) |
adresse_personnelle |
Son adresse personnelle |
adresse_professionnelle |
Son adresse professionnelle |
telephone_personnel |
Son numéro de téléphone personnel |
telephone_professionnel |
Son numéro de téléphone professionnel |
telephone_mobile |
Son numéro de téléphone mobile |
telephone_fax |
Son numéro de fax |
commentaire |
Un commentaire éventuel |
L'objet « abonnement »
Il sert à enregistrer la durée d'activité d'un utilisateur.
id |
Identifiant unique d'un abonnement |
id_personne |
Identifiant de l'utilisateur concerné |
date_debut |
Date de début d'activité |
date_fin |
Date de fin d'activité |
Extension de gestion financière
voir le problème de la monnaie !
L'objet « recu »
Il sert à enregistrer le reçu d'un paiement, que ce soit en crédit ou en débit.
id |
Identifiant unique d'un reçu |
id_recu_origine |
Lien vers le reçu d'origine en cas de remboursement après clôture |
id_personne |
Identifiant de l'utilisateur recevant le reçu |
id_implantation |
Identifiant de l'implantation où est émis le reçu |
date_saisie |
Date de saisie du reçu |
date_valeur |
Date de valeur du reçu |
credit |
Valeur du reçu (perçue) |
debit |
Valeur du reçu (remboursée) |
Note : credit et debit indiquent des sommes dans le même mois ; les remboursements d'un mois sur l'autre devant faire l'objet d'un nouveau reçu pour des raisons de clôture financière mensuelle. Cela permet ensuite de générer un « état de caisse » mensuel qui correspond effectivement au contenu de la caisse à la fin de chaque mois.
L'objet « recu_abonnement »
Il sert à enregistrer le paiement d'un abonnement.
id |
Identifiant unique d'un paiement d'abonnement |
id_recu |
Identifiant du reçu pour le paiement |
id_abonnement |
Identifiant de l'abonnement concerné |
L'objet « recu_commande »
Il sert à enregistrer le paiement d'une commande.
id |
Identifiant unique d'un paiement de commande |
id_recu |
Identifiant du reçu pour le paiement |
id_commande |
Identifiant de la commande concernée |
Ce qui suit ne doit pas être pris en compte : ce sont des notes temporaires !
Nous aurons à manipuler :
des objets groupe
des objets compte
des objets commande