112 lines
4.2 KiB
Markdown
112 lines
4.2 KiB
Markdown
|
# Modèle de données
|
||
|
|
|
||
|
|
Statut: référence technique
|
||
|
|
Public: mainteneurs, analystes, exploitants
|
||
|
|
Dernière révision: 2026-06-01
|
||
|
|
|
||
|
|
Ce document décrit les tables SQLAlchemy de l'application et leur rôle. Il ne remplace pas les modèles du code; il donne la carte fonctionnelle.
|
||
|
|
|
||
|
|
## Principes
|
||
|
|
|
||
|
|
- `groupes` est la racine métier.
|
||
|
|
- Les données d'un groupe doivent être isolées par `groupe_id`.
|
||
|
|
- Les membres ne sont pas supprimés pour l'historique; le droit à l'oubli anonymise.
|
||
|
|
- Les propositions et décisions sont dans une seule table.
|
||
|
|
- Les finances s'appuient sur un registre comptable.
|
||
|
|
- Les mouvements de réserves sont historisés.
|
||
|
|
- Les rapports adoptés sont cristallisés.
|
||
|
|
|
||
|
|
## Tables d'identité et groupes
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `groupes` | Groupe AA, horaire, lieu, paramètres d'assemblée. |
|
||
|
|
| `membres` | Membres du groupe, identifiant, PIN haché, profil, statut, préférences. |
|
||
|
|
| `invitations` | Codes d'inscription et liens invités ciblés. |
|
||
|
|
| `push_subscriptions` | Abonnements navigateur aux notifications push. |
|
||
|
|
|
||
|
|
## Tables de postes et accès
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `postes` | Définition des postes d'un groupe. |
|
||
|
|
| `affectations` | Mandats actifs ou terminés entre membre et poste. |
|
||
|
|
| `rotations` | Planification et historique de rotations. |
|
||
|
|
| `candidatures` | Candidatures et propositions de candidature. |
|
||
|
|
| `postes_modules` | Permissions de modules accordées à un poste. |
|
||
|
|
|
||
|
|
## Tables de rencontres et assemblées
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `reunions` | Rencontres hebdomadaires et assemblées d'affaires. |
|
||
|
|
| `presences` | Présences rattachées à une réunion. |
|
||
|
|
| `pv_reunions` | Procès-verbaux préparés ou adoptés. |
|
||
|
|
| `rapport_rsg` / `rapports_rsg` | Rapports RSG. |
|
||
|
|
| `rapports_adoptes` | Rapports cristallisés après adoption. |
|
||
|
|
|
||
|
|
## Tables de gouvernance
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `propositions` | Propositions, rejets, résolutions, nominations et contributions adoptées. |
|
||
|
|
|
||
|
|
Champs conceptuels importants de `propositions`:
|
||
|
|
|
||
|
|
- proposition: objet, contenu, auteur, proposeur, secondeur, statut;
|
||
|
|
- rejet: statut rejeté et raison;
|
||
|
|
- décision: type, numéro, date d'adoption, `ÉTANT DONNÉ QUE`, `LE GROUPE A DÉCIDÉ DE`.
|
||
|
|
|
||
|
|
## Tables financières
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `collectes` | Collectes de rencontres et réception par le trésorier. |
|
||
|
|
| `depenses` | Dépenses soumises, traitées, rejetées ou débitées. |
|
||
|
|
| `operations_bancaires` | Dépôts, retraits et opérations bancaires. |
|
||
|
|
| `transactions_comptables` | Source de vérité des soldes banque/encaisse. |
|
||
|
|
| `reserves` | Réserves nommées du groupe. |
|
||
|
|
| `mouvements_reserves` | Historique des virements entre disponible et réserves. |
|
||
|
|
| `destinataires_contributions` | Destinataires possibles des contributions. |
|
||
|
|
| `envois_contributions` | Contributions préparées et traitées. |
|
||
|
|
| `config_repartition` | Pourcentages de répartition suggérée. |
|
||
|
|
|
||
|
|
## Tables d'inventaire
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `litterature` | Catalogue et stock de littérature. |
|
||
|
|
| `ventes_litterature` | Ventes de littérature et remise au trésorier. |
|
||
|
|
| `jetons` | Remises statistiques de jetons/gâteaux. |
|
||
|
|
| `ventes_jetons` | Ventes de jetons affectant l'inventaire et l'encaisse à recevoir. |
|
||
|
|
|
||
|
|
## Tables de calendrier et rapports
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `evenements` | Événements affichés au calendrier. |
|
||
|
|
| `sync_log` | Trace technique de synchronisation ou usage historique. |
|
||
|
|
|
||
|
|
## Tables de journalisation
|
||
|
|
|
||
|
|
| Table | Rôle |
|
||
|
|
| --- | --- |
|
||
|
|
| `journal_actions` | Journal automatique des appels API modifiants. |
|
||
|
|
| `historique_modifications` | Historique métier détaillé des modifications, ancienne valeur, nouvelle valeur et raison automatique. |
|
||
|
|
|
||
|
|
## Tables mortes supprimées au démarrage
|
||
|
|
|
||
|
|
Le démarrage supprime les anciennes tables devenues obsolètes:
|
||
|
|
|
||
|
|
- `votes`;
|
||
|
|
- `options_sondage`;
|
||
|
|
- `sondages`;
|
||
|
|
- `decisions`.
|
||
|
|
|
||
|
|
## Points de vigilance
|
||
|
|
|
||
|
|
- Une relation 1:1 ne justifie pas à elle seule la fusion de deux tables. Il faut aussi vérifier le cycle de vie, le niveau d'accès, l'historisation, la fréquence d'usage et la signification métier.
|
||
|
|
- Les caches de montant ou de statut ne doivent pas remplacer les registres d'origine.
|
||
|
|
- Toute nouvelle table métier doit documenter son rattachement à un groupe.
|
||
|
|
|