Refondre la documentation applicative
This commit is contained in:
parent
ab6ba0c13e
commit
2e7f471643
25 changed files with 2302 additions and 1870 deletions
141
README.md
141
README.md
|
|
@ -1,109 +1,52 @@
|
||||||
# Groupe Méditation — Application PWA
|
# Application de service pour groupes AA
|
||||||
|
|
||||||
**District 87-16 · Région 87 · Alcooliques anonymes**
|
Application PWA mobile-first pour soutenir la vie d'un ou plusieurs groupes AA: rencontres, assemblées, gouvernance, trésorerie, postes, membres, inventaires, rapports et historique.
|
||||||
|
|
||||||
Application mobile-first pour la gestion des groupes AA. 1 module = 1 tâche.
|
## Démarrage rapide
|
||||||
|
|
||||||
## Architecture
|
|
||||||
|
|
||||||
| Couche | Technologie |
|
|
||||||
|--------|-------------|
|
|
||||||
| Frontend | React 18 + Vite (PWA installable) |
|
|
||||||
| UI | Tailwind CSS (mobile-first) |
|
|
||||||
| État | Zustand |
|
|
||||||
| Backend | FastAPI (Python) async |
|
|
||||||
| DB | PostgreSQL + SQLAlchemy async |
|
|
||||||
| Auth | JWT 30 jours + bcrypt 12 rounds (prénom + PIN) |
|
|
||||||
| PDF | WeasyPrint |
|
|
||||||
| Serveur | NGINX (statiques + reverse proxy HTTPS) |
|
|
||||||
|
|
||||||
## Modules
|
|
||||||
|
|
||||||
### Consultation — Tous les membres
|
|
||||||
|
|
||||||
- **C1** Rapports PDF — finances, PV, résolutions, rapport complet
|
|
||||||
- **C2** Événements — anniversaires de sobriété, événements et résolutions
|
|
||||||
- **C4** Littérature — inventaire avec prix, alerte stock bas
|
|
||||||
- **C5** Gouvernance — décisions du groupe, propositions, résolutions, nominations et contributions
|
|
||||||
- **C7** Mon profil — modifier, changer PIN, notifications
|
|
||||||
- **C9** Postes à pourvoir — postes vacants, candidatures
|
|
||||||
|
|
||||||
### Saisie hebdomadaire (S1-S5)
|
|
||||||
|
|
||||||
- **S0** Réunion hebdomadaire — formulaire regroupé pour rapport, collecte, jeton et littérature
|
|
||||||
- **S1** Collecte 7e Tradition — réservé aux postes exécutifs
|
|
||||||
- **S1T** Trésorerie — soldes (banque + encaisse + réserves affectées), réception des collectes et ventes de littérature, registre détaillé des transactions, opérations bancaires (dépôt/retrait/relevé)
|
|
||||||
- **S2** Remise de jeton — 9 types, historique
|
|
||||||
- **S3** Vente littérature — stock auto-décrémenté, montant à remettre au trésorier
|
|
||||||
- **S4** Rapport de réunion — thème + annonces
|
|
||||||
- **S5** Dépenses — 6 champs, engagements non débités, confirmation de débit par le trésorier
|
|
||||||
|
|
||||||
### Saisie mensuelle (M1-M6)
|
|
||||||
|
|
||||||
- **M0** Assemblée d'affaires — formulaire regroupé pour réunion, présences et PV
|
|
||||||
- **M1** Rédiger PV — auto-renseigné depuis les propositions secondées, décisions structurées
|
|
||||||
- **M2** Présences réunion d'affaires
|
|
||||||
- **M3** Rapport RSG — template 3 sections
|
|
||||||
- **M4** Envoi contributions — somme disponible affichée par défaut, destinataire + montant + méthode
|
|
||||||
- **M5** Ajuster inventaire — +/−, ajout catalogue
|
|
||||||
- **M6** Commander jetons — état stock 30 jours
|
|
||||||
|
|
||||||
### Gestion — Exécutif
|
|
||||||
|
|
||||||
- **G2** Gestion des membres — membres, invitations, droit à l'oubli
|
|
||||||
- **G9** Paramètres du groupe — nom, horaire, adresse, format
|
|
||||||
- **G11** Gestion des mandats — affecter, terminer, planifier les rotations
|
|
||||||
- **G12** Gestion des postes — créer, abolir, candidatures, accès aux modules
|
|
||||||
|
|
||||||
## Trésorerie
|
|
||||||
|
|
||||||
La source de vérité financière est le registre `transactions_comptables`.
|
|
||||||
|
|
||||||
- **Banque** et **encaisse** sont calculées depuis les écritures comptables.
|
|
||||||
- **Réserves** est calculé depuis l'historique `mouvements_reserves`.
|
|
||||||
- Toute dépense ou contribution par chèque/virement reste un engagement jusqu'à confirmation du débit.
|
|
||||||
- Les rapports mensuels doivent s'appuyer sur ce registre.
|
|
||||||
|
|
||||||
## Gouvernance
|
|
||||||
|
|
||||||
Les propositions peuvent être créées en tout temps par n'importe quel membre, sans type initial. Le cycle est : proposée → secondée → transformée en résolution par l'exécutif. Lorsqu'adoptée, la proposition devient une décision numérotée avec les préfixes `RES` (résolution), `NOM` (nomination) ou `DON` (contribution), et les sections « ÉTANT DONNÉ QUE » et « LE GROUPE A DÉCIDÉ DE ».
|
|
||||||
|
|
||||||
Le PV de la réunion d'affaires s'auto-renseigne depuis les propositions secondées en attente de vote.
|
|
||||||
|
|
||||||
## Principes
|
|
||||||
|
|
||||||
- **Anonymat AA (12e Tradition)** — prénom seul dans les écrans partagés
|
|
||||||
- **Pas d'administrateur (2e Tradition)** — permissions = exécutif du groupe
|
|
||||||
- **Mandats manuels** — aucune terminaison automatique
|
|
||||||
- **Zéro traçage** — pas d'analytics, pas de cookies tiers
|
|
||||||
- **Hébergé au Québec** — souveraineté numérique · 100 % logiciel libre
|
|
||||||
|
|
||||||
## Fichiers
|
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd frontend
|
||||||
|
npm install
|
||||||
|
npm run build
|
||||||
```
|
```
|
||||||
backend/ API FastAPI (Python)
|
|
||||||
app/
|
```bash
|
||||||
core/ Config, DB, sécurité, rôles, règles communes
|
cd backend
|
||||||
services/ Logique métier réutilisable
|
python -m venv venv
|
||||||
models/ Modèles SQLAlchemy
|
venv/bin/pip install -r requirements.txt
|
||||||
routers/ Routes API
|
venv/bin/uvicorn app.main:app --reload
|
||||||
schemas/ Schémas Pydantic
|
```
|
||||||
frontend/ React + Vite + Tailwind
|
|
||||||
src/
|
La voie de déploiement supportée est Ansible:
|
||||||
pages/ 33 pages
|
|
||||||
stores/ Zustand + API helper
|
```bash
|
||||||
components/ Composants réutilisables
|
ansible-playbook ansible/site.yml
|
||||||
deploy/ Service systemd, NGINX, seed, backup
|
ansible-playbook ansible/verify.yml
|
||||||
docs/ DEPLOIEMENT.md, RUNBOOK.md
|
|
||||||
```
|
```
|
||||||
|
|
||||||
## Documentation
|
## Documentation
|
||||||
|
|
||||||
- [Guide utilisateur](docs/UTILISATEURS.md)
|
Le point d'entrée documentaire est [docs/00_INDEX.md](docs/00_INDEX.md).
|
||||||
- [Architecture technique](docs/ARCHITECTURE.md)
|
|
||||||
- [Déploiement Ansible](docs/ANSIBLE.md)
|
|
||||||
- [Runbook d'exploitation](docs/RUNBOOK.md)
|
|
||||||
|
|
||||||
---
|
Documents principaux:
|
||||||
|
|
||||||
|
- [Manuel utilisateur](docs/10_MANUEL_UTILISATEUR.md)
|
||||||
|
- [Processus applicatifs](docs/20_PROCESSUS.md)
|
||||||
|
- [Règles métier](docs/30_REGLES_METIER.md)
|
||||||
|
- [Architecture technique](docs/60_ARCHITECTURE.md)
|
||||||
|
- [Modèle de données](docs/50_MODELE_DONNEES.md)
|
||||||
|
- [API applicative](docs/70_API.md)
|
||||||
|
- [Déploiement Ansible](docs/91_DEPLOIEMENT_ANSIBLE.md)
|
||||||
|
- [Runbook](docs/90_EXPLOITATION.md)
|
||||||
|
|
||||||
|
## Stack
|
||||||
|
|
||||||
|
- Frontend: React, Vite, Tailwind, Zustand, PWA.
|
||||||
|
- Backend: FastAPI async, SQLAlchemy async, PostgreSQL.
|
||||||
|
- Rapports: WeasyPrint.
|
||||||
|
- Déploiement: systemd, NGINX, Ansible.
|
||||||
|
|
||||||
|
## Principe directeur
|
||||||
|
|
||||||
|
L'application est un outil de service. Elle garde la mémoire, facilite la continuité et rend les processus visibles, sans remplacer la conscience de groupe.
|
||||||
|
|
||||||
*«Nos leaders sont des serviteurs de confiance ; ils ne gouvernent pas.» — 2e Tradition*
|
|
||||||
|
|
|
||||||
63
docs/00_INDEX.md
Normal file
63
docs/00_INDEX.md
Normal file
|
|
@ -0,0 +1,63 @@
|
||||||
|
# Documentation de l'application
|
||||||
|
|
||||||
|
Statut: documentation de référence
|
||||||
|
Public: membres, exécutifs, sysadmin, mainteneurs
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Cette documentation décrit ce que l'application permet de faire, comment elle est exploitée et quels invariants doivent rester vrais. Elle doit être tenue à jour avec le code: une fonctionnalité livrée sans documentation est considérée incomplète.
|
||||||
|
|
||||||
|
## Parcours de lecture
|
||||||
|
|
||||||
|
Pour comprendre l'application comme membre:
|
||||||
|
|
||||||
|
- [Manuel utilisateur](10_MANUEL_UTILISATEUR.md)
|
||||||
|
- [Processus applicatifs](20_PROCESSUS.md)
|
||||||
|
- [Liens de causalité](40_LIENS_CAUSALITE.md)
|
||||||
|
- [Garde-fous sociaux](94_GARDE_FOUS_SOCIAUX.md)
|
||||||
|
- [Présentation aux membres](95_PRESENTATION_MEMBRES.md)
|
||||||
|
|
||||||
|
Pour administrer ou exploiter l'application:
|
||||||
|
|
||||||
|
- [Administration et exploitation](90_EXPLOITATION.md)
|
||||||
|
- [Déploiement Ansible](91_DEPLOIEMENT_ANSIBLE.md)
|
||||||
|
- [Déploiement](92_DEPLOIEMENT.md)
|
||||||
|
- [Sécurité et confidentialité](80_SECURITE.md)
|
||||||
|
- [Multi-groupe](93_MULTI_GROUPE.md)
|
||||||
|
|
||||||
|
Pour maintenir ou faire évoluer le code:
|
||||||
|
|
||||||
|
- [Architecture technique](60_ARCHITECTURE.md)
|
||||||
|
- [Modèle de données](50_MODELE_DONNEES.md)
|
||||||
|
- [API applicative](70_API.md)
|
||||||
|
- [Règles métier](30_REGLES_METIER.md)
|
||||||
|
- [Liens de causalité](40_LIENS_CAUSALITE.md)
|
||||||
|
|
||||||
|
## Organisation fonctionnelle
|
||||||
|
|
||||||
|
L'application est une PWA mobile-first pour soutenir la vie d'un ou plusieurs groupes AA isolés les uns des autres.
|
||||||
|
|
||||||
|
Elle couvre:
|
||||||
|
|
||||||
|
- sélection du groupe, connexion, inscription et profil;
|
||||||
|
- rencontres hebdomadaires;
|
||||||
|
- assemblées d'affaires;
|
||||||
|
- gouvernance, propositions, décisions, nominations et contributions;
|
||||||
|
- trésorerie, dépenses, collectes, ventes, réserves et rapports;
|
||||||
|
- membres, postes, mandats, candidatures et permissions;
|
||||||
|
- littérature, jetons, événements et anniversaires;
|
||||||
|
- rapports PDF et mode papier;
|
||||||
|
- journalisation, historique de modifications et notifications;
|
||||||
|
- gestion sysadmin des groupes et données de démonstration;
|
||||||
|
- liens de causalité entre les actions et leurs effets métier.
|
||||||
|
|
||||||
|
## Conventions
|
||||||
|
|
||||||
|
Les modules sont parfois identifiés par codes internes:
|
||||||
|
|
||||||
|
- `C`: consultation;
|
||||||
|
- `S`: saisie ou activité hebdomadaire;
|
||||||
|
- `M`: activité mensuelle ou d'assemblée;
|
||||||
|
- `G`: gestion;
|
||||||
|
- `G14`: gestion sysadmin des groupes.
|
||||||
|
|
||||||
|
Le mot `exécutif` désigne un membre ayant une affectation active à un poste de catégorie `executif`. Le compte `Sysadmin` est un compte technique qui satisfait toutes les vérifications d'accès.
|
||||||
288
docs/10_MANUEL_UTILISATEUR.md
Normal file
288
docs/10_MANUEL_UTILISATEUR.md
Normal file
|
|
@ -0,0 +1,288 @@
|
||||||
|
# Manuel utilisateur
|
||||||
|
|
||||||
|
Statut: documentation utilisateur
|
||||||
|
Public: membres AA, serviteurs, exécutifs, sysadmin
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Cette application aide un groupe AA à garder ensemble ce qui concerne ses rencontres, ses assemblées, ses décisions, ses finances, ses postes et sa mémoire. Elle ne remplace pas la conscience de groupe. Elle donne un endroit commun pour noter, consulter, imprimer et transmettre.
|
||||||
|
|
||||||
|
## 1. Avant de commencer
|
||||||
|
|
||||||
|
L'application fonctionne mieux sur téléphone. Les écrans sont conçus pour être utilisés avec le pouce.
|
||||||
|
|
||||||
|
Chaque membre a:
|
||||||
|
|
||||||
|
- un groupe;
|
||||||
|
- un identifiant ou courriel;
|
||||||
|
- un PIN de 4 chiffres;
|
||||||
|
- des accès qui dépendent de ses postes de service.
|
||||||
|
|
||||||
|
Le compte `Sysadmin` sert à l'administration technique et aux démonstrations. Il ne remplace pas les serviteurs du groupe.
|
||||||
|
|
||||||
|
## 2. Choisir son groupe et se connecter
|
||||||
|
|
||||||
|
1. Ouvrir l'application.
|
||||||
|
2. Choisir son groupe dans la liste.
|
||||||
|
3. Ouvrir la tuile du groupe.
|
||||||
|
4. Saisir son identifiant ou courriel.
|
||||||
|
5. Saisir son PIN.
|
||||||
|
6. Cocher `Se souvenir de moi` seulement sur son appareil personnel.
|
||||||
|
7. Appuyer sur `Connexion`.
|
||||||
|
|
||||||
|
Si la connexion échoue, vérifier que le bon groupe est ouvert. Le même identifiant peut exister dans un autre groupe.
|
||||||
|
|
||||||
|
## 3. S'inscrire
|
||||||
|
|
||||||
|
L'inscription se fait avec un code d'invitation.
|
||||||
|
|
||||||
|
1. Demander un code à un membre de l'exécutif.
|
||||||
|
2. Ouvrir `J'ai un code d'invitation`.
|
||||||
|
3. Entrer le code.
|
||||||
|
4. Renseigner prénom, téléphone, identifiant ou courriel et PIN.
|
||||||
|
5. Valider.
|
||||||
|
|
||||||
|
Le code rattache automatiquement l'inscription au bon groupe.
|
||||||
|
|
||||||
|
## 4. Navigation
|
||||||
|
|
||||||
|
La barre du bas apparaît seulement sur l'accueil. Elle sert à choisir un contexte:
|
||||||
|
|
||||||
|
- `Accueil`: consultation générale;
|
||||||
|
- `Rencontres`: activités des rencontres hebdomadaires;
|
||||||
|
- `Assemblées`: activités des assemblées d'affaires;
|
||||||
|
- `Gestion`: administration par les exécutifs.
|
||||||
|
|
||||||
|
Quand un module est ouvert, la barre disparaît pour libérer l'espace.
|
||||||
|
|
||||||
|
## 5. Profil
|
||||||
|
|
||||||
|
Le module `Profil` permet de:
|
||||||
|
|
||||||
|
- modifier ses informations personnelles;
|
||||||
|
- changer son PIN;
|
||||||
|
- voir ses postes actifs;
|
||||||
|
- comprendre ses accès;
|
||||||
|
- choisir les catégories de notifications;
|
||||||
|
- demander ou comprendre le droit à l'oubli.
|
||||||
|
|
||||||
|
Un membre désactivé ne peut plus se connecter, mais son historique reste conservé. Le droit à l'oubli anonymise les données personnelles tout en conservant l'ID et le prénom pour préserver la mémoire du groupe.
|
||||||
|
|
||||||
|
## 6. Rencontres
|
||||||
|
|
||||||
|
La page `Rencontres` présente les rencontres sous forme de tuiles.
|
||||||
|
|
||||||
|
Une tuile fermée montre:
|
||||||
|
|
||||||
|
- la date et l'heure;
|
||||||
|
- le sujet;
|
||||||
|
- le membre qui anime.
|
||||||
|
|
||||||
|
Une tuile ouverte donne accès aux actions de la rencontre:
|
||||||
|
|
||||||
|
- `Collecte`;
|
||||||
|
- `Ventes`;
|
||||||
|
- `Jetons/Gâteaux`;
|
||||||
|
- `Rapport PDF`.
|
||||||
|
|
||||||
|
Les exécutifs peuvent planifier et modifier une rencontre.
|
||||||
|
|
||||||
|
## 7. Collecte
|
||||||
|
|
||||||
|
Une rencontre a une collecte. Pour saisir une collecte:
|
||||||
|
|
||||||
|
1. Ouvrir la rencontre.
|
||||||
|
2. Appuyer sur `Collecte`.
|
||||||
|
3. Entrer le montant.
|
||||||
|
4. Indiquer qui détient l'argent.
|
||||||
|
5. Enregistrer.
|
||||||
|
|
||||||
|
Le trésorier accusera réception plus tard dans `Trésorerie`. Quand il reçoit l'argent, l'encaisse augmente à la date de la collecte.
|
||||||
|
|
||||||
|
## 8. Ventes de littérature et de jetons
|
||||||
|
|
||||||
|
Les ventes sont saisies dans la rencontre où elles ont lieu.
|
||||||
|
|
||||||
|
Pour une vente:
|
||||||
|
|
||||||
|
1. Ouvrir la rencontre.
|
||||||
|
2. Appuyer sur `Ventes`.
|
||||||
|
3. Choisir littérature ou jetons selon le cas.
|
||||||
|
4. Indiquer quoi, combien, le montant et qui détient l'argent.
|
||||||
|
5. Enregistrer.
|
||||||
|
|
||||||
|
Les ventes affectent l'inventaire. Le trésorier devra confirmer la réception de l'argent.
|
||||||
|
|
||||||
|
Les remises de jetons et gâteaux sont seulement statistiques. Elles ne diminuent pas l'inventaire.
|
||||||
|
|
||||||
|
## 9. Assemblées d'affaires
|
||||||
|
|
||||||
|
La page `Assemblées` fonctionne comme `Rencontres`: une tuile par assemblée.
|
||||||
|
|
||||||
|
Une assemblée peut contenir:
|
||||||
|
|
||||||
|
- présences;
|
||||||
|
- décisions;
|
||||||
|
- contributions;
|
||||||
|
- postes à pourvoir;
|
||||||
|
- rapport PDF.
|
||||||
|
|
||||||
|
La page de l'assemblée sert d'ordre du jour. Le rapport PDF sert de procès-verbal imprimable.
|
||||||
|
|
||||||
|
## 10. Présences
|
||||||
|
|
||||||
|
Dans une assemblée, ouvrir `Présences`, cocher les membres présents et enregistrer. Les présences alimentent le rapport PDF.
|
||||||
|
|
||||||
|
## 11. Procès-verbal et rapport du trésorier
|
||||||
|
|
||||||
|
L'adoption d'un procès-verbal ou d'un rapport du trésorier est faite par un exécutif avec un bouton `Adopter`. L'adoption demande un proposeur et un secondeur.
|
||||||
|
|
||||||
|
Avant adoption, le rapport peut être corrigé. Après adoption, il est cristallisé: il reste consultable et imprimable comme historique.
|
||||||
|
|
||||||
|
Le rapport du trésorier doit être adopté avant de décider du montant des contributions.
|
||||||
|
|
||||||
|
## 12. Gouvernance
|
||||||
|
|
||||||
|
Le module `Gouvernance` rassemble les propositions, réflexions en cours, rejets et décisions.
|
||||||
|
|
||||||
|
Un membre peut:
|
||||||
|
|
||||||
|
- soumettre une proposition;
|
||||||
|
- seconder une proposition avec `Je seconde`;
|
||||||
|
- consulter les décisions passées.
|
||||||
|
|
||||||
|
Un exécutif peut aussi:
|
||||||
|
|
||||||
|
- seconder pour un autre membre;
|
||||||
|
- transformer une proposition secondée en décision;
|
||||||
|
- rejeter une proposition avec une raison.
|
||||||
|
|
||||||
|
Une décision demande:
|
||||||
|
|
||||||
|
- un proposeur;
|
||||||
|
- un secondeur;
|
||||||
|
- une section `ÉTANT DONNÉ QUE`;
|
||||||
|
- une section `LE GROUPE A DÉCIDÉ DE`.
|
||||||
|
|
||||||
|
Les types de décisions sont:
|
||||||
|
|
||||||
|
- `Résolution`;
|
||||||
|
- `Nomination`;
|
||||||
|
- `Contribution`.
|
||||||
|
|
||||||
|
## 13. Dépenses
|
||||||
|
|
||||||
|
Un membre peut soumettre une dépense en son nom. Un exécutif peut soumettre pour un autre membre.
|
||||||
|
|
||||||
|
La dépense est ensuite traitée dans `Trésorerie`:
|
||||||
|
|
||||||
|
- `Cash`: diminue l'encaisse;
|
||||||
|
- `Chèque` ou `Virement`: crée un engagement jusqu'au débit bancaire;
|
||||||
|
- `Rejeter`: efface la demande.
|
||||||
|
|
||||||
|
## 14. Trésorerie
|
||||||
|
|
||||||
|
Le module `Trésorerie` présente d'abord la position du groupe:
|
||||||
|
|
||||||
|
- banque;
|
||||||
|
- encaisse;
|
||||||
|
- disponible;
|
||||||
|
- réserves;
|
||||||
|
- éléments à traiter.
|
||||||
|
|
||||||
|
Les exécutifs peuvent:
|
||||||
|
|
||||||
|
- recevoir collectes et ventes;
|
||||||
|
- traiter ou rejeter des dépenses;
|
||||||
|
- déposer de l'encaisse à la banque;
|
||||||
|
- enregistrer un don direct;
|
||||||
|
- retirer de la banque vers l'encaisse;
|
||||||
|
- créer, renommer ou supprimer des réserves à zéro;
|
||||||
|
- transférer des montants entre disponible et réserves;
|
||||||
|
- consulter le registre;
|
||||||
|
- produire le rapport PDF.
|
||||||
|
|
||||||
|
La page `Résultats` présente l'état des résultats par mois.
|
||||||
|
|
||||||
|
## 15. Donner au suivant
|
||||||
|
|
||||||
|
Le module `Donner au suivant` sert à préparer une contribution.
|
||||||
|
|
||||||
|
Il faut choisir:
|
||||||
|
|
||||||
|
- un destinataire;
|
||||||
|
- un montant;
|
||||||
|
- une méthode;
|
||||||
|
- un proposeur;
|
||||||
|
- un secondeur.
|
||||||
|
|
||||||
|
La contribution crée une décision de groupe. Elle doit ensuite être approuvée et traitée par la trésorerie avant de modifier les soldes.
|
||||||
|
|
||||||
|
## 16. Postes à pourvoir
|
||||||
|
|
||||||
|
Les postes disponibles sont affichés en tuiles. En ouvrant une tuile, le membre voit:
|
||||||
|
|
||||||
|
- la description;
|
||||||
|
- les candidats;
|
||||||
|
- le bouton `Postuler`;
|
||||||
|
- le bouton `Proposer`.
|
||||||
|
|
||||||
|
`Postuler` sert pour soi-même. `Proposer` permet à un exécutif de proposer un autre membre.
|
||||||
|
|
||||||
|
## 17. Gestion des membres
|
||||||
|
|
||||||
|
Les exécutifs peuvent:
|
||||||
|
|
||||||
|
- consulter les membres;
|
||||||
|
- inviter un membre;
|
||||||
|
- créer un compte pour un autre membre;
|
||||||
|
- désactiver ou réactiver;
|
||||||
|
- appliquer le droit à l'oubli.
|
||||||
|
|
||||||
|
Sysadmin peut impersonifier un membre pour aider ou vérifier un problème.
|
||||||
|
|
||||||
|
## 18. Gestion des postes et mandats
|
||||||
|
|
||||||
|
`Gestion des postes` permet de définir les postes et leurs permissions.
|
||||||
|
|
||||||
|
`Gestion des mandats` permet d'affecter, terminer et planifier les rotations.
|
||||||
|
|
||||||
|
Une affectation produit une décision de type `Nomination` avec proposeur et secondeur.
|
||||||
|
|
||||||
|
## 19. Littérature et jetons
|
||||||
|
|
||||||
|
Les membres peuvent consulter l'inventaire de littérature. Les responsables peuvent ajuster les stocks. Les ventes diminuent les stocks; les remises statistiques de jetons ne les diminuent pas.
|
||||||
|
|
||||||
|
## 20. Événements
|
||||||
|
|
||||||
|
Le module `Événements` affiche les événements passés et futurs. Les filtres peuvent être combinés.
|
||||||
|
|
||||||
|
## 21. Rapports PDF et mode papier
|
||||||
|
|
||||||
|
Les rapports PDF servent à imprimer ou conserver:
|
||||||
|
|
||||||
|
- rencontres;
|
||||||
|
- assemblées;
|
||||||
|
- décisions;
|
||||||
|
- état des résultats;
|
||||||
|
- rapports adoptés.
|
||||||
|
|
||||||
|
`Mode papier` soutient une reprise en main si l'informatique n'est pas disponible.
|
||||||
|
|
||||||
|
## 22. Journal
|
||||||
|
|
||||||
|
Le journal affiche les changements enregistrés. Une ligne condensée montre date, heure et domaine; l'ouverture donne les détails. Il sert à comprendre ce qui a changé, pas à surveiller les membres.
|
||||||
|
|
||||||
|
## 23. Gestion des groupes
|
||||||
|
|
||||||
|
Sur la page de sélection des groupes, le bouton discret `Sysadmin` demande le PIN sysadmin. Il ouvre la gestion des groupes.
|
||||||
|
|
||||||
|
Sysadmin peut:
|
||||||
|
|
||||||
|
- créer un groupe;
|
||||||
|
- modifier un groupe;
|
||||||
|
- supprimer un groupe non protégé;
|
||||||
|
- réinitialiser un groupe;
|
||||||
|
- réinitialiser le groupe de démonstration.
|
||||||
|
|
||||||
|
`Groupe Démonstration` est toujours présent sur une installation vanille et ne peut pas être supprimé.
|
||||||
|
|
||||||
366
docs/20_PROCESSUS.md
Normal file
366
docs/20_PROCESSUS.md
Normal file
|
|
@ -0,0 +1,366 @@
|
||||||
|
# Processus applicatifs
|
||||||
|
|
||||||
|
Statut: référence fonctionnelle
|
||||||
|
Public: membres, exécutifs, sysadmin, mainteneurs
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Ce document inventorie ce qui peut être fait avec l'application. Il complète le [manuel utilisateur](10_MANUEL_UTILISATEUR.md) en présentant les processus sous forme opérationnelle.
|
||||||
|
|
||||||
|
## Accès et identité
|
||||||
|
|
||||||
|
### Choisir un groupe
|
||||||
|
|
||||||
|
Un visiteur ouvre l'application, voit les groupes disponibles sous forme de tuiles, ouvre la tuile du groupe voulu, puis se connecte. Les groupes sont isolés: un membre appartient à un groupe précis et son jeton de session transporte ce `groupe_id`.
|
||||||
|
|
||||||
|
### Se connecter
|
||||||
|
|
||||||
|
Un membre se connecte avec son identifiant ou courriel, son PIN à 4 chiffres et le groupe sélectionné. L'option `Se souvenir de moi` prolonge la durée de session sur un appareil personnel.
|
||||||
|
|
||||||
|
### S'inscrire avec invitation
|
||||||
|
|
||||||
|
Un exécutif génère un code d'invitation. Le nouveau membre saisit ce code, ses informations personnelles et son PIN. L'inscription rattache automatiquement le membre au groupe de l'invitation.
|
||||||
|
|
||||||
|
### Gérer son profil
|
||||||
|
|
||||||
|
Chaque membre peut modifier son profil, changer son PIN, consulter ses accès et choisir les catégories de notifications. Les notifications push restent optionnelles et dépendent du navigateur.
|
||||||
|
|
||||||
|
### Se déconnecter
|
||||||
|
|
||||||
|
Le bouton `Déconnexion` est dans l'entête. Sur un appareil partagé, la déconnexion est obligatoire.
|
||||||
|
|
||||||
|
## Navigation
|
||||||
|
|
||||||
|
### Accueil
|
||||||
|
|
||||||
|
L'accueil présente les éléments de consultation et les tâches utiles au membre. Les modules visibles dépendent des postes actifs et des permissions.
|
||||||
|
|
||||||
|
### Rencontres
|
||||||
|
|
||||||
|
La page `Rencontres` remplace le vieux principe de module isolé. Les rencontres sont affichées en tuiles. Une tuile fermée montre date, heure, sujet et animation. Une tuile ouverte donne accès aux intrants de cette rencontre.
|
||||||
|
|
||||||
|
Actions possibles:
|
||||||
|
|
||||||
|
- planifier une rencontre;
|
||||||
|
- modifier une rencontre;
|
||||||
|
- saisir ou consulter la collecte liée;
|
||||||
|
- saisir des ventes de littérature;
|
||||||
|
- saisir des ventes de jetons;
|
||||||
|
- comptabiliser les remises de jetons et gâteaux;
|
||||||
|
- produire le rapport PDF de la rencontre.
|
||||||
|
|
||||||
|
### Assemblées
|
||||||
|
|
||||||
|
La page `Assemblées` suit le même principe que les rencontres: une tuile par assemblée d'affaires. La page de l'assemblée tient lieu d'ordre du jour.
|
||||||
|
|
||||||
|
Actions possibles:
|
||||||
|
|
||||||
|
- planifier une assemblée selon l'horaire du groupe;
|
||||||
|
- gérer les présences;
|
||||||
|
- préparer le texte d'invitation avec lien invité;
|
||||||
|
- traiter les décisions et propositions;
|
||||||
|
- traiter les contributions;
|
||||||
|
- consulter les postes à pourvoir;
|
||||||
|
- produire le rapport PDF, qui sert de procès-verbal.
|
||||||
|
|
||||||
|
## Rencontres hebdomadaires
|
||||||
|
|
||||||
|
### Planifier une rencontre
|
||||||
|
|
||||||
|
Un exécutif choisit une date permise par les paramètres du groupe. Les dates offertes respectent le jour de réunion configuré. L'animateur est choisi dans la liste des membres; par défaut, l'application propose le membre occupant le poste d'animateur.
|
||||||
|
|
||||||
|
### Saisir la collecte
|
||||||
|
|
||||||
|
Une rencontre a une collecte, et une collecte appartient à une rencontre. La date de transaction lors de la réception par le trésorier est la date de la collecte, pas la date de saisie tardive.
|
||||||
|
|
||||||
|
Processus:
|
||||||
|
|
||||||
|
1. Choisir la rencontre.
|
||||||
|
2. Saisir le montant.
|
||||||
|
3. Indiquer le membre qui détient l'argent.
|
||||||
|
4. Laisser le trésorier accuser réception.
|
||||||
|
5. À la réception, l'encaisse augmente.
|
||||||
|
|
||||||
|
### Saisir une vente
|
||||||
|
|
||||||
|
Les ventes de littérature et de jetons sont saisies pendant une rencontre. Elles peuvent être absentes, uniques ou multiples.
|
||||||
|
|
||||||
|
Effets:
|
||||||
|
|
||||||
|
- une vente de littérature diminue l'inventaire;
|
||||||
|
- une vente de jetons diminue l'inventaire de jetons;
|
||||||
|
- le montant vendu devient une somme à recevoir par le trésorier;
|
||||||
|
- à la réception, l'encaisse augmente.
|
||||||
|
|
||||||
|
### Comptabiliser une remise de jeton ou gâteau
|
||||||
|
|
||||||
|
Les remises de jetons et gâteaux sont statistiques. Elles n'affectent pas l'inventaire. Seules les ventes affectent l'inventaire.
|
||||||
|
|
||||||
|
### Produire un rapport PDF
|
||||||
|
|
||||||
|
Le rapport de rencontre regroupe les intrants associés à la rencontre. Il est conçu pour impression format lettre, avec un saut de page avant les ventes.
|
||||||
|
|
||||||
|
## Assemblées d'affaires
|
||||||
|
|
||||||
|
### Planifier une assemblée
|
||||||
|
|
||||||
|
Un exécutif planifie l'assemblée selon le rang configuré dans les paramètres du groupe: première, deuxième, troisième, quatrième ou dernière réunion du mois.
|
||||||
|
|
||||||
|
### Inviter
|
||||||
|
|
||||||
|
L'application produit un texte à copier/coller contenant un lien invité. Le lien donne accès à la page de l'assemblée en lecture seule. La page est l'ordre du jour.
|
||||||
|
|
||||||
|
### Présences
|
||||||
|
|
||||||
|
Les présences sont saisies pour l'assemblée. Elles alimentent le rapport PDF.
|
||||||
|
|
||||||
|
### Procès-verbal
|
||||||
|
|
||||||
|
Le rapport PDF d'assemblée tient lieu de procès-verbal. Le procès-verbal précédent peut être adopté par les exécutifs. L'adoption exige un proposeur et un secondeur et peut inclure des corrections avant cristallisation.
|
||||||
|
|
||||||
|
### Rapport du trésorier
|
||||||
|
|
||||||
|
Le rapport du trésorier doit être adopté avant de décider des contributions. Son adoption exige un proposeur et un secondeur. Une fois adopté, le rapport est cristallisé, historisé, consultable et imprimable.
|
||||||
|
|
||||||
|
### Décisions
|
||||||
|
|
||||||
|
Les propositions secondées mais non résolues, les décisions prises, les contributions et les nominations alimentent le rapport d'assemblée.
|
||||||
|
|
||||||
|
## Gouvernance
|
||||||
|
|
||||||
|
### Soumettre une proposition
|
||||||
|
|
||||||
|
Un membre peut soumettre une proposition avec un objet et un contenu. Une proposition n'a pas de type au départ.
|
||||||
|
|
||||||
|
### Seconder
|
||||||
|
|
||||||
|
Un membre peut cliquer `Je seconde`. Un exécutif peut seconder pour un autre membre depuis une liste déroulante. Sysadmin peut seconder ses propres propositions et nominations.
|
||||||
|
|
||||||
|
### Transformer en décision
|
||||||
|
|
||||||
|
Un exécutif peut transformer une proposition secondée en décision du groupe. Il doit renseigner:
|
||||||
|
|
||||||
|
- le type de décision;
|
||||||
|
- le proposeur;
|
||||||
|
- le secondeur;
|
||||||
|
- `ÉTANT DONNÉ QUE`;
|
||||||
|
- `LE GROUPE A DÉCIDÉ DE`.
|
||||||
|
|
||||||
|
Types et préfixes:
|
||||||
|
|
||||||
|
- `Résolution`: `RES`;
|
||||||
|
- `Nomination`: `NOM`;
|
||||||
|
- `Contribution`: `DON`.
|
||||||
|
|
||||||
|
### Rejeter une proposition
|
||||||
|
|
||||||
|
Un exécutif peut rejeter une proposition. Le rejet conserve la proposition et exige `ÉTANT DONNÉ QUE` pour expliquer la raison historique.
|
||||||
|
|
||||||
|
### Consulter les décisions
|
||||||
|
|
||||||
|
Les décisions sont consultables sous forme de tuiles. Les rapports PDF de résolutions utilisent la section `LE GROUPE A DÉCIDÉ DE` comme libellé principal lorsque cette section existe.
|
||||||
|
|
||||||
|
## Trésorerie
|
||||||
|
|
||||||
|
### Voir la position de trésorerie
|
||||||
|
|
||||||
|
La page d'accueil de `Trésorerie` affiche:
|
||||||
|
|
||||||
|
- banque;
|
||||||
|
- encaisse;
|
||||||
|
- solde disponible;
|
||||||
|
- total des réserves;
|
||||||
|
- réserves;
|
||||||
|
- éléments à traiter.
|
||||||
|
|
||||||
|
Le solde disponible n'est pas une réserve. Il est calculé comme solde bancaire moins engagements et réserves affectées. L'encaisse est disponible, mais séparée de la banque.
|
||||||
|
|
||||||
|
### Voir les résultats
|
||||||
|
|
||||||
|
La page `Résultats` présente l'état des résultats avec sélecteur mois/année. Le rapport PDF mensuel utilise toujours le mois précédent et les positions au dernier jour du mois précédent.
|
||||||
|
|
||||||
|
### Accuser réception
|
||||||
|
|
||||||
|
Le trésorier confirme la réception de collectes et de ventes. Cette confirmation augmente l'encaisse.
|
||||||
|
|
||||||
|
### Traiter une dépense
|
||||||
|
|
||||||
|
Une dépense soumise devient un élément à traiter. Le trésorier peut traiter ou rejeter.
|
||||||
|
|
||||||
|
Effets:
|
||||||
|
|
||||||
|
- `Cash`: diminue immédiatement l'encaisse;
|
||||||
|
- `Chèque` ou `Virement`: crée un engagement jusqu'à confirmation du débit bancaire;
|
||||||
|
- si le solde bancaire ne permet pas d'engager la dépense, l'acceptation est refusée;
|
||||||
|
- `Rejeter`: efface la demande comme si elle n'avait jamais existé.
|
||||||
|
|
||||||
|
### Dépôt
|
||||||
|
|
||||||
|
Un dépôt bancaire peut provenir:
|
||||||
|
|
||||||
|
- de l'encaisse;
|
||||||
|
- d'un don direct qui ne provenait pas de l'encaisse.
|
||||||
|
|
||||||
|
Un dépôt depuis l'encaisse diminue l'encaisse et augmente la banque. Un don direct augmente la banque.
|
||||||
|
|
||||||
|
### Retrait
|
||||||
|
|
||||||
|
Un retrait transfère de la banque vers l'encaisse.
|
||||||
|
|
||||||
|
### Virement entre réserves
|
||||||
|
|
||||||
|
Un virement déplace un montant entre le solde disponible et les réserves, ou entre deux réserves. Ces mouvements virtuels apparaissent au registre.
|
||||||
|
|
||||||
|
### Gérer les réserves
|
||||||
|
|
||||||
|
Un exécutif peut créer une réserve, modifier son nom et supprimer une réserve dont le solde est à zéro. Le montant d'une réserve ne se modifie pas directement: il change par virement.
|
||||||
|
|
||||||
|
### Registre
|
||||||
|
|
||||||
|
Le registre présente les transactions les plus récentes d'abord. Il peut être filtré par mois et type de transaction.
|
||||||
|
|
||||||
|
## Dépenses
|
||||||
|
|
||||||
|
### Soumettre une dépense
|
||||||
|
|
||||||
|
Un membre soumet une dépense en son nom. Un exécutif peut soumettre pour un autre membre. La date est la date de soumission, sauf contexte sysadmin permettant une saisie à posteriori.
|
||||||
|
|
||||||
|
### Joindre une preuve
|
||||||
|
|
||||||
|
Une preuve peut être ajoutée à la dépense lorsque le flux le prévoit.
|
||||||
|
|
||||||
|
### Suivre l'état
|
||||||
|
|
||||||
|
Les dépenses sont suivies depuis le module `Trésorerie` pour éviter un double traitement.
|
||||||
|
|
||||||
|
## Contributions
|
||||||
|
|
||||||
|
### Donner au suivant
|
||||||
|
|
||||||
|
Le module `Donner au suivant` prépare une contribution. Il choisit un destinataire, un montant, une méthode, un proposeur et un secondeur. La contribution crée une décision de type `Contribution`. Elle doit ensuite être approuvée et traitée par la trésorerie pour affecter les soldes.
|
||||||
|
|
||||||
|
### Gérer les destinataires
|
||||||
|
|
||||||
|
La liste des destinataires est gérée depuis la trésorerie. `District 87-16` existe au déploiement initial et est protégé contre la suppression.
|
||||||
|
|
||||||
|
## Membres
|
||||||
|
|
||||||
|
### Inviter
|
||||||
|
|
||||||
|
Un exécutif génère une invitation. Le message d'invitation mentionne le groupe courant.
|
||||||
|
|
||||||
|
### Créer un compte pour un autre membre
|
||||||
|
|
||||||
|
Un exécutif peut créer un compte membre.
|
||||||
|
|
||||||
|
### Désactiver ou réactiver
|
||||||
|
|
||||||
|
La désactivation suspend seulement le droit de connexion. Elle ne supprime pas l'historique.
|
||||||
|
|
||||||
|
### Droit à l'oubli
|
||||||
|
|
||||||
|
Le droit à l'oubli anonymise le membre au lieu de supprimer son enregistrement. L'application conserve l'ID et le prénom afin que l'historique reste intelligible.
|
||||||
|
|
||||||
|
### Impersonification
|
||||||
|
|
||||||
|
Sysadmin peut agir au nom d'un autre membre. Le jeton conserve l'identité du sysadmin pour journalisation.
|
||||||
|
|
||||||
|
## Postes, mandats et permissions
|
||||||
|
|
||||||
|
### Postes à pourvoir
|
||||||
|
|
||||||
|
Les postes disponibles sont affichés par tuiles. Une tuile ouverte présente la description, les candidats et les boutons:
|
||||||
|
|
||||||
|
- `Postuler`;
|
||||||
|
- `Proposer`.
|
||||||
|
|
||||||
|
### Gestion des postes
|
||||||
|
|
||||||
|
Un exécutif gère les postes sous forme de tuiles:
|
||||||
|
|
||||||
|
- créer un poste;
|
||||||
|
- modifier les attributs;
|
||||||
|
- gérer les permissions;
|
||||||
|
- consulter les attentes;
|
||||||
|
- abolir;
|
||||||
|
- réactiver;
|
||||||
|
- supprimer définitivement si permis.
|
||||||
|
|
||||||
|
### Gestion des mandats
|
||||||
|
|
||||||
|
Un exécutif peut:
|
||||||
|
|
||||||
|
- affecter un poste;
|
||||||
|
- terminer un mandat;
|
||||||
|
- planifier les rotations;
|
||||||
|
- consulter les affectations.
|
||||||
|
|
||||||
|
Une affectation génère une décision de type `Nomination` et exige proposeur et secondeur.
|
||||||
|
|
||||||
|
## Littérature et jetons
|
||||||
|
|
||||||
|
### Consulter l'inventaire
|
||||||
|
|
||||||
|
Tous les membres peuvent consulter la littérature et les stocks visibles.
|
||||||
|
|
||||||
|
### Ajuster l'inventaire
|
||||||
|
|
||||||
|
Les responsables autorisés peuvent ajuster littérature et jetons. L'inventaire initial de littérature peut être chargé depuis le fichier d'import.
|
||||||
|
|
||||||
|
### Commander des jetons
|
||||||
|
|
||||||
|
Le module de commande présente l'état des stocks de jetons.
|
||||||
|
|
||||||
|
## Événements et calendrier
|
||||||
|
|
||||||
|
### Consulter les événements
|
||||||
|
|
||||||
|
Les événements passés et futurs sont affichés. Les filtres peuvent être sélectionnés en combinaison. Les résolutions ne sont pas affichées comme événements du calendrier.
|
||||||
|
|
||||||
|
### Gérer les événements
|
||||||
|
|
||||||
|
Les exécutifs peuvent créer et supprimer les événements du groupe.
|
||||||
|
|
||||||
|
## Rapports PDF
|
||||||
|
|
||||||
|
Rapports disponibles:
|
||||||
|
|
||||||
|
- état des résultats;
|
||||||
|
- rapport de rencontre;
|
||||||
|
- rapport d'assemblée d'affaires;
|
||||||
|
- registre des résolutions;
|
||||||
|
- rapports financiers ou historiques conservés;
|
||||||
|
- rapports adoptés cristallisés.
|
||||||
|
|
||||||
|
Les rapports sont conçus pour pouvoir être imprimés et servir de reprise papier.
|
||||||
|
|
||||||
|
## Journal et historique
|
||||||
|
|
||||||
|
### Journal
|
||||||
|
|
||||||
|
Le journal affiche les changements API sous forme de tuiles. Une tuile condensée montre date, heure et domaine. L'ouverture affiche les détails.
|
||||||
|
|
||||||
|
### Historique de modifications
|
||||||
|
|
||||||
|
L'historique conserve, lorsque disponible, l'objet modifié, l'ancien contenu, le nouveau contenu, la raison automatique et le membre ayant causé le changement.
|
||||||
|
|
||||||
|
## Gestion des groupes
|
||||||
|
|
||||||
|
### Accès sysadmin
|
||||||
|
|
||||||
|
Sur la page de sélection des groupes, le bouton discret `Sysadmin` demande le PIN sysadmin et ouvre la gestion des groupes.
|
||||||
|
|
||||||
|
### Créer, modifier, supprimer
|
||||||
|
|
||||||
|
Sysadmin peut créer, modifier ou supprimer des groupes. Le groupe de démonstration est protégé.
|
||||||
|
|
||||||
|
### Réinitialiser
|
||||||
|
|
||||||
|
Chaque tuile de groupe possède un bouton `Réinit`.
|
||||||
|
|
||||||
|
- Pour le groupe de démonstration, les données fictives sont recréées.
|
||||||
|
- Pour un autre groupe, les données du groupe sont remises à leur état de base.
|
||||||
|
|
||||||
|
### Groupe de démonstration
|
||||||
|
|
||||||
|
Une installation vanille crée automatiquement `Groupe Démonstration` avec des données fictives crédibles, 12 mois d'activité, 52 rencontres et 12 assemblées.
|
||||||
|
|
||||||
197
docs/30_REGLES_METIER.md
Normal file
197
docs/30_REGLES_METIER.md
Normal file
|
|
@ -0,0 +1,197 @@
|
||||||
|
# Règles métier
|
||||||
|
|
||||||
|
Statut: référence métier
|
||||||
|
Public: exécutifs, mainteneurs, testeurs
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Ce document rassemble les règles que l'application doit respecter. Pour les parcours complets, voir [Processus applicatifs](20_PROCESSUS.md).
|
||||||
|
|
||||||
|
## Accès, identité et groupes
|
||||||
|
|
||||||
|
- Un membre se connecte dans un groupe précis.
|
||||||
|
- Les données d'un groupe ne doivent pas être visibles ou modifiables depuis un autre groupe.
|
||||||
|
- Le compte `Sysadmin` existe au déploiement initial avec le PIN `0000`.
|
||||||
|
- `Sysadmin` a tous les accès.
|
||||||
|
- `Sysadmin` ne peut pas être supprimé.
|
||||||
|
- `Sysadmin` peut impersonifier un membre.
|
||||||
|
- Une session impersonifiée conserve l'identité du sysadmin responsable.
|
||||||
|
- Un membre inactif ne peut pas se connecter.
|
||||||
|
- Un PIN doit avoir 4 chiffres.
|
||||||
|
- L'identifiant de connexion est unique dans un groupe.
|
||||||
|
- L'option `Se souvenir de moi` ne doit être utilisée que sur un appareil personnel.
|
||||||
|
|
||||||
|
## Groupe de démonstration
|
||||||
|
|
||||||
|
- Une installation vanille crée `Groupe Démonstration`.
|
||||||
|
- `Groupe Démonstration` est protégé contre la suppression.
|
||||||
|
- Le bouton `Réinit` du groupe de démonstration recrée les données fictives.
|
||||||
|
- Les autres groupes ne doivent pas être modifiés par la réinitialisation du groupe de démonstration.
|
||||||
|
- Les groupes sont listés alphabétiquement, sauf le groupe de démonstration qui reste en bas.
|
||||||
|
|
||||||
|
## Membres
|
||||||
|
|
||||||
|
- Le prénom et le téléphone sont requis pour un membre ordinaire.
|
||||||
|
- La désactivation agit seulement sur le droit de connexion.
|
||||||
|
- La réactivation restaure le droit de connexion.
|
||||||
|
- Le droit à l'oubli anonymise au lieu de supprimer.
|
||||||
|
- Le droit à l'oubli conserve l'ID et le prénom.
|
||||||
|
- Le droit à l'oubli efface les informations de contact, le nom, la date d'abstinence, les préférences et les abonnements push.
|
||||||
|
- Un membre ne doit pas pouvoir détruire l'historique relationnel du groupe.
|
||||||
|
|
||||||
|
## Invitations
|
||||||
|
|
||||||
|
- Une invitation appartient à un groupe.
|
||||||
|
- Une inscription par invitation crée le membre dans le groupe de l'invitation.
|
||||||
|
- Un code d'invitation ne peut être utilisé qu'une seule fois.
|
||||||
|
- Un code expiré est refusé.
|
||||||
|
|
||||||
|
## Permissions
|
||||||
|
|
||||||
|
- Les permissions viennent des postes actifs.
|
||||||
|
- Les permissions de modules sont associées aux postes.
|
||||||
|
- Les exécutifs ont accès aux fonctions de gestion courante.
|
||||||
|
- Les responsables de service peuvent recevoir des modules spécialisés.
|
||||||
|
- Le frontend peut masquer un module, mais le backend doit refuser l'action non autorisée.
|
||||||
|
|
||||||
|
## Postes, candidatures et mandats
|
||||||
|
|
||||||
|
- Un poste appartient à un groupe.
|
||||||
|
- Un poste peut être actif ou aboli.
|
||||||
|
- Un poste aboli n'est pas proposé comme poste à pourvoir.
|
||||||
|
- Un membre peut postuler à un poste disponible.
|
||||||
|
- Un exécutif peut proposer un autre membre.
|
||||||
|
- Une affectation active lie un membre, un poste et une date de début.
|
||||||
|
- Un poste déjà affecté ne doit pas être affecté une deuxième fois tant que le mandat est actif.
|
||||||
|
- Terminer un mandat conserve l'historique.
|
||||||
|
- Une affectation ou nomination produit une décision de type `Nomination`.
|
||||||
|
- Une nomination exige proposeur et secondeur.
|
||||||
|
|
||||||
|
## Rencontres
|
||||||
|
|
||||||
|
- Les dates de rencontres doivent respecter le jour configuré du groupe.
|
||||||
|
- Les listes de dates doivent être présentées en ordre chronologique inverse lorsque cela réduit le risque de choisir la mauvaise année.
|
||||||
|
- Une rencontre indique une date, une heure, un sujet et un animateur.
|
||||||
|
- L'animateur par défaut est le membre occupant le poste d'animateur lorsque connu.
|
||||||
|
- Une rencontre peut avoir une collecte.
|
||||||
|
- Une rencontre peut avoir plusieurs ventes.
|
||||||
|
- Une rencontre peut avoir plusieurs remises statistiques de jetons ou gâteaux.
|
||||||
|
- Le rapport PDF d'une rencontre regroupe les intrants de cette rencontre.
|
||||||
|
|
||||||
|
## Assemblées
|
||||||
|
|
||||||
|
- Les assemblées sont des réunions d'affaires planifiées selon les paramètres du groupe.
|
||||||
|
- Le paramètre mensuel indique première, deuxième, troisième, quatrième ou dernière réunion du mois.
|
||||||
|
- La page d'une assemblée sert d'ordre du jour.
|
||||||
|
- Le rapport PDF d'assemblée sert de procès-verbal imprimable.
|
||||||
|
- Les présences alimentent le rapport.
|
||||||
|
- Le lien invité donne accès en lecture seule pendant une période contrôlée.
|
||||||
|
|
||||||
|
## Procès-verbaux et rapports adoptés
|
||||||
|
|
||||||
|
- L'adoption d'un procès-verbal exige un proposeur et un secondeur.
|
||||||
|
- L'adoption du rapport du trésorier exige un proposeur et un secondeur.
|
||||||
|
- Un rapport peut être corrigé avant adoption.
|
||||||
|
- Une fois adopté, un rapport est cristallisé, historisé, consultable et imprimable.
|
||||||
|
- Le rapport du trésorier doit être adopté avant de décider des contributions.
|
||||||
|
|
||||||
|
## Gouvernance
|
||||||
|
|
||||||
|
- Une proposition n'a pas de type au départ.
|
||||||
|
- Une proposition doit avoir un objet.
|
||||||
|
- Une proposition peut être secondée avec `Je seconde`.
|
||||||
|
- Un exécutif peut seconder pour un autre membre.
|
||||||
|
- Sysadmin peut seconder ses propres propositions et nominations.
|
||||||
|
- Une décision de groupe exige proposeur et secondeur.
|
||||||
|
- Une décision exige les sections `ÉTANT DONNÉ QUE` et `LE GROUPE A DÉCIDÉ DE`.
|
||||||
|
- Les types de décisions sont `Résolution`, `Nomination` et `Contribution`.
|
||||||
|
- Les préfixes sont `RES`, `NOM` et `DON`.
|
||||||
|
- Une proposition rejetée est conservée.
|
||||||
|
- Le rejet exige une raison dans `ÉTANT DONNÉ QUE`.
|
||||||
|
|
||||||
|
## Collectes
|
||||||
|
|
||||||
|
- Une collecte appartient à une rencontre.
|
||||||
|
- Une rencontre ne doit pas avoir plus d'une collecte.
|
||||||
|
- La saisie de collecte est réservée aux postes autorisés, notamment exécutifs.
|
||||||
|
- Une collecte reçue par le trésorier augmente l'encaisse.
|
||||||
|
- La date comptable de réception d'une collecte est la date de la collecte.
|
||||||
|
|
||||||
|
## Ventes et inventaire
|
||||||
|
|
||||||
|
- Une vente de littérature est saisie lors d'une rencontre.
|
||||||
|
- Une vente de littérature diminue l'inventaire.
|
||||||
|
- Une vente de jetons est saisie lors d'une rencontre.
|
||||||
|
- Une vente de jetons diminue l'inventaire de jetons.
|
||||||
|
- L'argent d'une vente est à recevoir par le trésorier.
|
||||||
|
- La réception d'une vente augmente l'encaisse.
|
||||||
|
- Une remise de jeton ou gâteau est statistique et n'affecte pas l'inventaire.
|
||||||
|
|
||||||
|
## Dépenses
|
||||||
|
|
||||||
|
- Un membre soumet une dépense en son nom.
|
||||||
|
- Un exécutif peut soumettre une dépense pour un autre membre.
|
||||||
|
- La date de dépense est la date de soumission, sauf saisie à posteriori autorisée pour sysadmin.
|
||||||
|
- Les dépenses sont traitées dans le module `Trésorerie`.
|
||||||
|
- Une dépense cash diminue l'encaisse au traitement.
|
||||||
|
- Une dépense par chèque ou virement crée un engagement jusqu'au débit bancaire.
|
||||||
|
- Une dépense par chèque ou virement ne peut pas être acceptée si le solde bancaire ne permet pas d'engager le montant.
|
||||||
|
- Une demande rejetée est effacée.
|
||||||
|
|
||||||
|
## Trésorerie
|
||||||
|
|
||||||
|
- `transactions_comptables` est la source de vérité des soldes banque et encaisse.
|
||||||
|
- L'encaisse est disponible mais séparée de la banque.
|
||||||
|
- Le solde disponible est le solde bancaire moins engagements et réserves.
|
||||||
|
- Le solde disponible n'est pas une réserve.
|
||||||
|
- Le total des réserves fait partie de la position de trésorerie.
|
||||||
|
- Les réserves ne doivent pas dépasser ce que la banque permet de couvrir.
|
||||||
|
- Le montant d'une réserve change par mouvement de réserve, pas par modification directe.
|
||||||
|
- Une réserve peut être supprimée seulement si son solde est zéro.
|
||||||
|
- Les virements entre disponible et réserves apparaissent au registre.
|
||||||
|
- Les transactions du registre sont affichées les plus récentes d'abord.
|
||||||
|
|
||||||
|
## Dépôts, retraits et dons
|
||||||
|
|
||||||
|
- Un dépôt peut provenir de l'encaisse.
|
||||||
|
- Un dépôt peut provenir d'un don direct.
|
||||||
|
- Un don direct augmente la banque sans diminuer l'encaisse.
|
||||||
|
- Un dépôt depuis l'encaisse augmente la banque et diminue l'encaisse.
|
||||||
|
- Un retrait augmente l'encaisse et diminue la banque.
|
||||||
|
|
||||||
|
## Contributions
|
||||||
|
|
||||||
|
- `Donner au suivant` crée une décision de type `Contribution`.
|
||||||
|
- Une contribution exige proposeur et secondeur.
|
||||||
|
- Une contribution doit avoir un destinataire.
|
||||||
|
- `District 87-16` est créé au déploiement initial.
|
||||||
|
- `District 87-16` est protégé contre la suppression.
|
||||||
|
- Une contribution doit être traitée par la trésorerie pour affecter les soldes.
|
||||||
|
|
||||||
|
## Rapports
|
||||||
|
|
||||||
|
- L'état des résultats est intégré à la trésorerie.
|
||||||
|
- Le rapport PDF mensuel utilise l'état des résultats du mois précédent.
|
||||||
|
- Les positions de trésorerie du rapport PDF sont celles du dernier jour du mois précédent.
|
||||||
|
- Le registre PDF des décisions affiche `LE GROUPE A DÉCIDÉ DE` comme résolution lorsque ce champ existe.
|
||||||
|
- Le sommaire du registre de décisions ne doit pas être ajouté s'il n'apporte pas de valeur.
|
||||||
|
|
||||||
|
## Journal et historique
|
||||||
|
|
||||||
|
- Les actions modifiantes réussies sont journalisées.
|
||||||
|
- Le journal doit indiquer le membre ayant causé le changement.
|
||||||
|
- L'historique détaillé peut indiquer l'ancienne valeur et la nouvelle valeur.
|
||||||
|
- La raison de modification est déterminée automatiquement par l'application.
|
||||||
|
- Le journal doit être filtrable et lisible sous forme de tuiles.
|
||||||
|
|
||||||
|
## Notifications
|
||||||
|
|
||||||
|
- Les notifications sont optionnelles.
|
||||||
|
- Chaque membre choisit les catégories qui l'intéressent.
|
||||||
|
- Une action peut produire une notification selon son domaine.
|
||||||
|
|
||||||
|
## Mode papier et continuité
|
||||||
|
|
||||||
|
- Les rapports doivent soutenir l'impression format lettre.
|
||||||
|
- Le groupe doit pouvoir continuer une rencontre ou assemblée sans l'application.
|
||||||
|
- Les données papier peuvent être ressaisies plus tard.
|
||||||
|
|
||||||
140
docs/40_LIENS_CAUSALITE.md
Normal file
140
docs/40_LIENS_CAUSALITE.md
Normal file
|
|
@ -0,0 +1,140 @@
|
||||||
|
# Liens de causalité
|
||||||
|
|
||||||
|
Statut: référence fonctionnelle
|
||||||
|
Public: exécutifs, testeurs, mainteneurs
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Ce document décrit les effets attendus des actions importantes. Il sert à tester l'application, à comprendre les impacts indirects et à éviter de casser un processus en modifiant seulement une page.
|
||||||
|
|
||||||
|
## Rencontres
|
||||||
|
|
||||||
|
- Planifier une rencontre crée une tuile de rencontre.
|
||||||
|
- Modifier une rencontre met à jour la tuile et ses rapports.
|
||||||
|
- Saisir une collecte associe une collecte à la rencontre.
|
||||||
|
- Saisir une collecte crée un montant à recevoir par le trésorier.
|
||||||
|
- Le trésorier reçoit la collecte et augmente l'encaisse.
|
||||||
|
- La réception d'une collecte utilise la date de la collecte comme date comptable.
|
||||||
|
- Saisir une vente de littérature diminue le stock de littérature.
|
||||||
|
- Saisir une vente de littérature crée un montant à recevoir.
|
||||||
|
- Le trésorier reçoit la vente de littérature et augmente l'encaisse.
|
||||||
|
- Saisir une vente de jetons diminue le stock de jetons.
|
||||||
|
- Saisir une vente de jetons crée un montant à recevoir.
|
||||||
|
- Le trésorier reçoit la vente de jetons et augmente l'encaisse.
|
||||||
|
- Saisir une remise de jeton ou gâteau alimente les statistiques seulement.
|
||||||
|
- Une remise de jeton ou gâteau ne change pas l'inventaire.
|
||||||
|
- Le bouton `Rapport PDF` génère le rapport de la rencontre.
|
||||||
|
|
||||||
|
## Assemblées
|
||||||
|
|
||||||
|
- Planifier une assemblée crée une tuile d'assemblée.
|
||||||
|
- La date proposée respecte l'horaire d'assemblée configuré pour le groupe.
|
||||||
|
- Saisir les présences met à jour le rapport d'assemblée.
|
||||||
|
- Générer une invitation crée un lien invité temporaire.
|
||||||
|
- Ouvrir un lien invité affiche l'assemblée en lecture seule.
|
||||||
|
- Un lien invité expiré refuse l'accès.
|
||||||
|
- Le rapport PDF produit le procès-verbal ou rapport d'assemblée.
|
||||||
|
- Adopter le PV précédent cristallise son contenu.
|
||||||
|
- Adopter le PV précédent exige un proposeur et un secondeur.
|
||||||
|
- Adopter le rapport du trésorier exige un proposeur et un secondeur.
|
||||||
|
- Adopter le rapport du trésorier autorise ensuite les contributions.
|
||||||
|
- Un rapport du trésorier non adopté bloque le processus de contribution.
|
||||||
|
|
||||||
|
## Contributions
|
||||||
|
|
||||||
|
- Créer une contribution crée une décision de type `Contribution`.
|
||||||
|
- Créer une contribution exige un proposeur et un secondeur.
|
||||||
|
- Créer une contribution crée un montant engagé à débiter.
|
||||||
|
- Une contribution créée apparaît dans `Trésorerie > À traiter`.
|
||||||
|
- Une contribution traitée diminue le solde bancaire.
|
||||||
|
- Une contribution traitée apparaît au registre.
|
||||||
|
- Une contribution traitée met à jour l'état des résultats.
|
||||||
|
- Modifier la liste des destinataires change les choix offerts dans `Donner au suivant`.
|
||||||
|
- Supprimer un destinataire non protégé retire ce choix des prochaines contributions.
|
||||||
|
|
||||||
|
## Gouvernance
|
||||||
|
|
||||||
|
- Soumettre une proposition crée une proposition en cours.
|
||||||
|
- Une proposition sans secondeur peut être secondée.
|
||||||
|
- Une proposition secondée peut être transformée en décision.
|
||||||
|
- Rejeter une proposition exige `ÉTANT DONNÉ QUE`.
|
||||||
|
- Rejeter une proposition conserve l'historique.
|
||||||
|
- Transformer en résolution exige `ÉTANT DONNÉ QUE`.
|
||||||
|
- Transformer en résolution exige `LE GROUPE A DÉCIDÉ DE`.
|
||||||
|
- Transformer en résolution crée une décision de type `Résolution`.
|
||||||
|
- Accepter une nomination crée une décision de type `Nomination`.
|
||||||
|
- Créer une décision lui attribue un numéro selon son type.
|
||||||
|
- Créer une décision la rend visible dans l'historique des décisions.
|
||||||
|
- Créer une décision la rend visible dans le rapport PDF des résolutions.
|
||||||
|
- Renseigner `LE GROUPE A DÉCIDÉ DE` fait utiliser ce texte comme résolution principale dans le rapport.
|
||||||
|
|
||||||
|
## Postes et mandats
|
||||||
|
|
||||||
|
- Postuler à un poste crée une candidature.
|
||||||
|
- Proposer un membre à un poste crée une candidature pour ce membre.
|
||||||
|
- Une candidature acceptée ou une nomination alimente les décisions de type `Nomination`.
|
||||||
|
- Une nomination adoptée affecte le membre au poste.
|
||||||
|
- Affecter un membre à un poste retire ce poste des postes à pourvoir.
|
||||||
|
- Terminer un mandat libère le poste.
|
||||||
|
- Libérer un poste le rend de nouveau visible dans `Postes à pourvoir`.
|
||||||
|
- Associer une permission à un poste contrôle l'accès aux modules.
|
||||||
|
- Changer les permissions d'un poste change les modules visibles pour les membres qui occupent ce poste.
|
||||||
|
- Abolir un poste le retire des listes ordinaires.
|
||||||
|
- Réactiver un poste peut le remettre dans les postes disponibles si aucun mandat actif ne l'occupe.
|
||||||
|
|
||||||
|
## Trésorerie
|
||||||
|
|
||||||
|
- Recevoir une collecte augmente l'encaisse.
|
||||||
|
- Recevoir une vente augmente l'encaisse.
|
||||||
|
- Déposer de l'encaisse à la banque diminue l'encaisse.
|
||||||
|
- Déposer de l'encaisse à la banque augmente le solde bancaire.
|
||||||
|
- Enregistrer un don direct augmente le solde bancaire sans diminuer l'encaisse.
|
||||||
|
- Soumettre une dépense la fait apparaître dans `À traiter`.
|
||||||
|
- Traiter une dépense cash diminue immédiatement l'encaisse.
|
||||||
|
- Traiter une dépense par chèque ou virement engage le solde bancaire.
|
||||||
|
- Confirmer le débit d'une dépense par chèque ou virement diminue le solde bancaire.
|
||||||
|
- Rejeter une dépense efface la demande comme si elle n'avait jamais existé.
|
||||||
|
- Créer une réserve ajoute une réserve à zéro.
|
||||||
|
- Virer vers une réserve diminue le disponible bancaire.
|
||||||
|
- Virer depuis une réserve augmente le disponible bancaire ou une autre réserve.
|
||||||
|
- Supprimer une réserve est permis seulement si son solde est zéro.
|
||||||
|
- La somme des réserves ne doit pas dépasser le solde bancaire disponible pour les couvrir.
|
||||||
|
- Le disponible bancaire est le solde bancaire moins engagements et réserves.
|
||||||
|
- L'encaisse est disponible pour le groupe, mais elle reste une position séparée de la banque.
|
||||||
|
- Un mouvement de réserve apparaît au registre.
|
||||||
|
- Le registre affiche les transactions les plus récentes d'abord.
|
||||||
|
|
||||||
|
## Rapports
|
||||||
|
|
||||||
|
- L'état des résultats calcule revenus, charges et résultat net.
|
||||||
|
- Le rapport PDF de trésorerie utilise le mois précédent.
|
||||||
|
- Le rapport PDF de trésorerie utilise les positions au dernier jour du mois précédent.
|
||||||
|
- Un rapport adopté devient historisé et cristallisé.
|
||||||
|
- Un rapport adopté reste consultable et imprimable.
|
||||||
|
- Le registre PDF des résolutions affiche les décisions du groupe.
|
||||||
|
- Une résolution avec `LE GROUPE A DÉCIDÉ DE` utilise cette section comme texte principal du rapport.
|
||||||
|
|
||||||
|
## Sécurité et accès
|
||||||
|
|
||||||
|
- Sysadmin a tous les accès.
|
||||||
|
- Sysadmin ne peut pas être supprimé.
|
||||||
|
- Sysadmin peut impersonifier un membre.
|
||||||
|
- Sysadmin peut saisir des informations à posteriori.
|
||||||
|
- Un exécutif peut créer des membres, planifier des assemblées et traiter les décisions.
|
||||||
|
- Un non-exécutif ne voit pas les actions réservées.
|
||||||
|
- Un invité peut consulter seulement le lien prévu.
|
||||||
|
- Un invité ne peut rien modifier.
|
||||||
|
- Un lien invité expiré refuse l'accès.
|
||||||
|
- Désactiver un membre bloque la connexion sans effacer son historique.
|
||||||
|
- Le droit à l'oubli anonymise le membre sans supprimer son enregistrement.
|
||||||
|
|
||||||
|
## Audit et persistance
|
||||||
|
|
||||||
|
- Toute modification importante crée une entrée au journal ou dans l'historique métier.
|
||||||
|
- L'historique métier peut conserver l'ancienne valeur, la nouvelle valeur, le membre responsable et une raison automatique.
|
||||||
|
- Rafraîchir la page conserve les données.
|
||||||
|
- Déconnexion et reconnexion conservent les données.
|
||||||
|
- Redéployer conserve les données existantes.
|
||||||
|
- Réinitialiser un groupe remet les données de ce groupe à leur base initiale.
|
||||||
|
- Réinitialiser `Groupe Démonstration` recrée un historique fictif cohérent.
|
||||||
|
- Réinitialiser un groupe ne doit pas modifier les autres groupes.
|
||||||
|
|
||||||
111
docs/50_MODELE_DONNEES.md
Normal file
111
docs/50_MODELE_DONNEES.md
Normal file
|
|
@ -0,0 +1,111 @@
|
||||||
|
# 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.
|
||||||
|
|
||||||
167
docs/60_ARCHITECTURE.md
Normal file
167
docs/60_ARCHITECTURE.md
Normal file
|
|
@ -0,0 +1,167 @@
|
||||||
|
# Architecture technique
|
||||||
|
|
||||||
|
Statut: référence technique
|
||||||
|
Public: mainteneurs, exploitants
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
## Vue d'ensemble
|
||||||
|
|
||||||
|
L'application est composée de quatre couches:
|
||||||
|
|
||||||
|
- frontend PWA React;
|
||||||
|
- API FastAPI;
|
||||||
|
- base PostgreSQL;
|
||||||
|
- déploiement systemd, NGINX et Ansible.
|
||||||
|
|
||||||
|
Le frontend ne contient pas les règles d'autorisation finales. Il adapte l'interface selon les modules retournés par l'API, mais le backend reste responsable de refuser les actions non permises.
|
||||||
|
|
||||||
|
## Frontend
|
||||||
|
|
||||||
|
Emplacement: `frontend/src`.
|
||||||
|
|
||||||
|
Éléments principaux:
|
||||||
|
|
||||||
|
- `App.jsx`: routeur applicatif côté client;
|
||||||
|
- `stores/store.js`: état global Zustand, session, groupe courant, modules;
|
||||||
|
- `stores/api.js`: client HTTP et gestion du token;
|
||||||
|
- `components/PageHeader.jsx`: entête commun des pages authentifiées;
|
||||||
|
- `components/BottomNav.jsx`: navigation par contextes;
|
||||||
|
- `pages/`: écrans fonctionnels;
|
||||||
|
- `features/assemblees/`: composants et helpers propres aux assemblées;
|
||||||
|
- `utils/datesReunion.js`: logique de dates de rencontres;
|
||||||
|
- `utils/pushNotifications.js`: abonnement push.
|
||||||
|
|
||||||
|
Conventions:
|
||||||
|
|
||||||
|
- les pages protégées sont sélectionnées par code de module;
|
||||||
|
- la barre de navigation du bas n'apparaît que sur l'accueil;
|
||||||
|
- les tuiles expansibles sont le motif principal pour rencontres, assemblées, décisions, postes et journal;
|
||||||
|
- les pages doivent rester utilisables sur petit téléphone.
|
||||||
|
|
||||||
|
## Backend
|
||||||
|
|
||||||
|
Emplacement: `backend/app`.
|
||||||
|
|
||||||
|
Éléments principaux:
|
||||||
|
|
||||||
|
- `main.py`: application FastAPI, middleware, montage des routers, migrations légères au démarrage;
|
||||||
|
- `core/`: sécurité, rôles, audit, concurrence, finances, décisions, configuration;
|
||||||
|
- `models/`: modèles SQLAlchemy et tables;
|
||||||
|
- `routers/`: endpoints API;
|
||||||
|
- `schemas/`: contrats Pydantic;
|
||||||
|
- `services/`: logique métier réutilisable.
|
||||||
|
|
||||||
|
Règle de maintenance:
|
||||||
|
|
||||||
|
- un router orchestre une action HTTP;
|
||||||
|
- une règle métier partagée va dans `services/` ou `core/`;
|
||||||
|
- un router ne doit pas importer un autre router pour réutiliser sa logique.
|
||||||
|
|
||||||
|
## Authentification et session
|
||||||
|
|
||||||
|
Le membre se connecte par groupe, identifiant/courriel et PIN. Le backend émet un JWT contenant:
|
||||||
|
|
||||||
|
- `sub`: membre courant;
|
||||||
|
- `groupe_id`: groupe courant;
|
||||||
|
- `adm`: sysadmin d'origine lors d'une impersonification.
|
||||||
|
|
||||||
|
Les routes authentifiées récupèrent le membre courant depuis le token. Les données doivent toujours être filtrées par `membre.groupe_id`.
|
||||||
|
|
||||||
|
## Permissions
|
||||||
|
|
||||||
|
Les accès sont déterminés par:
|
||||||
|
|
||||||
|
- les affectations actives du membre;
|
||||||
|
- la catégorie du poste (`executif`, `service`, `physique`);
|
||||||
|
- les permissions de modules associées aux postes;
|
||||||
|
- le statut spécial `Sysadmin`.
|
||||||
|
|
||||||
|
Les modules visibles sont calculés par `/api/accueil/`.
|
||||||
|
|
||||||
|
## Multi-groupe
|
||||||
|
|
||||||
|
Chaque table métier doit avoir un `groupe_id`, ou être reliée à une table parent qui en a un. Une route recevant un identifiant client doit vérifier que l'objet appartient au groupe courant avant lecture ou modification.
|
||||||
|
|
||||||
|
Voir [Multi-groupe](93_MULTI_GROUPE.md).
|
||||||
|
|
||||||
|
## Journalisation
|
||||||
|
|
||||||
|
`AuditMiddleware` journalise les méthodes mutantes réussies (`POST`, `PUT`, `PATCH`, `DELETE`) sous `/api/`.
|
||||||
|
|
||||||
|
Les journaux techniques sont conservés dans `journal_actions`. Les changements métier détaillés peuvent aussi être enregistrés dans `historique_modifications`, avec ancienne valeur, nouvelle valeur, membre responsable et raison automatique.
|
||||||
|
|
||||||
|
## Notifications
|
||||||
|
|
||||||
|
Les notifications push sont optionnelles. Le backend mappe les chemins API vers des catégories (`gouvernance`, `tresorerie`, `membres`, `postes`, `rencontres`, `litterature`, `evenements`, `systeme`) et notifie les membres abonnés selon leurs préférences.
|
||||||
|
|
||||||
|
## Finances
|
||||||
|
|
||||||
|
La source de vérité financière est `transactions_comptables`.
|
||||||
|
|
||||||
|
Conventions:
|
||||||
|
|
||||||
|
- `compte = banque` ou `encaisse`;
|
||||||
|
- `sens = debit` augmente le compte;
|
||||||
|
- `sens = credit` diminue le compte;
|
||||||
|
- `source_table` et `source_id` relient l'écriture à l'objet métier.
|
||||||
|
|
||||||
|
Les réserves sont historisées dans `mouvements_reserves`. Le solde courant de `reserves` ne doit pas devenir la seule source de vérité.
|
||||||
|
|
||||||
|
## Décisions
|
||||||
|
|
||||||
|
Les propositions et décisions partagent la table `propositions`.
|
||||||
|
|
||||||
|
Une proposition devient une décision lorsque les champs de décision sont renseignés:
|
||||||
|
|
||||||
|
- `type_decision`;
|
||||||
|
- `date_adoption`;
|
||||||
|
- `numero_resolution`;
|
||||||
|
- `etant_donne_que`;
|
||||||
|
- `groupe_a_decide_de`.
|
||||||
|
|
||||||
|
La numérotation est produite par `core/decisions.py`.
|
||||||
|
|
||||||
|
## Rapports PDF
|
||||||
|
|
||||||
|
Les PDF sont produits côté backend avec WeasyPrint. Les rapports importants doivent rester imprimables en format lettre et utilisables comme reprise papier.
|
||||||
|
|
||||||
|
## Déploiement
|
||||||
|
|
||||||
|
La voie supportée est Ansible. Le playbook installe:
|
||||||
|
|
||||||
|
- paquets système;
|
||||||
|
- PostgreSQL;
|
||||||
|
- backend Python;
|
||||||
|
- frontend compilé;
|
||||||
|
- service systemd;
|
||||||
|
- NGINX;
|
||||||
|
- sauvegardes.
|
||||||
|
|
||||||
|
Voir [Déploiement Ansible](91_DEPLOIEMENT_ANSIBLE.md).
|
||||||
|
|
||||||
|
## Initialisation
|
||||||
|
|
||||||
|
`deploy/seed.py` crée le schéma et initialise `Groupe Démonstration`. Une VM vanille ne crée plus de groupe réel par défaut.
|
||||||
|
|
||||||
|
Le groupe de démonstration contient:
|
||||||
|
|
||||||
|
- `Sysadmin` avec PIN `0000`;
|
||||||
|
- postes et permissions de base;
|
||||||
|
- littérature;
|
||||||
|
- 12 mois d'activité fictive crédible.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
Tests actuellement présents:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
.venv/bin/python -m pytest backend/tests/test_business_rules.py
|
||||||
|
```
|
||||||
|
|
||||||
|
Build frontend:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd frontend
|
||||||
|
npm run build
|
||||||
|
```
|
||||||
|
|
||||||
206
docs/70_API.md
Normal file
206
docs/70_API.md
Normal file
|
|
@ -0,0 +1,206 @@
|
||||||
|
# API applicative
|
||||||
|
|
||||||
|
Statut: référence technique
|
||||||
|
Public: mainteneurs, intégrateurs
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Toutes les routes applicatives sont préfixées par `/api`. Les routes protégées exigent un JWT valide. Sauf mention contraire, les routes doivent agir uniquement dans le groupe du membre courant.
|
||||||
|
|
||||||
|
## Authentification et accueil
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `GET /api/auth/health` | Vérifier l'accès DB côté auth. |
|
||||||
|
| `GET /api/auth/groupes` | Lister les groupes disponibles et initialiser le groupe de démonstration au besoin. |
|
||||||
|
| `POST /api/auth/connexion` | Ouvrir une session. |
|
||||||
|
| `POST /api/auth/impersoner/{membre_id}` | Sysadmin agit au nom d'un membre. |
|
||||||
|
| `POST /api/auth/inscription` | Inscrire un membre avec invitation. |
|
||||||
|
| `GET /api/accueil/` | Retourner membre, groupe, postes et modules visibles. |
|
||||||
|
| `GET /api/health` | Santé globale de l'API. |
|
||||||
|
|
||||||
|
## Administration sysadmin
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `POST /api/admin/sysadmin-login` | Connexion sysadmin depuis la page publique. |
|
||||||
|
| `POST /api/admin/demo` | Créer le groupe de démonstration si absent. |
|
||||||
|
| `POST /api/admin/demo/reset` | Réinitialiser les données fictives de démonstration. |
|
||||||
|
| `GET /api/admin/groupes` | Lister les groupes avec compteurs. |
|
||||||
|
| `POST /api/admin/groupes` | Créer un groupe. |
|
||||||
|
| `PATCH /api/admin/groupes/{groupe_id}` | Modifier un groupe. |
|
||||||
|
| `POST /api/admin/groupes/{groupe_id}/reset` | Réinitialiser un groupe. |
|
||||||
|
| `DELETE /api/admin/groupes/{groupe_id}` | Supprimer un groupe non protégé. |
|
||||||
|
|
||||||
|
## Membres et invitations
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `GET /api/membres/moi` | Profil complet du membre courant. |
|
||||||
|
| `PATCH /api/membres/moi` | Modifier son profil. |
|
||||||
|
| `POST /api/membres/moi/pin` | Changer son PIN. |
|
||||||
|
| `GET /api/membres/actifs` | Liste des membres actifs. |
|
||||||
|
| `GET /api/membres/` | Liste de gestion des membres. |
|
||||||
|
| `POST /api/membres/` | Créer un membre. |
|
||||||
|
| `PATCH /api/membres/{membre_id}/desactiver` | Désactiver la connexion. |
|
||||||
|
| `PATCH /api/membres/{membre_id}/reactiver` | Réactiver la connexion. |
|
||||||
|
| `DELETE /api/membres/{membre_id}/oubli` | Anonymiser par droit à l'oubli. |
|
||||||
|
| `POST /api/invitations/` | Générer une invitation. |
|
||||||
|
|
||||||
|
## Rencontres
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `POST /api/reunions/` | Planifier une rencontre ou assemblée. |
|
||||||
|
| `GET /api/reunions/` | Lister les réunions. |
|
||||||
|
| `GET /api/reunions/rencontres/details` | Données enrichies des tuiles de rencontres. |
|
||||||
|
| `PATCH /api/reunions/{reunion_id}` | Modifier une rencontre. |
|
||||||
|
| `GET /api/reunions/{reunion_id}` | Lire une rencontre. |
|
||||||
|
| `GET /api/reunions/{reunion_id}/rapport.pdf` | Produire le rapport PDF de rencontre. |
|
||||||
|
|
||||||
|
## Assemblées et présences
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `POST /api/presences/reunion` | Créer une réunion d'affaires. |
|
||||||
|
| `GET /api/presences/reunions` | Lister les assemblées. |
|
||||||
|
| `POST /api/presences/reunions/{reunion_id}/invitation` | Générer le lien invité. |
|
||||||
|
| `GET /api/presences/invite/{code}` | Lecture invitée d'une assemblée. |
|
||||||
|
| `GET /api/presences/reunions/{reunion_id}/rapport.pdf` | Rapport PDF d'assemblée. |
|
||||||
|
| `POST /api/presences/` | Enregistrer les présences. |
|
||||||
|
| `GET /api/pv/` | Lister les PV. |
|
||||||
|
| `GET /api/pv/{pv_id}` | Lire un PV. |
|
||||||
|
| `POST /api/pv/` | Créer un PV. |
|
||||||
|
| `PATCH /api/pv/{pv_id}` | Corriger un PV. |
|
||||||
|
| `PATCH /api/pv/{pv_id}/adopter` | Adopter un PV. |
|
||||||
|
|
||||||
|
## Gouvernance
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `POST /api/propositions/` | Soumettre une proposition. |
|
||||||
|
| `POST /api/propositions/{proposition_id}/seconder` | Seconder ou seconder pour un autre membre. |
|
||||||
|
| `PATCH /api/propositions/{proposition_id}/voter` | Transformer ou rejeter selon le payload. |
|
||||||
|
| `GET /api/propositions/` | Lister propositions et réflexions. |
|
||||||
|
| `GET /api/propositions/resolutions` | Lister les décisions. |
|
||||||
|
|
||||||
|
## Trésorerie
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `POST /api/collectes/` | Créer une collecte. |
|
||||||
|
| `PATCH /api/collectes/{collecte_id}` | Modifier une collecte. |
|
||||||
|
| `POST /api/collectes/{collecte_id}/confirmer` | Confirmer une collecte. |
|
||||||
|
| `POST /api/collectes/{collecte_id}/reception` | Accuser réception. |
|
||||||
|
| `GET /api/collectes/` | Lister les collectes. |
|
||||||
|
| `GET /api/collectes/soldes` | Soldes et éléments à recevoir. |
|
||||||
|
| `GET /api/collectes/registre` | Registre financier agrégé. |
|
||||||
|
| `POST /api/depenses/` | Soumettre une dépense. |
|
||||||
|
| `POST /api/depenses/{depense_id}/preuve` | Ajouter une preuve. |
|
||||||
|
| `POST /api/depenses/{depense_id}/confirmer` | Confirmer une dépense selon l'ancien flux. |
|
||||||
|
| `POST /api/depenses/{depense_id}/confirmer-debit` | Confirmer le débit bancaire. |
|
||||||
|
| `DELETE /api/depenses/{depense_id}` | Rejeter ou supprimer une demande. |
|
||||||
|
| `GET /api/depenses/` | Lister les dépenses. |
|
||||||
|
| `GET /api/depenses/a-confirmer` | Lister les dépenses à traiter. |
|
||||||
|
| `PATCH /api/depenses/{depense_id}` | Modifier une dépense. |
|
||||||
|
| `POST /api/banque/` | Dépôt, retrait ou opération bancaire. |
|
||||||
|
| `GET /api/banque/reserves` | Lister les réserves. |
|
||||||
|
| `POST /api/banque/reserves` | Créer une réserve. |
|
||||||
|
| `PATCH /api/banque/reserves/{reserve_id}` | Renommer une réserve. |
|
||||||
|
| `DELETE /api/banque/reserves/{reserve_id}` | Supprimer une réserve à zéro. |
|
||||||
|
| `POST /api/banque/reserves/transfert` | Virer entre disponible et réserves. |
|
||||||
|
| `GET /api/banque/reserves/mouvements` | Historique des réserves. |
|
||||||
|
| `GET /api/banque/registre-comptable` | Registre comptable. |
|
||||||
|
| `GET /api/banque/` | Lister opérations bancaires. |
|
||||||
|
|
||||||
|
## Contributions
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `GET /api/contributions/destinataires` | Lister les destinataires. |
|
||||||
|
| `POST /api/contributions/destinataires` | Créer un destinataire. |
|
||||||
|
| `PATCH /api/contributions/destinataires/{destinataire_id}` | Modifier un destinataire. |
|
||||||
|
| `DELETE /api/contributions/destinataires/{destinataire_id}` | Supprimer un destinataire non protégé. |
|
||||||
|
| `POST /api/contributions/calculer` | Calculer une répartition. |
|
||||||
|
| `POST /api/contributions/` | Créer un envoi de contribution. |
|
||||||
|
| `POST /api/contributions/{envoi_id}/confirmer-debit` | Confirmer le débit. |
|
||||||
|
| `GET /api/contributions/` | Lister les contributions. |
|
||||||
|
| `GET /api/config-repartition/` | Lire la configuration. |
|
||||||
|
| `PUT /api/config-repartition/` | Modifier la répartition. |
|
||||||
|
|
||||||
|
## Postes, mandats et permissions
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `GET /api/postes/` | Lister les postes. |
|
||||||
|
| `POST /api/postes/` | Créer un poste. |
|
||||||
|
| `PATCH /api/postes/{poste_id}` | Modifier un poste. |
|
||||||
|
| `DELETE /api/postes/{poste_id}` | Abolir un poste. |
|
||||||
|
| `POST /api/postes/{poste_id}/reactiver` | Réactiver un poste. |
|
||||||
|
| `DELETE /api/postes/{poste_id}/permanent` | Supprimer définitivement. |
|
||||||
|
| `GET /api/postes/disponibles` | Postes à pourvoir. |
|
||||||
|
| `POST /api/postes/candidatures` | Postuler. |
|
||||||
|
| `POST /api/postes/candidatures/proposer` | Proposer un autre membre. |
|
||||||
|
| `POST /api/postes/candidatures/nominer` | Nomination directe. |
|
||||||
|
| `POST /api/postes/candidatures/{id}/retirer` | Retirer une candidature. |
|
||||||
|
| `POST /api/postes/candidatures/{id}/accepter-nomination` | Accepter une nomination. |
|
||||||
|
| `GET /api/postes/candidatures` | Lister les candidatures. |
|
||||||
|
| `GET /api/postes/candidatures/mes` | Mes candidatures. |
|
||||||
|
| `PATCH /api/postes/candidatures/{id}` | Traiter une candidature. |
|
||||||
|
| `GET /api/postes/affectations` | Affectations actives du membre. |
|
||||||
|
| `GET /api/postes/affectations/groupe` | Affectations du groupe. |
|
||||||
|
| `POST /api/postes/affectations` | Affecter un poste. |
|
||||||
|
| `POST /api/postes/affectations/{id}/terminer` | Terminer un mandat. |
|
||||||
|
| `GET /api/postes/modules` | Modules configurables. |
|
||||||
|
| `PUT /api/postes/{poste_id}/modules` | Modifier les permissions d'un poste. |
|
||||||
|
| `GET /api/rotations/` | Rotations planifiées. |
|
||||||
|
| `GET /api/rotations/historique` | Historique des rotations. |
|
||||||
|
| `POST /api/rotations/` | Créer une rotation. |
|
||||||
|
| `POST /api/rotations/batch` | Créer plusieurs rotations. |
|
||||||
|
| `DELETE /api/rotations/{rotation_id}` | Supprimer une rotation. |
|
||||||
|
|
||||||
|
## Inventaires, événements et rapports
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `GET /api/litterature/` | Lister la littérature. |
|
||||||
|
| `POST /api/litterature/` | Ajouter un titre. |
|
||||||
|
| `PATCH /api/litterature/{item_id}` | Modifier un titre. |
|
||||||
|
| `PATCH /api/litterature/{item_id}/stock` | Ajuster le stock. |
|
||||||
|
| `POST /api/ventes-litterature/` | Enregistrer une vente. |
|
||||||
|
| `GET /api/ventes-litterature/` | Lister les ventes. |
|
||||||
|
| `GET /api/ventes-litterature/a-recevoir` | Ventes à recevoir. |
|
||||||
|
| `POST /api/ventes-litterature/{vente_id}/recevoir` | Confirmer réception. |
|
||||||
|
| `GET /api/jetons/types` | Types de jetons. |
|
||||||
|
| `POST /api/jetons/` | Enregistrer une remise statistique. |
|
||||||
|
| `POST /api/jetons/ventes` | Enregistrer une vente de jetons. |
|
||||||
|
| `GET /api/jetons/ventes/a-recevoir` | Ventes de jetons à recevoir. |
|
||||||
|
| `POST /api/jetons/ventes/{vente_id}/recevoir` | Confirmer réception. |
|
||||||
|
| `GET /api/jetons/` | Historique des remises. |
|
||||||
|
| `GET /api/commandes-jetons/stock` | Stock de jetons. |
|
||||||
|
| `GET /api/evenements/` | Lister les événements. |
|
||||||
|
| `POST /api/evenements/` | Créer un événement. |
|
||||||
|
| `DELETE /api/evenements/{evenement_id}` | Supprimer un événement. |
|
||||||
|
| `GET /api/calendrier/` | Calendrier du groupe courant. |
|
||||||
|
| `GET /api/calendrier/groupe/{groupe_id}` | Calendrier public d'un groupe. |
|
||||||
|
| `GET /api/anniversaires/` | Anniversaires de sobriété. |
|
||||||
|
|
||||||
|
## Rapports, journal et notifications
|
||||||
|
|
||||||
|
| Route | Usage |
|
||||||
|
| --- | --- |
|
||||||
|
| `GET /api/rapports/disponibles` | Rapports disponibles. |
|
||||||
|
| `GET /api/rapports/resolutions/annees` | Années de décisions disponibles. |
|
||||||
|
| `GET /api/rapports/resolutions/{annee}` | Registre PDF des décisions. |
|
||||||
|
| `GET /api/rapports/etat-resultats/{annee}/{mois}` | PDF état des résultats. |
|
||||||
|
| `POST /api/rapports/etat-resultats/{annee}/{mois}/adopter` | Adopter un rapport du trésorier. |
|
||||||
|
| `GET /api/rapports/adoptes` | Rapports adoptés. |
|
||||||
|
| `GET /api/rapports/adoptes/{rapport_id}.pdf` | PDF cristallisé. |
|
||||||
|
| `GET /api/journal/actions` | Journal d'actions. |
|
||||||
|
| `GET /api/journal/historique` | Historique détaillé. |
|
||||||
|
| `GET /api/notifications/configuration` | Configuration push. |
|
||||||
|
| `GET /api/notifications/preferences` | Préférences du membre. |
|
||||||
|
| `PATCH /api/notifications/preferences` | Modifier les préférences. |
|
||||||
|
| `POST /api/notifications/abonnement` | Enregistrer un abonnement push. |
|
||||||
|
| `DELETE /api/notifications/abonnement` | Supprimer un abonnement push. |
|
||||||
|
| `POST /api/notifications/test` | Tester une notification. |
|
||||||
|
|
||||||
163
docs/80_SECURITE.md
Normal file
163
docs/80_SECURITE.md
Normal file
|
|
@ -0,0 +1,163 @@
|
||||||
|
# Sécurité et confidentialité
|
||||||
|
|
||||||
|
Statut: référence opérationnelle
|
||||||
|
Public: exploitants, sysadmin, mainteneurs, exécutifs
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
## Principes
|
||||||
|
|
||||||
|
L'application doit minimiser les données personnelles, isoler les groupes et permettre au groupe de comprendre qui a changé quoi. Le journal ne sert pas à surveiller les membres; il sert à protéger l'historique et corriger les erreurs.
|
||||||
|
|
||||||
|
## Authentification
|
||||||
|
|
||||||
|
- Connexion par groupe, identifiant/courriel et PIN à 4 chiffres.
|
||||||
|
- PIN haché côté serveur.
|
||||||
|
- Session JWT.
|
||||||
|
- Durée normale: 30 jours.
|
||||||
|
- Durée avec `Se souvenir de moi`: 90 jours.
|
||||||
|
- Un membre inactif ne peut pas se connecter.
|
||||||
|
|
||||||
|
## Sysadmin
|
||||||
|
|
||||||
|
Le compte `Sysadmin`:
|
||||||
|
|
||||||
|
- existe au déploiement initial;
|
||||||
|
- a tous les accès;
|
||||||
|
- ne doit pas être supprimé;
|
||||||
|
- peut impersonifier un membre;
|
||||||
|
- peut gérer les groupes;
|
||||||
|
- doit être utilisé avec retenue.
|
||||||
|
|
||||||
|
Le PIN initial `0000` doit être changé ou encadré selon la politique du groupe après installation réelle.
|
||||||
|
|
||||||
|
## Impersonification
|
||||||
|
|
||||||
|
Quand Sysadmin agit comme un autre membre, le jeton conserve l'identité sysadmin dans `adm`. La journalisation peut donc distinguer:
|
||||||
|
|
||||||
|
- le membre au nom duquel l'action est faite;
|
||||||
|
- le sysadmin qui a causé l'action.
|
||||||
|
|
||||||
|
## Autorisations
|
||||||
|
|
||||||
|
Les accès ordinaires viennent:
|
||||||
|
|
||||||
|
- des postes actifs;
|
||||||
|
- des permissions de modules associées aux postes;
|
||||||
|
- de la catégorie `executif`.
|
||||||
|
|
||||||
|
Le frontend masque les modules non visibles, mais le backend doit toujours vérifier l'autorisation.
|
||||||
|
|
||||||
|
## Isolation multi-groupe
|
||||||
|
|
||||||
|
Chaque lecture ou modification doit être bornée au `groupe_id` du membre courant. Une route qui reçoit un identifiant doit vérifier l'appartenance de l'objet au groupe courant.
|
||||||
|
|
||||||
|
Voir [Multi-groupe](93_MULTI_GROUPE.md).
|
||||||
|
|
||||||
|
## Journalisation
|
||||||
|
|
||||||
|
Sont journalisées automatiquement:
|
||||||
|
|
||||||
|
- méthodes `POST`, `PUT`, `PATCH`, `DELETE`;
|
||||||
|
- routes sous `/api/`;
|
||||||
|
- actions réussies;
|
||||||
|
- membre;
|
||||||
|
- sysadmin d'origine si impersonification;
|
||||||
|
- chemin;
|
||||||
|
- statut HTTP;
|
||||||
|
- IP;
|
||||||
|
- user-agent;
|
||||||
|
- paramètres sûrs.
|
||||||
|
|
||||||
|
L'historique métier peut conserver:
|
||||||
|
|
||||||
|
- domaine;
|
||||||
|
- objet;
|
||||||
|
- ancienne valeur;
|
||||||
|
- nouvelle valeur;
|
||||||
|
- raison automatique;
|
||||||
|
- membre responsable.
|
||||||
|
|
||||||
|
## Données personnelles
|
||||||
|
|
||||||
|
Données membres typiques:
|
||||||
|
|
||||||
|
- prénom;
|
||||||
|
- nom optionnel;
|
||||||
|
- téléphone;
|
||||||
|
- identifiant/courriel;
|
||||||
|
- date d'abstinence optionnelle;
|
||||||
|
- PIN haché;
|
||||||
|
- préférences de notifications.
|
||||||
|
|
||||||
|
Le prénom est conservé lors du droit à l'oubli afin que l'historique reste lisible.
|
||||||
|
|
||||||
|
## Droit à l'oubli
|
||||||
|
|
||||||
|
Le droit à l'oubli ne supprime pas l'enregistrement du membre. Il anonymise:
|
||||||
|
|
||||||
|
- nom;
|
||||||
|
- téléphone;
|
||||||
|
- courriel ou identifiant de connexion;
|
||||||
|
- date d'abstinence;
|
||||||
|
- PIN;
|
||||||
|
- préférences;
|
||||||
|
- abonnements push.
|
||||||
|
|
||||||
|
Sont conservés:
|
||||||
|
|
||||||
|
- ID technique;
|
||||||
|
- prénom;
|
||||||
|
- relations historiques.
|
||||||
|
|
||||||
|
## Notifications push
|
||||||
|
|
||||||
|
Les notifications sont opt-in. Le membre choisit les catégories. Le navigateur peut refuser ou bloquer les notifications.
|
||||||
|
|
||||||
|
Les catégories applicatives sont:
|
||||||
|
|
||||||
|
- gouvernance;
|
||||||
|
- trésorerie;
|
||||||
|
- membres;
|
||||||
|
- postes;
|
||||||
|
- rencontres;
|
||||||
|
- littérature;
|
||||||
|
- événements;
|
||||||
|
- système.
|
||||||
|
|
||||||
|
## Secrets
|
||||||
|
|
||||||
|
Les secrets ne doivent pas être committés en clair.
|
||||||
|
|
||||||
|
Secrets principaux:
|
||||||
|
|
||||||
|
- mot de passe PostgreSQL applicatif;
|
||||||
|
- secret JWT;
|
||||||
|
- variables de notification push si utilisées;
|
||||||
|
- accès SSH Ansible.
|
||||||
|
|
||||||
|
Le fichier `ansible/group_vars/vault.yml` doit être chiffré avec Ansible Vault lorsqu'il contient des valeurs réelles.
|
||||||
|
|
||||||
|
## Sauvegardes
|
||||||
|
|
||||||
|
Les sauvegardes PostgreSQL doivent être protégées comme des données personnelles. Elles contiennent l'historique complet du groupe.
|
||||||
|
|
||||||
|
## Points de fracture
|
||||||
|
|
||||||
|
Risques principaux:
|
||||||
|
|
||||||
|
- mauvais groupe sélectionné à la connexion;
|
||||||
|
- utilisation prolongée de `Sysadmin`;
|
||||||
|
- permissions trop larges accordées à un poste;
|
||||||
|
- sauvegardes non testées;
|
||||||
|
- perte d'accès au serveur;
|
||||||
|
- conflit social autour du journal;
|
||||||
|
- absence de reprise papier.
|
||||||
|
|
||||||
|
Mesures:
|
||||||
|
|
||||||
|
- vérifier régulièrement les permissions;
|
||||||
|
- imprimer ou savoir produire les rapports clés;
|
||||||
|
- tester les sauvegardes;
|
||||||
|
- expliquer le rôle du journal;
|
||||||
|
- garder l'application comme outil, pas comme autorité.
|
||||||
|
|
||||||
142
docs/90_EXPLOITATION.md
Normal file
142
docs/90_EXPLOITATION.md
Normal file
|
|
@ -0,0 +1,142 @@
|
||||||
|
# Administration et exploitation
|
||||||
|
|
||||||
|
Statut: runbook opérationnel
|
||||||
|
Public: exploitants, sysadmin, exécutifs responsables
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
## Vérifier l'état du service
|
||||||
|
|
||||||
|
Sur la VM:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
systemctl status groupe-meditation
|
||||||
|
systemctl status nginx
|
||||||
|
```
|
||||||
|
|
||||||
|
Depuis le poste Ansible:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible-playbook ansible/verify.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vérifier l'API
|
||||||
|
|
||||||
|
```bash
|
||||||
|
curl http://127.0.0.1:8000/api/health
|
||||||
|
```
|
||||||
|
|
||||||
|
Réponse attendue:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{"status":"ok","app":"Groupe Méditation","version":"0.1.0"}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Redémarrer
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo systemctl restart groupe-meditation
|
||||||
|
sudo systemctl reload nginx
|
||||||
|
```
|
||||||
|
|
||||||
|
## Lire les journaux système
|
||||||
|
|
||||||
|
```bash
|
||||||
|
journalctl -u groupe-meditation -n 200 --no-pager
|
||||||
|
journalctl -u nginx -n 100 --no-pager
|
||||||
|
```
|
||||||
|
|
||||||
|
## Sauvegarder
|
||||||
|
|
||||||
|
Depuis le poste de contrôle:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible-playbook ansible/backup-now.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
Les sauvegardes contiennent des données personnelles et doivent être protégées.
|
||||||
|
|
||||||
|
## Redéployer
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git pull
|
||||||
|
ansible-playbook ansible/site.yml
|
||||||
|
ansible-playbook ansible/verify.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
## Installation vanille
|
||||||
|
|
||||||
|
Après installation sur une base vide:
|
||||||
|
|
||||||
|
- seul `Groupe Démonstration` est créé automatiquement;
|
||||||
|
- le compte `sysadmin` existe;
|
||||||
|
- le PIN initial est `0000`;
|
||||||
|
- les données fictives servent à la formation.
|
||||||
|
|
||||||
|
## Gestion des groupes
|
||||||
|
|
||||||
|
1. Ouvrir l'application.
|
||||||
|
2. Sur la page de sélection des groupes, cliquer `Sysadmin`.
|
||||||
|
3. Entrer le PIN sysadmin.
|
||||||
|
4. Ouvrir `Gestion des groupes`.
|
||||||
|
|
||||||
|
Actions:
|
||||||
|
|
||||||
|
- créer un groupe;
|
||||||
|
- modifier un groupe;
|
||||||
|
- supprimer un groupe non protégé;
|
||||||
|
- réinitialiser un groupe avec le bouton `Réinit`;
|
||||||
|
- réinitialiser les données fictives du groupe de démonstration.
|
||||||
|
|
||||||
|
## Problème de cache navigateur
|
||||||
|
|
||||||
|
Si un membre se fait déconnecter immédiatement ou ne voit pas les changements:
|
||||||
|
|
||||||
|
1. Tester en navigation privée.
|
||||||
|
2. Forcer le rafraîchissement.
|
||||||
|
3. Supprimer les données du site dans le navigateur.
|
||||||
|
4. Vérifier que le service worker PWA n'a pas conservé une ancienne version.
|
||||||
|
|
||||||
|
## Problème de connexion
|
||||||
|
|
||||||
|
Vérifier:
|
||||||
|
|
||||||
|
- bon groupe sélectionné;
|
||||||
|
- identifiant/courriel exact;
|
||||||
|
- PIN de 4 chiffres;
|
||||||
|
- membre actif;
|
||||||
|
- absence d'impersonification confuse;
|
||||||
|
- heure serveur raisonnable pour les tokens.
|
||||||
|
|
||||||
|
## Problème de trésorerie
|
||||||
|
|
||||||
|
Vérifier dans cet ordre:
|
||||||
|
|
||||||
|
1. Registre comptable.
|
||||||
|
2. Collectes et ventes non reçues.
|
||||||
|
3. Dépenses à traiter.
|
||||||
|
4. Contributions non débitées.
|
||||||
|
5. Mouvements de réserves.
|
||||||
|
6. Opérations bancaires.
|
||||||
|
|
||||||
|
Les soldes doivent être expliqués par les écritures, pas modifiés directement.
|
||||||
|
|
||||||
|
## Problème de permissions
|
||||||
|
|
||||||
|
Vérifier:
|
||||||
|
|
||||||
|
- affectations actives du membre;
|
||||||
|
- catégorie du poste;
|
||||||
|
- permissions du poste dans `Gestion des postes`;
|
||||||
|
- présence du module dans `/api/accueil/`;
|
||||||
|
- statut sysadmin si applicable.
|
||||||
|
|
||||||
|
## Reprise papier
|
||||||
|
|
||||||
|
Si l'application est indisponible:
|
||||||
|
|
||||||
|
1. Continuer la rencontre ou l'assemblée sur papier.
|
||||||
|
2. Identifier date, responsable, montants et décisions.
|
||||||
|
3. Faire adopter comme d'habitude si requis.
|
||||||
|
4. Ressaisir les données lorsque l'application revient.
|
||||||
|
5. Conserver les notes papier jusqu'à vérification.
|
||||||
|
|
||||||
146
docs/91_DEPLOIEMENT_ANSIBLE.md
Normal file
146
docs/91_DEPLOIEMENT_ANSIBLE.md
Normal file
|
|
@ -0,0 +1,146 @@
|
||||||
|
# Déploiement Ansible
|
||||||
|
|
||||||
|
Statut: procédure supportée
|
||||||
|
Public: exploitants, sysadmin technique
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Ce dépôt peut installer l'application sur une Debian vanille avec un compte `ansible` sudoer sans mot de passe.
|
||||||
|
|
||||||
|
Le playbook installe:
|
||||||
|
|
||||||
|
- dépendances système;
|
||||||
|
- PostgreSQL;
|
||||||
|
- backend FastAPI;
|
||||||
|
- frontend compilé;
|
||||||
|
- service systemd;
|
||||||
|
- NGINX local;
|
||||||
|
- sauvegardes quotidiennes;
|
||||||
|
- certificat Let's Encrypt si activé.
|
||||||
|
|
||||||
|
## Pré-requis poste de contrôle
|
||||||
|
|
||||||
|
```bash
|
||||||
|
python3 -m pip install --user ansible
|
||||||
|
ansible-galaxy collection install -r ansible/requirements.yml
|
||||||
|
node --version
|
||||||
|
npm --version
|
||||||
|
```
|
||||||
|
|
||||||
|
Node.js 20 ou plus récent est recommandé pour construire le frontend.
|
||||||
|
|
||||||
|
## Accès SSH
|
||||||
|
|
||||||
|
L'inventaire référence explicitement la clé:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
~/.ssh/id_ed25519_ansible_chezlepro
|
||||||
|
```
|
||||||
|
|
||||||
|
Préparation type:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_ansible_chezlepro -C "ansible@chezlepro"
|
||||||
|
ssh-copy-id -i ~/.ssh/id_ed25519_ansible_chezlepro.pub ansible@ADRESSE_IP_VM
|
||||||
|
ssh -i ~/.ssh/id_ed25519_ansible_chezlepro ansible@ADRESSE_IP_VM
|
||||||
|
```
|
||||||
|
|
||||||
|
## Inventaire
|
||||||
|
|
||||||
|
Fichier:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible/inventory/hosts.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
Vérifier:
|
||||||
|
|
||||||
|
- `ansible_host`;
|
||||||
|
- `ansible_user`;
|
||||||
|
- `ansible_ssh_private_key_file`.
|
||||||
|
|
||||||
|
## Variables
|
||||||
|
|
||||||
|
Variables non secrètes:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible/group_vars/all.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
Secrets:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible/group_vars/vault.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
Créer depuis l'exemple:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cp ansible/group_vars/vault.yml.example ansible/group_vars/vault.yml
|
||||||
|
openssl rand -base64 48
|
||||||
|
nano ansible/group_vars/vault.yml
|
||||||
|
ansible-vault encrypt ansible/group_vars/vault.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
Le fichier de secrets doit contenir au minimum:
|
||||||
|
|
||||||
|
- `groupe_meditation_db_password`;
|
||||||
|
- `groupe_meditation_jwt_secret`.
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
Depuis la racine:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible-playbook ansible/site.yml --ask-vault-pass
|
||||||
|
```
|
||||||
|
|
||||||
|
Si le vault local n'est pas chiffré dans un contexte de développement, l'option `--ask-vault-pass` peut être omise.
|
||||||
|
|
||||||
|
## Vérification
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible-playbook ansible/verify.yml --ask-vault-pass
|
||||||
|
```
|
||||||
|
|
||||||
|
Vérification directe de l'API:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible groupe-meditation-prod -m uri -a 'url=http://127.0.0.1:8000/api/health return_content=true status_code=200' -o
|
||||||
|
```
|
||||||
|
|
||||||
|
Vérification des groupes publics:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible groupe-meditation-prod -m uri -a 'url=http://127.0.0.1:8000/api/auth/groupes return_content=true status_code=200' -o
|
||||||
|
```
|
||||||
|
|
||||||
|
## Initialisation de la base
|
||||||
|
|
||||||
|
Le seed ne crée qu'un groupe de démonstration:
|
||||||
|
|
||||||
|
- nom: `Groupe Démonstration`;
|
||||||
|
- compte: `sysadmin`;
|
||||||
|
- PIN initial: `0000`;
|
||||||
|
- historique fictif crédible.
|
||||||
|
|
||||||
|
Le playbook ne relance le seed que si la base est absente ou vide selon les tests du rôle applicatif.
|
||||||
|
|
||||||
|
## Redéploiement
|
||||||
|
|
||||||
|
Le playbook est conçu pour être relancé. Il synchronise le code, reconstruit le frontend, redémarre le service et laisse les données existantes intactes.
|
||||||
|
|
||||||
|
## Sauvegarde manuelle
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible-playbook ansible/backup-now.yml --ask-vault-pass
|
||||||
|
```
|
||||||
|
|
||||||
|
## NGINX
|
||||||
|
|
||||||
|
L'application installe un NGINX local sur la VM. Il sert:
|
||||||
|
|
||||||
|
- le frontend statique;
|
||||||
|
- le reverse proxy vers l'API FastAPI locale.
|
||||||
|
|
||||||
|
Un proxy externe peut gérer TLS et relayer vers cette VM en HTTP.
|
||||||
|
|
||||||
41
docs/92_DEPLOIEMENT.md
Normal file
41
docs/92_DEPLOIEMENT.md
Normal file
|
|
@ -0,0 +1,41 @@
|
||||||
|
# Déploiement
|
||||||
|
|
||||||
|
Statut: point d'entrée opérationnel
|
||||||
|
Public: exploitants
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
La méthode supportée est Ansible. Voir [Déploiement Ansible](91_DEPLOIEMENT_ANSIBLE.md).
|
||||||
|
|
||||||
|
## Résumé
|
||||||
|
|
||||||
|
1. Préparer une Debian vanille.
|
||||||
|
2. Créer un compte `ansible` sudoer sans mot de passe.
|
||||||
|
3. Installer la clé SSH prévue par l'inventaire.
|
||||||
|
4. Ajuster `ansible/inventory/hosts.yml`.
|
||||||
|
5. Vérifier les variables dans `ansible/group_vars/all.yml`.
|
||||||
|
6. Créer et chiffrer `ansible/group_vars/vault.yml` si secrets réels.
|
||||||
|
7. Lancer:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ansible-playbook ansible/site.yml
|
||||||
|
ansible-playbook ansible/verify.yml
|
||||||
|
```
|
||||||
|
|
||||||
|
## Après installation vanille
|
||||||
|
|
||||||
|
La page de sélection des groupes doit présenter `Groupe Démonstration`.
|
||||||
|
|
||||||
|
Connexion:
|
||||||
|
|
||||||
|
- identifiant: `sysadmin`;
|
||||||
|
- PIN: `0000`.
|
||||||
|
|
||||||
|
## TLS
|
||||||
|
|
||||||
|
Deux modèles sont possibles:
|
||||||
|
|
||||||
|
- TLS géré par l'instance si Certbot est activé;
|
||||||
|
- TLS géré par un proxy externe, qui relaie vers le NGINX local de l'application.
|
||||||
|
|
||||||
|
Le second modèle est accepté: l'application répond en HTTP local, le proxy externe termine TLS.
|
||||||
|
|
||||||
87
docs/93_MULTI_GROUPE.md
Normal file
87
docs/93_MULTI_GROUPE.md
Normal file
|
|
@ -0,0 +1,87 @@
|
||||||
|
# Isolation multi-groupe
|
||||||
|
|
||||||
|
Statut: référence technique
|
||||||
|
Public: mainteneurs, sysadmin
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
L'application peut servir plusieurs groupes sous une même instance. Les groupes ne doivent pas avoir de liens d'interdépendance métier.
|
||||||
|
|
||||||
|
## Principe
|
||||||
|
|
||||||
|
Le groupe courant est déterminé par le membre authentifié et le `groupe_id` dans le jeton. Une requête authentifiée ne doit lire ou modifier que les données de ce groupe.
|
||||||
|
|
||||||
|
## Page publique
|
||||||
|
|
||||||
|
La page de connexion liste les groupes sous forme de tuiles. Chaque tuile affiche l'horaire et les coordonnées du groupe, puis le formulaire de connexion.
|
||||||
|
|
||||||
|
Le groupe de démonstration est toujours disponible sur une installation vanille.
|
||||||
|
|
||||||
|
## Données de groupe
|
||||||
|
|
||||||
|
Doivent être isolés par groupe:
|
||||||
|
|
||||||
|
- membres;
|
||||||
|
- invitations;
|
||||||
|
- postes;
|
||||||
|
- affectations;
|
||||||
|
- candidatures;
|
||||||
|
- rotations;
|
||||||
|
- rencontres;
|
||||||
|
- assemblées;
|
||||||
|
- présences;
|
||||||
|
- PV;
|
||||||
|
- propositions et décisions;
|
||||||
|
- collectes;
|
||||||
|
- dépenses;
|
||||||
|
- opérations bancaires;
|
||||||
|
- transactions comptables;
|
||||||
|
- réserves;
|
||||||
|
- mouvements de réserves;
|
||||||
|
- destinataires;
|
||||||
|
- contributions;
|
||||||
|
- littérature;
|
||||||
|
- ventes;
|
||||||
|
- jetons;
|
||||||
|
- événements;
|
||||||
|
- rapports;
|
||||||
|
- journal;
|
||||||
|
- historique.
|
||||||
|
|
||||||
|
## Tables sans `groupe_id` direct
|
||||||
|
|
||||||
|
Une table sans `groupe_id` direct est acceptable seulement si son parent isole strictement le groupe. Exemple: une présence peut être bornée par sa réunion.
|
||||||
|
|
||||||
|
## Routes
|
||||||
|
|
||||||
|
Toute route qui reçoit un ID depuis le client doit:
|
||||||
|
|
||||||
|
1. charger l'objet;
|
||||||
|
2. vérifier son appartenance au groupe courant;
|
||||||
|
3. refuser si l'objet n'appartient pas au groupe.
|
||||||
|
|
||||||
|
## Permissions
|
||||||
|
|
||||||
|
Les permissions de modules sont calculées depuis les postes du groupe courant. Un poste d'un groupe ne peut pas accorder d'accès dans un autre groupe.
|
||||||
|
|
||||||
|
## Sysadmin
|
||||||
|
|
||||||
|
Sysadmin est transversal pour l'administration technique. Ses actions doivent être limitées aux opérations prévues:
|
||||||
|
|
||||||
|
- gérer les groupes;
|
||||||
|
- réinitialiser un groupe;
|
||||||
|
- réinitialiser la démonstration;
|
||||||
|
- impersonifier.
|
||||||
|
|
||||||
|
## Démonstration
|
||||||
|
|
||||||
|
`Groupe Démonstration` est protégé et toujours placé en bas de la liste. Le bouton `Réinit` recrée ses données fictives sans toucher aux autres groupes.
|
||||||
|
|
||||||
|
## Tests à refaire lors de changements multi-groupe
|
||||||
|
|
||||||
|
- Créer deux groupes.
|
||||||
|
- Créer des membres dans chaque groupe.
|
||||||
|
- Vérifier que les listes de membres ne se croisent pas.
|
||||||
|
- Vérifier que les postes et permissions ne se croisent pas.
|
||||||
|
- Vérifier les rencontres, assemblées, finances, rapports et journal par groupe.
|
||||||
|
- Vérifier que l'impersonification reste dans le groupe du membre ciblé.
|
||||||
|
|
||||||
49
docs/94_GARDE_FOUS_SOCIAUX.md
Normal file
49
docs/94_GARDE_FOUS_SOCIAUX.md
Normal file
|
|
@ -0,0 +1,49 @@
|
||||||
|
# Garde-fous sociaux
|
||||||
|
|
||||||
|
Statut: support de conscience de groupe
|
||||||
|
Public: membres, exécutifs
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
Ces textes peuvent être lus, adaptés et adoptés par un groupe. Ils visent à garder l'application à sa juste place: un outil de service, pas une autorité.
|
||||||
|
|
||||||
|
## Résolution type
|
||||||
|
|
||||||
|
Le groupe reconnaît cette application comme un outil de service. Elle vise à alléger les tâches, préserver l'historique, soutenir la transparence et faciliter la continuité entre serviteurs. Elle ne remplace pas la conscience de groupe, ne gouverne pas le groupe et ne doit pas devenir nécessaire pour participer à une rencontre. Le groupe conserve la possibilité de reprendre les processus sur papier lorsque l'informatique n'est pas disponible.
|
||||||
|
|
||||||
|
## Charte courte d'utilisation
|
||||||
|
|
||||||
|
1. L'application assiste le groupe; elle ne décide pas pour lui.
|
||||||
|
2. Les décisions importantes demeurent prises en assemblée.
|
||||||
|
3. Le journal sert à comprendre les changements, pas à surveiller.
|
||||||
|
4. Les permissions suivent les postes de service et doivent être revues.
|
||||||
|
5. Les données personnelles conservées doivent rester minimales.
|
||||||
|
6. Le compte `Sysadmin` est un outil technique, pas un poste de pouvoir.
|
||||||
|
7. Les rapports imprimables permettent une reprise papier.
|
||||||
|
8. Le groupe doit toujours pouvoir fonctionner sans l'application.
|
||||||
|
|
||||||
|
## Texte de présentation courte
|
||||||
|
|
||||||
|
Cette application a été conçue pour aider les serviteurs du groupe à faire leur service plus simplement. Elle rassemble les informations utiles aux rencontres, assemblées, finances, postes et décisions.
|
||||||
|
|
||||||
|
Elle ne remplace pas la parole, la confiance, la conscience de groupe ni les traditions. Elle aide surtout à éviter les oublis, faciliter les rapports, garder une trace des changements et soutenir la continuité entre serviteurs.
|
||||||
|
|
||||||
|
## Questions à revoir périodiquement
|
||||||
|
|
||||||
|
- Les permissions correspondent-elles encore aux postes réellement occupés?
|
||||||
|
- Les rapports produits aident-ils les discussions du groupe?
|
||||||
|
- Conservons-nous des données inutiles?
|
||||||
|
- Le journal est-il utilisé pour comprendre plutôt que blâmer?
|
||||||
|
- Le groupe sait-il continuer une rencontre ou assemblée sans l'application?
|
||||||
|
- Le PIN sysadmin est-il géré prudemment?
|
||||||
|
- Les sauvegardes sont-elles récentes et restaurables?
|
||||||
|
|
||||||
|
## Reprise papier
|
||||||
|
|
||||||
|
Si l'application n'est pas disponible:
|
||||||
|
|
||||||
|
1. Continuer la rencontre ou l'assemblée normalement.
|
||||||
|
2. Noter date, montants, présences, décisions et responsables.
|
||||||
|
3. Faire approuver ce qui doit l'être.
|
||||||
|
4. Ressaisir les données lorsque l'application revient.
|
||||||
|
5. Conserver le papier jusqu'à vérification.
|
||||||
|
|
||||||
94
docs/95_PRESENTATION_MEMBRES.md
Normal file
94
docs/95_PRESENTATION_MEMBRES.md
Normal file
|
|
@ -0,0 +1,94 @@
|
||||||
|
# Présentation aux membres
|
||||||
|
|
||||||
|
Statut: texte de présentation
|
||||||
|
Public: membres AA
|
||||||
|
Dernière révision: 2026-06-01
|
||||||
|
|
||||||
|
## L'attrait plutôt que la réclame
|
||||||
|
|
||||||
|
Bonjour à toutes et à tous.
|
||||||
|
|
||||||
|
Cette présentation n'a pas pour but de vendre un outil, ni de convaincre qui que ce soit d'aimer l'informatique. Dans AA, ce qui dure repose rarement sur la pression. Nous avançons mieux quand les choses sont simples, utiles et au service du groupe.
|
||||||
|
|
||||||
|
L'application présentée ici a été pensée dans cet esprit: aider le groupe à mieux garder sa mémoire, ses décisions, ses responsabilités et sa trésorerie, sans remplacer la conscience de groupe.
|
||||||
|
|
||||||
|
Elle ne décide pas à notre place. Elle ne dirige pas le groupe. Elle ne remplace ni les traditions, ni le bon sens, ni la confiance entre nous.
|
||||||
|
|
||||||
|
Elle sert simplement à mieux soutenir ce que nous faisons déjà.
|
||||||
|
|
||||||
|
## Pourquoi cet outil existe
|
||||||
|
|
||||||
|
Dans un groupe AA, plusieurs petites choses doivent être suivies:
|
||||||
|
|
||||||
|
- les rencontres;
|
||||||
|
- les assemblées d'affaires;
|
||||||
|
- les présences;
|
||||||
|
- les procès-verbaux;
|
||||||
|
- les propositions et décisions;
|
||||||
|
- les collectes;
|
||||||
|
- les dépenses;
|
||||||
|
- les contributions;
|
||||||
|
- les postes de service;
|
||||||
|
- la littérature;
|
||||||
|
- les événements;
|
||||||
|
- les rapports.
|
||||||
|
|
||||||
|
Quand tout repose sur quelques personnes, des cahiers, des messages, des souvenirs ou des fichiers dispersés, il devient facile de perdre le fil.
|
||||||
|
|
||||||
|
L'application vise à réduire cette fragilité.
|
||||||
|
|
||||||
|
## Ce que l'application apporte
|
||||||
|
|
||||||
|
Elle apporte surtout de l'ordre.
|
||||||
|
|
||||||
|
Un membre peut consulter les informations utiles au groupe. Un serviteur peut saisir ce qui concerne son service au bon endroit. Un trésorier peut suivre les entrées, les sorties, les réserves et les rapports. Un secrétaire peut préparer les assemblées, les présences et les procès-verbaux. Le groupe peut retrouver ses décisions passées plus facilement.
|
||||||
|
|
||||||
|
## Ce que l'application ne fait pas
|
||||||
|
|
||||||
|
Elle ne remplace pas:
|
||||||
|
|
||||||
|
- l'assemblée d'affaires;
|
||||||
|
- la discussion;
|
||||||
|
- le vote ou le consensus;
|
||||||
|
- la responsabilité des serviteurs;
|
||||||
|
- la rotation;
|
||||||
|
- la confiance.
|
||||||
|
|
||||||
|
Elle donne seulement un endroit commun pour noter ce qui a été fait, ce qui reste à faire et ce qui a été décidé ensemble.
|
||||||
|
|
||||||
|
## Pour un membre
|
||||||
|
|
||||||
|
Un membre peut s'en servir simplement pour:
|
||||||
|
|
||||||
|
- consulter les événements;
|
||||||
|
- voir les postes à pourvoir;
|
||||||
|
- proposer ou seconder une proposition;
|
||||||
|
- soumettre une dépense;
|
||||||
|
- consulter les décisions du groupe;
|
||||||
|
- vérifier les rapports disponibles.
|
||||||
|
|
||||||
|
Personne n'a besoin de devenir technicien pour participer à la vie du groupe.
|
||||||
|
|
||||||
|
## Pour les serviteurs
|
||||||
|
|
||||||
|
L'application aide les serviteurs à:
|
||||||
|
|
||||||
|
- préparer les rencontres;
|
||||||
|
- saisir les collectes;
|
||||||
|
- suivre la littérature et les jetons;
|
||||||
|
- préparer les assemblées;
|
||||||
|
- produire des rapports imprimables;
|
||||||
|
- transmettre plus facilement la responsabilité au prochain serviteur.
|
||||||
|
|
||||||
|
## Pour le groupe
|
||||||
|
|
||||||
|
Le plus important est la continuité. Quand les serviteurs changent, la mémoire du groupe reste accessible. Les décisions sont plus faciles à retrouver. Les finances sont plus claires. Les postes disponibles sont visibles.
|
||||||
|
|
||||||
|
L'outil n'est pas là pour rendre le groupe plus compliqué. Il est là pour rendre le service plus léger.
|
||||||
|
|
||||||
|
## Mot de fermeture
|
||||||
|
|
||||||
|
Si le groupe choisit d'utiliser cette application, il devrait le faire à sa manière, avec prudence et simplicité. L'application doit rester au service du groupe. Si elle cesse d'aider, le groupe doit pouvoir l'ajuster, la mettre de côté ou revenir au papier.
|
||||||
|
|
||||||
|
L'essentiel demeure ce que nous faisons ensemble.
|
||||||
|
|
||||||
128
docs/ANSIBLE.md
128
docs/ANSIBLE.md
|
|
@ -1,128 +0,0 @@
|
||||||
# Deploiement Ansible
|
|
||||||
|
|
||||||
Ce depot peut installer l'application complete sur une Debian vanille avec un compte `ansible` sudoer sans mot de passe.
|
|
||||||
|
|
||||||
Le playbook installe PostgreSQL, Node.js, Python, NGINX, le backend FastAPI, le frontend Vite compile, le service systemd, les sauvegardes quotidiennes et, optionnellement, le certificat Let's Encrypt.
|
|
||||||
|
|
||||||
## Prerequis cote poste de controle
|
|
||||||
|
|
||||||
```bash
|
|
||||||
python3 -m pip install --user ansible
|
|
||||||
ansible-galaxy collection install -r ansible/requirements.yml
|
|
||||||
node --version # Node.js 20 recommande pour construire le frontend PWA
|
|
||||||
npm --version
|
|
||||||
```
|
|
||||||
|
|
||||||
Le serveur cible doit etre joignable en SSH avec l'utilisateur `ansible`.
|
|
||||||
L'inventaire utilise explicitement cette cle locale:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
~/.ssh/id_ed25519_ansible_chezlepro
|
|
||||||
```
|
|
||||||
|
|
||||||
Pour preparer l'acces SSH:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_ansible_chezlepro -C "ansible@chezlepro"
|
|
||||||
ssh-copy-id -i ~/.ssh/id_ed25519_ansible_chezlepro.pub ansible@ADRESSE_IP_VM
|
|
||||||
ssh -i ~/.ssh/id_ed25519_ansible_chezlepro ansible@ADRESSE_IP_VM
|
|
||||||
```
|
|
||||||
|
|
||||||
## Configuration
|
|
||||||
|
|
||||||
1. Modifier l'inventaire:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
nano ansible/inventory/hosts.yml
|
|
||||||
```
|
|
||||||
|
|
||||||
Remplacer `ansible_host` par l'adresse de la machine Debian si elle change.
|
|
||||||
|
|
||||||
2. Creer le fichier de secrets:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
cp ansible/group_vars/vault.yml.example ansible/group_vars/vault.yml
|
|
||||||
openssl rand -base64 48
|
|
||||||
nano ansible/group_vars/vault.yml
|
|
||||||
ansible-vault encrypt ansible/group_vars/vault.yml
|
|
||||||
```
|
|
||||||
|
|
||||||
Le fichier chiffre doit contenir au minimum:
|
|
||||||
|
|
||||||
- `groupe_meditation_db_password`
|
|
||||||
- `groupe_meditation_jwt_secret`
|
|
||||||
- `groupe_meditation_first_member`
|
|
||||||
|
|
||||||
3. Ajuster les variables non secretes au besoin:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
nano ansible/group_vars/all.yml
|
|
||||||
```
|
|
||||||
|
|
||||||
Par defaut, le domaine est `app.87-16.org`.
|
|
||||||
|
|
||||||
## Installation
|
|
||||||
|
|
||||||
Depuis la racine du depot:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
ansible-playbook ansible/site.yml --ask-vault-pass
|
|
||||||
```
|
|
||||||
|
|
||||||
Le playbook est concu pour etre relance. Il ne relance le seed que si la table `groupes` est absente ou vide.
|
|
||||||
|
|
||||||
Playbooks utiles:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
ansible-playbook ansible/verify.yml --ask-vault-pass
|
|
||||||
ansible-playbook ansible/backup-now.yml --ask-vault-pass
|
|
||||||
```
|
|
||||||
|
|
||||||
## TLS
|
|
||||||
|
|
||||||
Laissez d'abord `groupe_meditation_enable_tls: false`, pointez le DNS vers la machine, puis activez:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
groupe_meditation_enable_tls: true
|
|
||||||
groupe_meditation_certbot_email: vous@example.com
|
|
||||||
```
|
|
||||||
|
|
||||||
Relancer ensuite:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
ansible-playbook ansible/site.yml --ask-vault-pass
|
|
||||||
```
|
|
||||||
|
|
||||||
## Verification
|
|
||||||
|
|
||||||
```bash
|
|
||||||
curl -s http://app.87-16.org/api/health
|
|
||||||
ssh ansible@app.87-16.org 'sudo systemctl status groupe-meditation --no-pager'
|
|
||||||
ssh ansible@app.87-16.org 'sudo journalctl -u groupe-meditation -n 100 --no-pager'
|
|
||||||
```
|
|
||||||
|
|
||||||
## Ce que le playbook gere
|
|
||||||
|
|
||||||
- Paquets Debian requis.
|
|
||||||
- PostgreSQL local avec utilisateur et base applicatifs.
|
|
||||||
- `.env` backend avec permissions restrictives.
|
|
||||||
- Copie du code depuis ce depot vers `/opt/groupe-meditation`.
|
|
||||||
- Environnement virtuel Python et dependances backend.
|
|
||||||
- Installation npm et build frontend sur le poste de controle, puis publication de `dist/` sur la VM.
|
|
||||||
- Publication des fichiers statiques dans `/var/www/groupe-meditation`.
|
|
||||||
- Service systemd `groupe-meditation`.
|
|
||||||
- Site NGINX reverse proxy + SPA.
|
|
||||||
- Sauvegarde quotidienne dans `/var/backups/groupe-meditation`.
|
|
||||||
|
|
||||||
## Documents liés
|
|
||||||
|
|
||||||
- [Architecture technique](ARCHITECTURE.md)
|
|
||||||
- [Runbook d'exploitation](RUNBOOK.md)
|
|
||||||
- [Guide utilisateur](UTILISATEURS.md)
|
|
||||||
|
|
||||||
## Notes importantes
|
|
||||||
|
|
||||||
- Le playbook ne modifie pas le code applicatif.
|
|
||||||
- `node_modules/`, `dist/` et `ansible/group_vars/vault.yml` sont ignores par Git.
|
|
||||||
- La sauvegarde Ansible injecte `PGPASSWORD` dans le script cron root pour que le dump PostgreSQL fonctionne en mode non interactif.
|
|
||||||
- Le seed utilise le script existant `deploy/seed.py` et lui fournit les valeurs configurees dans Ansible.
|
|
||||||
|
|
@ -1,52 +0,0 @@
|
||||||
# Architecture technique
|
|
||||||
|
|
||||||
## Sources de vérité
|
|
||||||
|
|
||||||
- `propositions` porte les propositions, résolutions, nominations et contributions.
|
|
||||||
- Une décision de groupe est une proposition adoptée avec `date_adoption`, `numero_resolution`, `etant_donne_que` et `groupe_a_decide_de`.
|
|
||||||
- `transactions_comptables` est la source des soldes financiers.
|
|
||||||
- `mouvements_reserves` est la source des soldes de réserves.
|
|
||||||
- `reserves.montant` est un cache d'affichage; il ne doit pas devenir la source de vérité.
|
|
||||||
|
|
||||||
## Backend
|
|
||||||
|
|
||||||
- `app/core`: configuration, sécurité, rôles, règles communes.
|
|
||||||
- `app/services`: logique métier réutilisable, notamment `finance.py`.
|
|
||||||
- `app/models`: tables SQLAlchemy.
|
|
||||||
- `app/routers`: endpoints FastAPI. Les routers doivent orchestrer, pas contenir les calculs centraux.
|
|
||||||
- `app/schemas`: contrats Pydantic d'entrée/sortie.
|
|
||||||
|
|
||||||
Règle de maintenance: un router ne doit pas importer un autre router pour obtenir une logique métier. Extraire dans `app/services` ou `app/core`.
|
|
||||||
|
|
||||||
## Frontend
|
|
||||||
|
|
||||||
- `src/pages`: écrans applicatifs.
|
|
||||||
- `src/components`: composants partagés.
|
|
||||||
- `src/utils`: calculs purs et helpers.
|
|
||||||
- `src/stores`: état global et client API.
|
|
||||||
|
|
||||||
Règle de maintenance: si un contrôle ou calcul apparaît dans plusieurs pages, l'extraire dans `components` ou `utils`.
|
|
||||||
|
|
||||||
## Comptabilité
|
|
||||||
|
|
||||||
Les écritures comptables utilisent:
|
|
||||||
|
|
||||||
- `compte`: `banque` ou `encaisse`;
|
|
||||||
- `sens`: `debit` augmente le compte, `credit` le diminue;
|
|
||||||
- `source_table` et `source_id`: lien vers l'objet métier.
|
|
||||||
|
|
||||||
Exemples:
|
|
||||||
|
|
||||||
- Collecte reçue: débit `encaisse`.
|
|
||||||
- Vente de littérature reçue: débit `encaisse`.
|
|
||||||
- Dépôt bancaire: débit `banque`, crédit `encaisse`.
|
|
||||||
- Retrait bancaire: crédit `banque`, débit `encaisse`.
|
|
||||||
- Dépense cash: crédit `encaisse`.
|
|
||||||
- Dépense par chèque/virement débitée: crédit `banque`.
|
|
||||||
- Contribution débitée: crédit `banque`.
|
|
||||||
|
|
||||||
## Déploiement
|
|
||||||
|
|
||||||
La voie normale est Ansible. Voir [ANSIBLE.md](ANSIBLE.md).
|
|
||||||
|
|
||||||
Le déploiement installe PostgreSQL, le backend FastAPI, le frontend compilé, NGINX, systemd et les sauvegardes.
|
|
||||||
|
|
@ -1,7 +0,0 @@
|
||||||
# Déploiement
|
|
||||||
|
|
||||||
La méthode supportée est le déploiement Ansible depuis ce dépôt.
|
|
||||||
|
|
||||||
Voir [ANSIBLE.md](ANSIBLE.md) pour la procédure complète.
|
|
||||||
|
|
||||||
Ce fichier est conservé comme point d'entrée historique afin d'éviter deux procédures concurrentes.
|
|
||||||
|
|
@ -1,51 +0,0 @@
|
||||||
# Garde-fous sociaux pour l'application
|
|
||||||
|
|
||||||
Ce document propose des textes de support que le groupe peut lire, adapter et adopter.
|
|
||||||
Ils visent a garder l'application a sa juste place : un outil de service, pas une autorite.
|
|
||||||
|
|
||||||
## Resolution type
|
|
||||||
|
|
||||||
> Le groupe reconnait cette application comme un outil de service. Elle vise a alleger les taches, preserver l'historique et soutenir la transparence. Elle ne remplace pas la conscience de groupe, ne sert pas a surveiller les membres et ne doit jamais etre necessaire pour participer a une reunion. Les membres conservent la possibilite de reprendre les processus sur papier lorsque l'informatique n'est pas disponible.
|
|
||||||
|
|
||||||
## Charte courte d'utilisation
|
|
||||||
|
|
||||||
1. L'application assiste le groupe; elle ne decide pas pour lui.
|
|
||||||
2. Le journal sert a comprendre les changements, corriger les erreurs et proteger l'historique.
|
|
||||||
3. Les permissions suivent les postes de service et doivent etre revues regulierement.
|
|
||||||
4. Les donnees personnelles conservees doivent rester minimales et utiles.
|
|
||||||
5. Les rapports imprimables permettent une reprise en main si l'outil est indisponible.
|
|
||||||
6. Le compte Sysadmin est un outil technique, pas un poste de pouvoir dans le groupe.
|
|
||||||
7. Les decisions importantes demeurent prises en assemblee, selon la conscience de groupe.
|
|
||||||
|
|
||||||
## Message de presentation aux membres
|
|
||||||
|
|
||||||
Cette application a ete concue pour aider les serviteurs du groupe a faire leur service plus simplement.
|
|
||||||
Elle rassemble les informations utiles aux rencontres, assemblees, finances, postes et decisions du groupe.
|
|
||||||
|
|
||||||
Elle ne remplace pas la parole, la confiance, la conscience de groupe ni les traditions.
|
|
||||||
Elle sert surtout a eviter les oublis, faciliter les rapports, garder une trace des changements et permettre une meilleure continuite entre les serviteurs.
|
|
||||||
|
|
||||||
Chaque membre peut consulter ce qui lui est utile selon ses acces.
|
|
||||||
Les actions importantes sont journalisees pour proteger l'historique, non pour surveiller les membres.
|
|
||||||
Lorsque l'informatique n'est pas disponible, le groupe peut continuer sur papier et ressaisir les informations plus tard.
|
|
||||||
|
|
||||||
## Questions a revoir periodiquement
|
|
||||||
|
|
||||||
- Les permissions correspondent-elles encore aux postes reellement occupes?
|
|
||||||
- Les rapports produits aident-ils vraiment les discussions du groupe?
|
|
||||||
- Des donnees inutiles sont-elles conservees?
|
|
||||||
- Le journal est-il utilise pour comprendre et non pour blamer?
|
|
||||||
- Le groupe sait-il continuer une rencontre ou une assemblee sans l'application?
|
|
||||||
- Le mot de passe Sysadmin a-t-il ete change apres installation?
|
|
||||||
- Les sauvegardes sont-elles recentes et protegees?
|
|
||||||
|
|
||||||
## Reprise papier
|
|
||||||
|
|
||||||
Si l'application n'est pas disponible:
|
|
||||||
|
|
||||||
1. Ouvrir le module `Mode papier` si l'app est encore accessible, ou utiliser des formulaires deja imprimes.
|
|
||||||
2. Continuer la rencontre ou l'assemblee normalement.
|
|
||||||
3. Identifier clairement la date, le responsable et les montants.
|
|
||||||
4. Faire approuver les rapports comme d'habitude.
|
|
||||||
5. Ressaisir les donnees dans l'application lorsque le service revient.
|
|
||||||
6. Conserver le papier jusqu'a verification par le secretaire ou le tresorier.
|
|
||||||
|
|
@ -1,23 +0,0 @@
|
||||||
# Isolation multi-groupe
|
|
||||||
|
|
||||||
L'application est servie sous une URL commune, mais les donnees d'un groupe doivent rester isolees de celles des autres groupes. Le contexte actif est toujours le `groupe_id` du membre authentifie, transporte dans le jeton de session et verifie au chargement du membre.
|
|
||||||
|
|
||||||
## Regles d'isolation
|
|
||||||
|
|
||||||
- Une requete authentifiee ne doit lire ou modifier que les donnees du groupe du membre courant.
|
|
||||||
- Les postes, affectations, candidatures, rotations, reunions, assemblees, propositions, transactions, reserves et journaux sont des donnees de groupe.
|
|
||||||
- Les permissions de modules sont derivees des postes du groupe courant seulement.
|
|
||||||
- Le calendrier affiche uniquement les serviteurs du groupe courant. Il ne fait pas de lecture district ou multi-groupe.
|
|
||||||
- Les liens invites donnent acces seulement a l'assemblee ciblee par l'invitation et a ses donnees publiques.
|
|
||||||
- Les tables sans `groupe_id` direct doivent etre bornees par leur parent : par exemple une presence est bornee par sa reunion, un PV par sa reunion, une permission de module par son poste.
|
|
||||||
|
|
||||||
## Points de vigilance
|
|
||||||
|
|
||||||
- Une route qui accepte un identifiant fourni par le client doit verifier que l'objet appartient au groupe courant avant de l'utiliser.
|
|
||||||
- Une jointure de permissions doit filtrer a la fois l'affectation et le poste sur le groupe courant.
|
|
||||||
- Une initialisation ou remise a zero par Sysadmin est une operation d'instance. Elle ne doit pas etre exposee comme operation courante en production multi-groupe.
|
|
||||||
- Toute nouvelle table metier doit recevoir un `groupe_id`, sauf si son rattachement a une table parent isolee est strict et documente.
|
|
||||||
|
|
||||||
## Etat actuel
|
|
||||||
|
|
||||||
Les postes sont maintenant scopes par `groupe_id`, ce qui evite qu'un groupe modifie les definitions de postes ou les permissions d'un autre groupe. Les routes de calendrier, de postes, d'assemblees et de rotations filtrent les donnees par groupe courant.
|
|
||||||
|
|
@ -1,209 +0,0 @@
|
||||||
# Présentation aux membres
|
|
||||||
|
|
||||||
## L'attrait plutôt que la réclame
|
|
||||||
|
|
||||||
Bonjour à toutes et à tous.
|
|
||||||
|
|
||||||
Cette présentation n'a pas pour but de vendre un outil, ni de convaincre qui que ce soit d'aimer l'informatique. Dans AA, nous savons que ce qui dure repose rarement sur la pression. Nous avançons mieux quand les choses sont simples, utiles, et qu'elles servent le groupe.
|
|
||||||
|
|
||||||
L'application que nous vous présentons a été pensée dans cet esprit : aider le groupe à mieux garder sa mémoire, ses décisions, ses responsabilités et sa trésorerie, sans remplacer la conscience de groupe.
|
|
||||||
|
|
||||||
Elle ne décide pas à notre place. Elle ne dirige pas le groupe. Elle ne remplace ni les traditions, ni le bon sens, ni la confiance entre nous.
|
|
||||||
|
|
||||||
Elle sert simplement à mieux soutenir ce que nous faisons déjà.
|
|
||||||
|
|
||||||
## Pourquoi cet outil existe
|
|
||||||
|
|
||||||
Dans un groupe AA, plusieurs petites choses doivent être suivies régulièrement :
|
|
||||||
|
|
||||||
- les rencontres;
|
|
||||||
- les assemblées d'affaires;
|
|
||||||
- les présences;
|
|
||||||
- les procès-verbaux;
|
|
||||||
- les propositions et décisions;
|
|
||||||
- les collectes;
|
|
||||||
- les dépenses;
|
|
||||||
- les contributions;
|
|
||||||
- les postes de service;
|
|
||||||
- la littérature;
|
|
||||||
- les événements;
|
|
||||||
- les rapports.
|
|
||||||
|
|
||||||
Quand tout repose sur quelques personnes, des cahiers, des messages texte, des souvenirs ou des fichiers dispersés, il devient facile de perdre le fil.
|
|
||||||
|
|
||||||
L'application vise à réduire cette fragilité.
|
|
||||||
|
|
||||||
Elle aide à ce que l'information du groupe reste disponible, compréhensible et transmissible, même quand les serviteurs changent.
|
|
||||||
|
|
||||||
## Ce que l'application apporte
|
|
||||||
|
|
||||||
Elle apporte surtout de l'ordre.
|
|
||||||
|
|
||||||
Un membre peut consulter les informations utiles au groupe sans avoir à demander à trois personnes différentes.
|
|
||||||
|
|
||||||
Un serviteur peut saisir ce qui concerne son service au bon endroit.
|
|
||||||
|
|
||||||
Un trésorier peut suivre les entrées, les sorties, les réserves et les rapports.
|
|
||||||
|
|
||||||
Un secrétaire peut préparer les assemblées, les présences et les procès-verbaux.
|
|
||||||
|
|
||||||
L'exécutif peut gérer les postes, les accès et les informations du groupe.
|
|
||||||
|
|
||||||
Le groupe peut retrouver ses décisions passées plus facilement.
|
|
||||||
|
|
||||||
## Ce que l'application ne fait pas
|
|
||||||
|
|
||||||
Elle ne remplace pas l'assemblée d'affaires.
|
|
||||||
|
|
||||||
Elle ne remplace pas la discussion.
|
|
||||||
|
|
||||||
Elle ne remplace pas le vote ou le consensus.
|
|
||||||
|
|
||||||
Elle ne remplace pas la responsabilité des serviteurs.
|
|
||||||
|
|
||||||
Elle ne remplace pas la rotation.
|
|
||||||
|
|
||||||
Elle ne remplace pas la confiance.
|
|
||||||
|
|
||||||
Elle donne seulement un endroit commun pour noter ce qui a été fait, ce qui reste à faire, et ce qui a été décidé ensemble.
|
|
||||||
|
|
||||||
## Pour les membres
|
|
||||||
|
|
||||||
Pour un membre, l'utilisation peut rester très simple.
|
|
||||||
|
|
||||||
On peut s'en servir pour :
|
|
||||||
|
|
||||||
- voir les événements;
|
|
||||||
- consulter la littérature;
|
|
||||||
- voir les postes à pourvoir;
|
|
||||||
- proposer sa candidature;
|
|
||||||
- soumettre une proposition;
|
|
||||||
- seconder une proposition;
|
|
||||||
- soumettre une dépense;
|
|
||||||
- consulter les décisions du groupe;
|
|
||||||
- consulter les rapports disponibles.
|
|
||||||
|
|
||||||
Personne n'a besoin de tout utiliser.
|
|
||||||
|
|
||||||
Chacun peut commencer par ce qui lui est utile.
|
|
||||||
|
|
||||||
## Pour les serviteurs
|
|
||||||
|
|
||||||
Pour les serviteurs, l'application peut alléger la tâche.
|
|
||||||
|
|
||||||
Elle aide à garder les informations au même endroit :
|
|
||||||
|
|
||||||
- rencontre hebdomadaire;
|
|
||||||
- collecte;
|
|
||||||
- ventes;
|
|
||||||
- jetons et gâteaux;
|
|
||||||
- assemblée d'affaires;
|
|
||||||
- présences;
|
|
||||||
- procès-verbal;
|
|
||||||
- rapport du trésorier;
|
|
||||||
- décisions;
|
|
||||||
- postes à pourvoir.
|
|
||||||
|
|
||||||
L'idée n'est pas d'ajouter du travail, mais de rendre le travail plus clair et plus facile à transmettre.
|
|
||||||
|
|
||||||
## Pour la trésorerie
|
|
||||||
|
|
||||||
La trésorerie est souvent un point sensible, non parce que les gens manquent de bonne volonté, mais parce que l'argent demande de la clarté.
|
|
||||||
|
|
||||||
L'application aide à suivre :
|
|
||||||
|
|
||||||
- l'encaisse;
|
|
||||||
- le solde bancaire;
|
|
||||||
- les collectes;
|
|
||||||
- les dépenses;
|
|
||||||
- les contributions;
|
|
||||||
- les réserves;
|
|
||||||
- les montants engagés;
|
|
||||||
- le registre;
|
|
||||||
- l'état des résultats;
|
|
||||||
- le rapport mensuel.
|
|
||||||
|
|
||||||
Le but est simple : que le groupe puisse comprendre où il en est, sans dépendre seulement de la mémoire d'une personne.
|
|
||||||
|
|
||||||
## Pour les assemblées d'affaires
|
|
||||||
|
|
||||||
Une assemblée d'affaires peut être mieux préparée.
|
|
||||||
|
|
||||||
L'application rassemble :
|
|
||||||
|
|
||||||
- l'ordre du jour;
|
|
||||||
- le procès-verbal précédent;
|
|
||||||
- les présences;
|
|
||||||
- le rapport du trésorier;
|
|
||||||
- les propositions en cours;
|
|
||||||
- les décisions prises;
|
|
||||||
- les contributions;
|
|
||||||
- les postes à pourvoir.
|
|
||||||
|
|
||||||
Le rapport PDF permet d'imprimer ce qui est nécessaire. Si la technologie fait défaut pendant la réunion, le groupe peut continuer avec le document papier.
|
|
||||||
|
|
||||||
## Respect de l'esprit AA
|
|
||||||
|
|
||||||
L'application a été pensée pour rester au service du groupe.
|
|
||||||
|
|
||||||
Elle favorise :
|
|
||||||
|
|
||||||
- la mémoire collective;
|
|
||||||
- la transparence;
|
|
||||||
- la rotation;
|
|
||||||
- la responsabilité;
|
|
||||||
- la simplicité;
|
|
||||||
- l'autonomie du groupe.
|
|
||||||
|
|
||||||
Elle ne cherche pas à faire entrer le groupe dans un moule. Elle doit plutôt s'adapter aux pratiques du groupe, tant que ces pratiques restent cohérentes et compréhensibles.
|
|
||||||
|
|
||||||
## Confidentialité et prudence
|
|
||||||
|
|
||||||
L'application contient des informations du groupe. Elle doit donc être utilisée avec prudence.
|
|
||||||
|
|
||||||
Quelques habitudes simples sont importantes :
|
|
||||||
|
|
||||||
- utiliser son propre compte;
|
|
||||||
- ne pas partager son PIN;
|
|
||||||
- se déconnecter sur un appareil partagé;
|
|
||||||
- éviter d'inscrire des informations inutilement personnelles;
|
|
||||||
- respecter l'anonymat;
|
|
||||||
- limiter les accès selon les responsabilités réelles.
|
|
||||||
|
|
||||||
Le principe reste le même : assez d'information pour bien servir le groupe, pas plus que nécessaire.
|
|
||||||
|
|
||||||
## Comment commencer
|
|
||||||
|
|
||||||
Il n'est pas nécessaire que tout le monde maîtrise tout dès le premier jour.
|
|
||||||
|
|
||||||
Une approche simple serait :
|
|
||||||
|
|
||||||
1. Les membres se connectent et consultent l'accueil.
|
|
||||||
2. Les serviteurs utilisent les modules liés à leur poste.
|
|
||||||
3. Le trésorier utilise la trésorerie.
|
|
||||||
4. Le secrétaire utilise les assemblées.
|
|
||||||
5. Le groupe ajuste les permissions et les habitudes au fil de l'usage.
|
|
||||||
|
|
||||||
L'outil peut grandir dans le groupe tranquillement, par l'utilité qu'il démontre.
|
|
||||||
|
|
||||||
## Ce que nous demandons aux membres
|
|
||||||
|
|
||||||
Nous ne demandons pas aux membres d'adopter une nouveauté par enthousiasme.
|
|
||||||
|
|
||||||
Nous demandons seulement de l'essayer avec ouverture.
|
|
||||||
|
|
||||||
Si l'application aide, elle trouvera naturellement sa place.
|
|
||||||
|
|
||||||
Si quelque chose complique le service au lieu de le simplifier, il faudra le corriger.
|
|
||||||
|
|
||||||
L'application doit rester un outil de service.
|
|
||||||
|
|
||||||
## Conclusion
|
|
||||||
|
|
||||||
Dans AA, nous avons appris que les choses les plus utiles sont souvent les plus simples.
|
|
||||||
|
|
||||||
Cette application ne prétend pas être importante. Le groupe est important. Les membres sont importants. Le message est important. Le service est important.
|
|
||||||
|
|
||||||
Si cet outil peut aider le groupe à mieux se souvenir, mieux se préparer, mieux rendre compte et mieux transmettre les responsabilités, alors il aura rempli son rôle.
|
|
||||||
|
|
||||||
Nous pourrons ensuite laisser l'expérience parler d'elle-même.
|
|
||||||
|
|
@ -1,375 +0,0 @@
|
||||||
# Registre des regles metier
|
|
||||||
|
|
||||||
Ce document inventorie les regles metier connues de l'application en les
|
|
||||||
alignant sur le comportement reel du code. Il sert de reference pour les
|
|
||||||
developpements, les tests, les validations apres deploiement et les discussions
|
|
||||||
fonctionnelles.
|
|
||||||
|
|
||||||
Le registre ne liste pas les erreurs techniques generiques comme `objet introuvable` quand elles ne portent pas une intention metier particuliere. Il
|
|
||||||
liste toutefois les droits d'acces, les contraintes de saisie, les transitions
|
|
||||||
d'etat, les invariants financiers et les protections de donnees.
|
|
||||||
|
|
||||||
Quand le comportement actuel ne correspond pas clairement a l'intention metier,
|
|
||||||
la regle est formulee selon le code et l'ecart est liste dans la section
|
|
||||||
`Ecarts connus et decisions requises`.
|
|
||||||
|
|
||||||
## Acces et identite
|
|
||||||
|
|
||||||
- RM-ACC-001 - Le compte `Sysadmin` est cree au deploiement initial avec le PIN `0000`.
|
|
||||||
- RM-ACC-002 - Le compte `Sysadmin` a acces a tous les modules.
|
|
||||||
- RM-ACC-003 - Le compte `Sysadmin` ne peut pas etre desactive ni supprime.
|
|
||||||
- RM-ACC-004 - Seul `Sysadmin` peut impersonifier un autre membre.
|
|
||||||
- RM-ACC-005 - Une session impersonifiee conserve l'identite du sysadmin dans le jeton.
|
|
||||||
- RM-ACC-006 - Un membre inactif ne peut pas ouvrir de session.
|
|
||||||
- RM-ACC-007 - Un token invalide, expire ou associe a un autre groupe est refuse.
|
|
||||||
- RM-ACC-008 - Un PIN doit etre compose de quatre chiffres.
|
|
||||||
- RM-ACC-009 - L'identifiant de connexion, stocke dans la colonne `courriel`, est unique dans un groupe.
|
|
||||||
- RM-ACC-010 - La connexion cherche l'identifiant sans tenir compte de la casse.
|
|
||||||
- RM-ACC-011 - Un jeton de session dure 30 jours par defaut.
|
|
||||||
- RM-ACC-012 - Un jeton de session dure 90 jours lorsque `se souvenir de moi` est choisi.
|
|
||||||
- RM-ACC-013 - Les operations d'administration courante sont reservees aux membres occupant un poste executif, sauf exception explicite.
|
|
||||||
- RM-ACC-014 - `Sysadmin` satisfait toutes les verifications de role.
|
|
||||||
|
|
||||||
## Invitations et inscriptions
|
|
||||||
|
|
||||||
- RM-INV-001 - Seul un executif peut generer une invitation.
|
|
||||||
- RM-INV-002 - Un code d'invitation est unique et comporte 12 caracteres hexadecimaux.
|
|
||||||
- RM-INV-003 - Un code d'invitation expire selon la configuration serveur.
|
|
||||||
- RM-INV-004 - Un code d'invitation ne peut etre utilise qu'une seule fois.
|
|
||||||
- RM-INV-005 - Une inscription cree le membre dans le groupe lie a l'invitation.
|
|
||||||
- RM-INV-006 - Le prenom et le nom saisis a l'inscription sont normalises en casse titre.
|
|
||||||
- RM-INV-007 - Le courriel saisi a l'inscription est normalise en minuscules.
|
|
||||||
- RM-INV-008 - Une inscription ouvre immediatement une session pour le nouveau membre.
|
|
||||||
|
|
||||||
## Membres et postes
|
|
||||||
|
|
||||||
- RM-MEM-001 - Le prenom et le telephone d'un membre sont obligatoires.
|
|
||||||
- RM-MEM-002 - Un membre ne peut pas supprimer son propre compte par le droit a l'oubli.
|
|
||||||
- RM-MEM-003 - Un membre peut modifier son profil personnel.
|
|
||||||
- RM-MEM-004 - Un changement de courriel doit conserver l'unicite dans le groupe.
|
|
||||||
- RM-MEM-005 - Un changement de PIN exige l'ancien PIN.
|
|
||||||
- RM-MEM-006 - Un executif peut consulter les membres actifs du groupe.
|
|
||||||
- RM-MEM-007 - La desactivation d'un membre conserve son historique.
|
|
||||||
- RM-MEM-008 - Le droit a l'oubli anonymise le membre au lieu d'effacer les donnees relationnelles.
|
|
||||||
- RM-MEM-009 - Le droit a l'oubli conserve l'identifiant technique et le prenom du membre pour preserver l'historique.
|
|
||||||
- RM-MEM-010 - Le droit a l'oubli retire le nom, neutralise le telephone, la date d'abstinence, le courriel de connexion, le PIN, les preferences de notification et les abonnements push.
|
|
||||||
- RM-MEM-011 - La desactivation ou la reactivation d'un membre agit seulement sur son droit de connexion.
|
|
||||||
- RM-POS-001 - Les postes appartiennent a une categorie valide: `executif`, `service` ou `physique`.
|
|
||||||
- RM-POS-002 - Une affectation active lie un membre, un poste et une date de debut.
|
|
||||||
- RM-POS-003 - Une affectation directe creee par le module d'affectation produit une decision adoptee de type `Nomination`.
|
|
||||||
- RM-POS-004 - Une nomination exige un proposeur et un secondeur actifs et distincts.
|
|
||||||
- RM-POS-005 - Un poste deja affecte ne peut pas etre affecte une seconde fois tant que l'affectation active existe.
|
|
||||||
- RM-POS-006 - Un poste doit etre aboli avant d'etre supprime definitivement.
|
|
||||||
- RM-POS-007 - Les permissions de modules sont associees aux postes.
|
|
||||||
- RM-POS-008 - Seul un executif peut creer, modifier, abolir, reactiver ou supprimer un poste.
|
|
||||||
- RM-POS-009 - Un poste aboli n'apparait pas dans les listes ordinaires, sauf si l'affichage des postes abolis est demande.
|
|
||||||
- RM-POS-010 - Le nom d'un poste est obligatoire.
|
|
||||||
- RM-POS-011 - Un membre peut postuler lui-meme sur un poste disponible.
|
|
||||||
- RM-POS-012 - Un membre ne peut pas postuler deux fois pour le meme poste.
|
|
||||||
- RM-POS-013 - Un executif peut proposer un autre membre pour un poste.
|
|
||||||
- RM-POS-014 - La proposition d'un autre membre ne peut pas viser le membre qui fait la proposition; il doit alors utiliser sa propre candidature.
|
|
||||||
- RM-POS-015 - Une candidature ou nomination deja traitee ne peut plus etre traitee de nouveau.
|
|
||||||
- RM-POS-016 - Le traitement direct d'une candidature acceptee cree une affectation active.
|
|
||||||
- RM-POS-017 - Une candidature refusee conserve son statut `refusee`.
|
|
||||||
- RM-POS-018 - Une nomination refusee marque la candidature comme refusee.
|
|
||||||
- RM-POS-019 - Terminer un mandat met l'affectation au statut `termine` et conserve la date de fin, la raison et le membre qui l'a terminee.
|
|
||||||
- RM-POS-020 - Les modules consultables par un membre dependent des permissions associees a ses postes, avec acces complet pour `Sysadmin`.
|
|
||||||
- RM-POS-021 - Les permissions de modules accordees aux postes sont reconnues par les verifications API des responsabilites specialisees.
|
|
||||||
- RM-POS-022 - Les postes et leurs permissions appartiennent a un seul groupe.
|
|
||||||
- RM-POS-023 - Un poste d'un groupe ne peut jamais accorder un acces, une affectation ou une candidature dans un autre groupe.
|
|
||||||
|
|
||||||
## Reunions et dates
|
|
||||||
|
|
||||||
- RM-REU-001 - Les dates de reunion doivent correspondre au jour configure dans les parametres du groupe.
|
|
||||||
- RM-REU-002 - Une reunion reguliere ne peut pas etre creee deux fois pour la meme semaine ISO.
|
|
||||||
- RM-REU-003 - L'assemblee d'affaires mensuelle doit correspondre a l'ordre configure: premiere, deuxieme, troisieme, quatrieme ou derniere reunion du mois.
|
|
||||||
- RM-REU-004 - Les rapports de rencontre et d'assemblee sont consultables par tous les membres.
|
|
||||||
- RM-REU-005 - La creation et la saisie des rapports de rencontre et d'assemblee sont reservees aux executifs.
|
|
||||||
- RM-REU-006 - `Sysadmin` peut saisir des informations a posteriori en specifiant la date.
|
|
||||||
- RM-REU-007 - Le jour de reunion configure dans le groupe pilote les dates permises pour les collectes, rencontres et assemblees.
|
|
||||||
- RM-REU-008 - L'heure de reunion configuree bloque la saisie de collecte le jour meme avant l'heure prevue, sauf pour `Sysadmin`.
|
|
||||||
- RM-REU-009 - Une rencontre hebdomadaire est de type `reguliere`.
|
|
||||||
- RM-REU-010 - Une assemblee d'affaires est de type `affaires`.
|
|
||||||
- RM-REU-011 - Une seule assemblee d'affaires peut exister pour un mois donne.
|
|
||||||
- RM-REU-012 - Les presences d'une assemblee peuvent etre resaisies; la nouvelle saisie remplace les presences precedentes.
|
|
||||||
- RM-REU-013 - La saisie des presences d'assemblee est reservee au secretaire ou a l'executif.
|
|
||||||
- RM-REU-014 - Le proces-verbal d'une assemblee est rattache a une reunion du groupe.
|
|
||||||
- RM-REU-015 - La creation et la modification d'un proces-verbal sont reservees au secretaire ou a l'executif.
|
|
||||||
- RM-REU-016 - L'adoption d'un proces-verbal exige un proposeur et un secondeur.
|
|
||||||
- RM-REU-017 - L'adoption d'un proces-verbal ajoute une decision d'adoption au proces-verbal.
|
|
||||||
- RM-REU-018 - Un rapport RSG est reserve au RSG, au RSG substitut, a l'executif ou a `Sysadmin`.
|
|
||||||
- RM-REU-019 - Les rotations futures et leur historique sont consultables par les membres.
|
|
||||||
- RM-REU-020 - La planification ou la suppression d'une rotation est reservee aux executifs.
|
|
||||||
|
|
||||||
## Collectes
|
|
||||||
|
|
||||||
- RM-COL-001 - La saisie d'une collecte est reservee aux executifs.
|
|
||||||
- RM-COL-002 - Une collecte ne peut pas etre saisie dans le futur, sauf par `Sysadmin`.
|
|
||||||
- RM-COL-003 - La date d'une collecte doit etre une date de reunion, sauf par `Sysadmin`.
|
|
||||||
- RM-COL-004 - La date de saisie proposee doit faire partie des 52 dernieres rencontres sans collecte deja enregistree.
|
|
||||||
- RM-COL-005 - Il ne peut y avoir qu'une collecte par date.
|
|
||||||
- RM-COL-006 - Une collecte en attente peut etre modifiee; une collecte confirmee ou recue ne le peut plus.
|
|
||||||
- RM-COL-007 - Le membre qui saisit une collecte ne peut pas confirmer son propre montant.
|
|
||||||
- RM-COL-008 - Si le tresorier saisit ou confirme une collecte, la reception est automatique.
|
|
||||||
- RM-COL-009 - Quand le tresorier recoit une collecte, la transaction comptable utilise la date de la collecte.
|
|
||||||
- RM-COL-010 - Une collecte recue debite l'encaisse.
|
|
||||||
- RM-COL-011 - Une collecte saisie puis confirmee par un non-tresorier reste au statut `confirmee` jusqu'a reception par le tresorier.
|
|
||||||
- RM-COL-012 - Le registre de tresorerie inclut les collectes recues.
|
|
||||||
- RM-COL-013 - Le module de collecte peut filtrer par mois, annee et statut.
|
|
||||||
- RM-COL-014 - Tous les montants de collecte participent aux soldes seulement lorsqu'ils atteignent l'etat comptable approprie.
|
|
||||||
|
|
||||||
## Tresorerie
|
|
||||||
|
|
||||||
- RM-TRE-001 - Les soldes de tresorerie sont calcules a partir du registre comptable.
|
|
||||||
- RM-TRE-002 - Le solde bancaire disponible est le solde en banque moins les reserves actives et les engagements non debites.
|
|
||||||
- RM-TRE-003 - L'encaisse est consideree comme disponible.
|
|
||||||
- RM-TRE-004 - Un depot peut provenir de l'encaisse ou d'un don direct au compte bancaire.
|
|
||||||
- RM-TRE-005 - Un depot depuis l'encaisse ne peut pas depasser l'encaisse disponible.
|
|
||||||
- RM-TRE-006 - Un retrait bancaire ne peut pas depasser le solde en banque.
|
|
||||||
- RM-TRE-007 - Un retrait bancaire ne peut pas faire depasser le total des reserves par rapport au solde en banque.
|
|
||||||
- RM-TRE-008 - Un releve bancaire ne peut pas etre inferieur au total des reserves.
|
|
||||||
- RM-TRE-009 - Les transactions du registre sont affichees de la plus recente a la plus ancienne.
|
|
||||||
- RM-TRE-010 - Le rapport PDF de tresorerie utilise l'etat des resultats du mois precedent.
|
|
||||||
- RM-TRE-011 - Les positions de tresorerie du rapport PDF sont celles du dernier jour du mois precedent.
|
|
||||||
- RM-TRE-012 - Les actions qui modifient la tresorerie sont reservees au tresorier ou a l'executif.
|
|
||||||
- RM-TRE-013 - Les membres peuvent voir les elements a traiter, mais seuls les executifs peuvent les confirmer.
|
|
||||||
- RM-TRE-014 - Une operation bancaire doit avoir un type parmi `depot`, `retrait` ou `releve`.
|
|
||||||
- RM-TRE-015 - Une operation bancaire doit avoir un montant positif.
|
|
||||||
- RM-TRE-016 - Un depot direct de don debite la banque sans crediter l'encaisse.
|
|
||||||
- RM-TRE-017 - Un depot depuis l'encaisse debite la banque et credite l'encaisse.
|
|
||||||
- RM-TRE-018 - Un retrait credite la banque et debite l'encaisse.
|
|
||||||
- RM-TRE-019 - Un releve bancaire cree une correction de banque egale a l'ecart entre le releve saisi et le solde bancaire courant.
|
|
||||||
- RM-TRE-020 - Le registre comptable conserve la source de chaque transaction quand elle provient d'une table applicative.
|
|
||||||
- RM-TRE-021 - Le filtre du registre permet de restreindre par mois et par type de transaction.
|
|
||||||
- RM-TRE-022 - Les ventes de litterature remises au tresorier debitent l'encaisse.
|
|
||||||
- RM-TRE-023 - Les depenses payees creditent le compte utilise: banque ou encaisse.
|
|
||||||
- RM-TRE-024 - Les contributions debitees creditent la banque.
|
|
||||||
|
|
||||||
## Reserves
|
|
||||||
|
|
||||||
- RM-RES-001 - Une reserve se cree avec un solde initial de zero.
|
|
||||||
- RM-RES-002 - Le montant d'une reserve ne se modifie pas directement.
|
|
||||||
- RM-RES-003 - Les variations de reserve passent par un virement de reserve.
|
|
||||||
- RM-RES-004 - Les virements de reserve sont historises.
|
|
||||||
- RM-RES-005 - Un virement ne peut pas avoir la meme source et la meme destination.
|
|
||||||
- RM-RES-006 - Le solde disponible peut etre utilise comme source ou destination de virement.
|
|
||||||
- RM-RES-007 - Un virement depuis le disponible ne peut pas depasser le disponible bancaire.
|
|
||||||
- RM-RES-008 - Un virement depuis une reserve ne peut pas depasser le solde de cette reserve.
|
|
||||||
- RM-RES-009 - Une reserve ne peut etre supprimee que si son solde est nul.
|
|
||||||
- RM-RES-010 - Une reserve supprimee est desactivee, pas effacee du registre.
|
|
||||||
- RM-RES-011 - La liste des reserves n'affiche que les reserves actives.
|
|
||||||
- RM-RES-012 - Le solde d'une reserve est calcule a partir des mouvements de reserve, pas a partir d'une saisie manuelle.
|
|
||||||
- RM-RES-013 - Les mouvements de reserve apparaissent au registre.
|
|
||||||
- RM-RES-014 - Les mouvements de reserve conservent source, destination, montant, type, note, createur et date de creation.
|
|
||||||
- RM-RES-015 - Le total des reserves actives ne doit jamais exceder le solde bancaire.
|
|
||||||
- RM-RES-016 - Le disponible n'est pas une reserve; il est calcule comme solde bancaire moins reserves et engagements.
|
|
||||||
|
|
||||||
## Depenses
|
|
||||||
|
|
||||||
- RM-DEP-001 - Un membre ordinaire ne peut soumettre une depense qu'en son nom.
|
|
||||||
- RM-DEP-002 - Un executif peut soumettre une depense au nom d'un autre membre actif.
|
|
||||||
- RM-DEP-003 - Seul `Sysadmin` peut saisir une date de depense a posteriori.
|
|
||||||
- RM-DEP-004 - Une depense soumise doit etre traitee par le tresorier ou un executif.
|
|
||||||
- RM-DEP-005 - Une depense par encaisse est payee immediatement si l'encaisse le permet.
|
|
||||||
- RM-DEP-006 - Une depense par cheque ou virement devient un engagement en attente de debit.
|
|
||||||
- RM-DEP-007 - Une depense bancaire ne peut pas etre engagee si le disponible bancaire est insuffisant.
|
|
||||||
- RM-DEP-008 - Le debit final d'une depense bancaire ne peut pas faire depasser les reserves par rapport au solde en banque.
|
|
||||||
- RM-DEP-009 - Une depense soumise non traitee peut etre rejetee.
|
|
||||||
- RM-DEP-010 - Une depense deja traitee ne peut plus etre rejetee.
|
|
||||||
- RM-DEP-011 - Les modes valides de traitement d'une depense sont `COLLECTE`, `CHEQUE` et `VIREMENT`.
|
|
||||||
- RM-DEP-012 - Une depense deja traitee ne peut pas etre traitee de nouveau.
|
|
||||||
- RM-DEP-013 - Une depense deja payee ne peut pas faire l'objet d'une confirmation de debit.
|
|
||||||
- RM-DEP-014 - Seules les depenses par cheque ou virement necessitent une confirmation de debit bancaire.
|
|
||||||
- RM-DEP-015 - Une preuve de depense peut etre jointe et conservee dans le repertoire des preuves.
|
|
||||||
- RM-DEP-016 - Rejeter une depense supprime aussi son fichier de preuve s'il existe.
|
|
||||||
- RM-DEP-017 - La liste des depenses peut etre filtree selon payee/non payee et confirmee/non confirmee.
|
|
||||||
- RM-DEP-018 - Modifier une depense est reserve au tresorier ou a l'executif.
|
|
||||||
- RM-DEP-019 - Modifier la methode d'une depense exige une methode valide.
|
|
||||||
|
|
||||||
## Contributions
|
|
||||||
|
|
||||||
- RM-CON-001 - Une contribution est une decision de groupe de type `Contribution`.
|
|
||||||
- RM-CON-002 - Une contribution exige un proposeur et un secondeur actifs et distincts.
|
|
||||||
- RM-CON-003 - Le destinataire `District 87-16` existe au deploiement initial.
|
|
||||||
- RM-CON-004 - Le destinataire `District 87-16` est protege contre la modification et la suppression.
|
|
||||||
- RM-CON-005 - Une contribution devient un engagement tant que le debit bancaire n'est pas confirme.
|
|
||||||
- RM-CON-006 - Le debit final d'une contribution ne peut pas depasser le solde en banque.
|
|
||||||
- RM-CON-007 - Le debit final d'une contribution ne peut pas faire depasser les reserves par rapport au solde en banque.
|
|
||||||
- RM-CON-008 - Une contribution doit avoir un montant positif.
|
|
||||||
- RM-CON-009 - Les modes valides de contribution sont `DU`, `VIREMENT` et `CHEQUE`.
|
|
||||||
- RM-CON-010 - La destination d'une contribution doit etre un destinataire actif du groupe.
|
|
||||||
- RM-CON-011 - Un destinataire de contribution est unique par nom dans un groupe.
|
|
||||||
- RM-CON-012 - Un destinataire supprime est desactive, pas efface.
|
|
||||||
- RM-CON-013 - Le calcul de repartition utilise la configuration active du groupe ou la repartition par defaut.
|
|
||||||
- RM-CON-014 - Les destinations de repartition manquantes sont completees a zero.
|
|
||||||
- RM-CON-015 - La configuration de repartition est reservee aux executifs.
|
|
||||||
- RM-CON-016 - Le total d'une repartition doit etre exactement 100 %, avec une tolerance de 0,01.
|
|
||||||
- RM-CON-017 - Les destinations de repartition valides sont `district`, `region`, `bsg` et `intergroupe`.
|
|
||||||
- RM-CON-018 - Un pourcentage de repartition ne peut pas etre negatif.
|
|
||||||
- RM-CON-019 - Une contribution cree automatiquement une decision adoptee de type `Contribution`.
|
|
||||||
- RM-CON-020 - `Sysadmin` peut utiliser la date d'envoi comme date de decision; les autres membres utilisent la date du jour.
|
|
||||||
|
|
||||||
## Gouvernance
|
|
||||||
|
|
||||||
- RM-GOU-001 - Une proposition ne stocke pas de type metier dedie.
|
|
||||||
- RM-GOU-002 - Une proposition exige un objet.
|
|
||||||
- RM-GOU-003 - Une proposition peut etre secondee par un autre membre.
|
|
||||||
- RM-GOU-004 - Un membre ne peut pas seconder sa propre proposition.
|
|
||||||
- RM-GOU-005 - Un executif peut seconder une proposition au nom d'un autre membre actif.
|
|
||||||
- RM-GOU-006 - Seule une proposition secondee peut etre transformee en decision.
|
|
||||||
- RM-GOU-007 - Transformer une proposition en resolution exige les sections `ETANT DONNE QUE` et `LE GROUPE A DECIDE DE`.
|
|
||||||
- RM-GOU-008 - Une resolution adoptee recoit un numero avec le prefixe `RES`.
|
|
||||||
- RM-GOU-009 - Une nomination adoptee recoit le prefixe `NOM`.
|
|
||||||
- RM-GOU-010 - Une contribution adoptee recoit le prefixe `DON`.
|
|
||||||
- RM-GOU-011 - Une proposition rejetee est conservee.
|
|
||||||
- RM-GOU-012 - Rejeter une proposition exige la section `ETANT DONNE QUE`.
|
|
||||||
- RM-GOU-013 - Le rapport des resolutions affiche les decisions prises en groupe.
|
|
||||||
- RM-GOU-014 - Une proposition peut etre rattachee a une reunion existante du groupe.
|
|
||||||
- RM-GOU-015 - Une proposition a l'etat initial `proposee`.
|
|
||||||
- RM-GOU-016 - Seule une proposition a l'etat `proposee` peut etre secondee.
|
|
||||||
- RM-GOU-017 - Seules les propositions aux statuts `proposee` ou `secondee` peuvent etre rejetees.
|
|
||||||
- RM-GOU-018 - Une proposition adoptee conserve la date d'adoption.
|
|
||||||
- RM-GOU-019 - Le type d'une decision est derive du prefixe de son numero (`RES`, `NOM`, `DON`) ou de son lien metier.
|
|
||||||
- RM-GOU-020 - Une nomination adoptee peut accepter automatiquement la candidature liee.
|
|
||||||
- RM-GOU-021 - Une nomination rejetee peut refuser automatiquement la candidature liee.
|
|
||||||
- RM-GOU-022 - L'historique des resolutions peut etre filtre par annee et par type.
|
|
||||||
- RM-GOU-023 - Les decisions adoptees sont ordonnees par date de vote/adoption decroissante dans l'historique.
|
|
||||||
|
|
||||||
## Rapports PDF et rapports de consultation
|
|
||||||
|
|
||||||
- RM-RAP-001 - La generation PDF exige que le moteur PDF serveur soit installe.
|
|
||||||
- RM-RAP-002 - Le mois d'un rapport financier doit etre entre 1 et 12.
|
|
||||||
- RM-RAP-003 - Le rapport des resolutions n'affiche pas de colonne de resultat.
|
|
||||||
- RM-RAP-004 - La description du rapport des resolutions est `Decisions prises en Groupe`.
|
|
||||||
- RM-RAP-005 - Dans le rapport des resolutions, la colonne `Resolution` affiche `LE GROUPE A DECIDE DE` lorsque ce champ est renseigne.
|
|
||||||
- RM-RAP-006 - Le sommaire final du rapport des resolutions est retire.
|
|
||||||
- RM-RAP-007 - Le rapport de tresorerie presente un etat des resultats mensuel, les positions de tresorerie et les reserves.
|
|
||||||
- RM-RAP-008 - Les rapports de rencontre et d'assemblee sont concus pour etre imprimables en format lettre.
|
|
||||||
- RM-RAP-009 - Les rapports consultables ne doivent pas exiger un poste executif, sauf pour leur creation ou modification.
|
|
||||||
|
|
||||||
## Litterature et jetons
|
|
||||||
|
|
||||||
- RM-LIT-001 - La gestion du catalogue de litterature est reservee au responsable de la litterature ou a l'executif.
|
|
||||||
- RM-LIT-002 - Une vente de litterature exige une quantite positive.
|
|
||||||
- RM-LIT-003 - Une vente ne peut pas depasser le stock disponible.
|
|
||||||
- RM-LIT-004 - Le stock de litterature ne peut pas devenir negatif.
|
|
||||||
- RM-LIT-005 - L'inventaire initial de litterature est charge depuis `data/import/Liste-de-prix-rev.-Fevrier-2026.csv`.
|
|
||||||
- RM-LIT-006 - Les categories valides de litterature sont `livre`, `brochure`, `depliant` et `pamphlet`.
|
|
||||||
- RM-LIT-007 - Ajouter ou modifier un titre exige une categorie valide.
|
|
||||||
- RM-LIT-008 - L'inventaire est visible aux membres connectes.
|
|
||||||
- RM-LIT-009 - Une vente de litterature non remise reste a recevoir par le tresorier.
|
|
||||||
- RM-LIT-010 - Une vente de litterature deja remise ne peut pas etre recue une seconde fois.
|
|
||||||
- RM-JET-001 - La gestion des jetons est reservee au responsable des jetons ou a l'executif.
|
|
||||||
- RM-JET-002 - Un type de jeton doit faire partie des types permis.
|
|
||||||
- RM-JET-003 - Un jeton `multiple` exige un nombre d'annees d'au moins 2.
|
|
||||||
- RM-JET-004 - Un jeton peut etre rattache a un membre actif ou etre enregistre sans membre.
|
|
||||||
- RM-JET-005 - Le stock de jetons est estime a partir des remises des 30 derniers jours.
|
|
||||||
- RM-JET-006 - Une suggestion de commande est emise si au moins deux jetons d'un type ont ete remis dans les 30 derniers jours.
|
|
||||||
- RM-JET-007 - Le jeton de desir est a surveiller si au moins quatre ont ete remis dans les 30 derniers jours.
|
|
||||||
|
|
||||||
## Evenements et calendrier
|
|
||||||
|
|
||||||
- RM-EVE-001 - Les evenements affiches incluent les anniversaires de sobriete et les evenements ad hoc.
|
|
||||||
- RM-EVE-002 - Les anniversaires de sobriete sont calcules pour tous les membres actifs du district.
|
|
||||||
- RM-EVE-003 - Un anniversaire du 29 fevrier est ramene au 1er mars pour les annees non bissextiles.
|
|
||||||
- RM-EVE-004 - Les evenements passes et futurs peuvent etre retournes selon les bornes demandees.
|
|
||||||
- RM-EVE-005 - Les evenements ad hoc sont visibles par les membres du district.
|
|
||||||
- RM-EVE-006 - La creation et la suppression d'un evenement ad hoc sont reservees aux executifs.
|
|
||||||
- RM-EVE-007 - Les evenements sont tries par date croissante.
|
|
||||||
|
|
||||||
## Journal et notifications
|
|
||||||
|
|
||||||
- RM-JOU-001 - Les requetes authentifiees qui modifient des donnees sont journalisees.
|
|
||||||
- RM-JOU-002 - Lorsqu'un sysadmin impersonifie un membre, le journal conserve l'identite du membre agissant et de l'admin.
|
|
||||||
- RM-NOT-001 - Les notifications push sont optionnelles et dependent de la configuration VAPID.
|
|
||||||
- RM-NOT-002 - Un abonnement push invalide ou expire peut etre retire automatiquement.
|
|
||||||
- RM-NOT-003 - Un membre peut enregistrer, consulter et supprimer son propre abonnement push.
|
|
||||||
- RM-NOT-004 - Les notifications ne peuvent pas etre activees si le serveur n'a pas de configuration VAPID.
|
|
||||||
- RM-JOU-003 - Le journal est reserve aux executifs.
|
|
||||||
- RM-JOU-004 - Les requetes `GET`, `HEAD` et `OPTIONS` ne sont pas journalisees comme actions modificatrices.
|
|
||||||
- RM-JOU-005 - Le journal n'enregistre pas le corps des requetes; il conserve la methode, le chemin, le statut HTTP, l'adresse IP, le user-agent et les parametres de requete non sensibles.
|
|
||||||
|
|
||||||
## Parametres et donnees initiales
|
|
||||||
|
|
||||||
- RM-PAR-001 - La modification des parametres du groupe est reservee aux executifs.
|
|
||||||
- RM-PAR-002 - Les ordres valides d'assemblee d'affaires sont `premiere`, `deuxieme`, `troisieme`, `quatrieme` et `derniere`.
|
|
||||||
- RM-PAR-003 - Une heure de reunion invalide est ignoree et retire l'heure configuree.
|
|
||||||
- RM-PAR-004 - Le deploiement initial cree le groupe `Groupe Meditation` avec le district `87-16` et la region `87`.
|
|
||||||
- RM-PAR-005 - Le deploiement initial cree les postes de base du groupe.
|
|
||||||
- RM-PAR-006 - Le deploiement initial cree une invitation pour les prochains membres.
|
|
||||||
- RM-PAR-007 - Le deploiement initial cree le destinataire de contribution protege `District 87-16`.
|
|
||||||
- RM-PAR-008 - Le deploiement initial charge le catalogue de litterature depuis `data/import` quand le fichier normalise est present.
|
|
||||||
|
|
||||||
## Transitions d'etat
|
|
||||||
|
|
||||||
| Domaine | Etat initial | Transition | Etat final | Condition |
|
|
||||||
|--------------|-------------------------|-----------------------------|------------|--------------------------------------------|
|
|
||||||
| Proposition | `proposee` | Seconder | `secondee` | Secondeur distinct du proposeur |
|
|
||||||
| Proposition | `secondee` | Adopter | `adoptee` | Executif, sections decisionnelles remplies |
|
|
||||||
| Proposition | `proposee` ou `secondee` | Rejeter | `rejetee` | Executif, section `ETANT DONNE QUE` remplie |
|
|
||||||
| Collecte | `en_attente` | Confirmer | `confirmee` | Confirmateur distinct du saisisseur |
|
|
||||||
| Collecte | `en_attente` ou `confirmee` | Recevoir | `recu` | Tresorier ou executif |
|
|
||||||
| Depense | Soumise | Traiter en encaisse | Payee | Encaisse suffisante |
|
|
||||||
| Depense | Soumise | Traiter par cheque/virement | Engagee | Disponible bancaire suffisant |
|
|
||||||
| Depense | Engagee | Confirmer debit | Payee | Banque suffisante et reserves preservees |
|
|
||||||
| Depense | Soumise | Rejeter | Supprimee | Non traitee |
|
|
||||||
| Contribution | Creee | Enregistrer | Engagee | Decision `DON` creee |
|
|
||||||
| Contribution | Engagee | Confirmer debit | Debitee | Banque suffisante et reserves preservees |
|
|
||||||
| Candidature | `proposee` | Retirer | `retiree` | Par le membre candidat |
|
|
||||||
| Candidature | `proposee` | Refuser | `refusee` | Executif ou membre nomine |
|
|
||||||
| Candidature | `proposee` | Accepter | `acceptee` | Decision `NOM` et affectation creees |
|
|
||||||
| Affectation | `actif` | Terminer | `termine` | Executif |
|
|
||||||
|
|
||||||
## Matrice des permissions par module
|
|
||||||
|
|
||||||
| Module | Consultation | Creation / saisie | Modification / confirmation | Suppression |
|
|
||||||
|------------------------|----------------------------------|-------------------------------------|-----------------------------------------|-------------------------------------------------------|
|
|
||||||
| Accueil | Membre connecte | \- | \- | \- |
|
|
||||||
| Profil | Membre connecte | Membre connecte | Son propre profil | \- |
|
|
||||||
| Gestion des membres | Executif | Executif | Executif | Executif, sauf Sysadmin et soi-meme |
|
|
||||||
| Parametres groupe | Membre connecte | \- | Executif | \- |
|
|
||||||
| Journal | Executif | Automatique | \- | \- |
|
|
||||||
| Gouvernance | Membre connecte | Membre connecte | Executif pour adopter/rejeter | \- |
|
|
||||||
| Postes a pourvoir | Membre connecte | Membre connecte | Membre concerne / executif selon action | Retrait par candidat |
|
|
||||||
| Gestion des postes | Membre connecte pour lister | Executif | Executif | Executif |
|
|
||||||
| Gestion des mandats | Membre connecte pour ses mandats | Executif | Executif | \- |
|
|
||||||
| Rencontre hebdomadaire | Membre connecte | Executif | Executif | \- |
|
|
||||||
| Assemblee d'affaires | Membre connecte | Secretaire ou executif | Secretaire ou executif | \- |
|
|
||||||
| PV | Membre connecte | Secretaire ou executif | Secretaire ou executif | \- |
|
|
||||||
| Rapport RSG | Membre connecte | RSG, RSG substitut ou executif | RSG, RSG substitut ou executif | \- |
|
|
||||||
| Collecte 7e | Executif | Executif | Executif / tresorier selon etape | \- |
|
|
||||||
| Tresorerie | Membre connecte | Tresorier ou executif | Tresorier ou executif | Tresorier ou executif selon action |
|
|
||||||
| Depense | Membre connecte | Membre connecte | Tresorier ou executif | Tresorier ou executif si non traitee |
|
|
||||||
| Donner au suivant | Tresorier ou executif | Tresorier ou executif | Tresorier ou executif | Tresorier ou executif pour destinataires non proteges |
|
|
||||||
| Litterature | Membre connecte | Responsable litterature ou executif | Responsable litterature ou executif | \- |
|
|
||||||
| Vente litterature | Membre connecte | Responsable litterature ou executif | Tresorier ou executif pour reception | \- |
|
|
||||||
| Jetons | Membre connecte | Responsable jetons ou executif | Responsable jetons ou executif | \- |
|
|
||||||
| Evenements | Membre connecte | Executif | Executif | Executif |
|
|
||||||
| Rapports PDF | Membre connecte | Serveur | \- | \- |
|
|
||||||
|
|
||||||
`Sysadmin` a tous les acces.
|
|
||||||
|
|
||||||
## Glossaire financier
|
|
||||||
|
|
||||||
- Banque - Solde du compte bancaire selon le registre comptable.
|
|
||||||
- Encaisse - Argent liquide detenu par le groupe.
|
|
||||||
- Reserve - Portion du solde bancaire affectee a un usage precis.
|
|
||||||
- Engagement non debite - Montant approuve mais pas encore sorti du compte bancaire.
|
|
||||||
- Disponible bancaire - Banque moins reserves actives moins engagements non debites.
|
|
||||||
- Disponible total - Disponible bancaire plus encaisse.
|
|
||||||
- Transaction comptable - Ligne du registre qui modifie un compte financier.
|
|
||||||
- Mouvement de reserve - Virement virtuel entre le disponible et une reserve, ou entre deux reserves.
|
|
||||||
- Etat des resultats - Revenus moins charges pour un mois donne.
|
|
||||||
- Position de tresorerie - Situation banque, encaisse, reserves et engagements a une date donnee.
|
|
||||||
|
|
||||||
## Ecarts connus et decisions requises
|
|
||||||
|
|
||||||
Cette section liste les zones ou la regle metier souhaitee, la documentation et
|
|
||||||
le comportement reel ne sont pas encore parfaitement alignes. Ces points doivent
|
|
||||||
etre corriges dans le code ou clarifies comme decisions fonctionnelles.
|
|
||||||
|
|
||||||
- ECART-001 - La colonne `membres.courriel` sert maintenant aussi d'identifiant de connexion, notamment pour `sysadmin`. Le profil protege maintenant l'identifiant `sysadmin`, mais certains ecrans parlent toujours de courriel. Decision requise: conserver un vrai courriel ou renommer/modeliser un identifiant distinct.
|
|
||||||
- ECART-002 - L'adoption d'un proces-verbal exige actuellement un proposeur et un secondeur en texte libre, pas des `membre_id`. Decision
|
|
||||||
- requise: garder une mention textuelle historique ou exiger des membres actifs comme pour les decisions.
|
|
||||||
- ECART-003 - Certaines contraintes metier sont uniquement appliquees dans le code applicatif et pas par des contraintes SQL, par exemple les montants positifs, le stock non negatif et plusieurs transitions d'etat. C'est acceptable pour l'instant, mais les tests doivent couvrir ces invariants.
|
|
||||||
- ECART-004 - Les rapports PDF et certaines listes utilisent encore des logiques de date dispersees. Les regles mensuelles sont documentees, mais elles devraient etre couvertes par des tests pour eviter les divergences.
|
|
||||||
247
docs/RUNBOOK.md
247
docs/RUNBOOK.md
|
|
@ -1,247 +0,0 @@
|
||||||
# Runbook opérationnel — Groupe Méditation
|
|
||||||
|
|
||||||
## Opérations courantes
|
|
||||||
|
|
||||||
### Inviter un nouveau membre
|
|
||||||
1. Un membre de l'exécutif ouvre **G1 — Inviter**
|
|
||||||
2. Un code à 12 caractères est généré (expire 48h)
|
|
||||||
3. Le code est partagé en personne ou par SMS
|
|
||||||
4. Le nouveau membre ouvre l'app → Inscription → entre le code + prénom + nom + PIN
|
|
||||||
|
|
||||||
> **Note :** le seed crée le premier code d'invitation avec une expiration de 7 jours.
|
|
||||||
|
|
||||||
### Affecter un poste
|
|
||||||
1. Exécutif ouvre **G3 — Affecter les postes**
|
|
||||||
2. Seuls les **postes vacants** apparaissent dans le menu déroulant
|
|
||||||
3. Si tous les postes sont pourvus, un message indique de terminer un mandat d'abord (G4)
|
|
||||||
4. Sélectionne le membre et le poste → le membre voit ses nouvelles tuiles immédiatement
|
|
||||||
|
|
||||||
### Terminer un mandat
|
|
||||||
1. Exécutif ouvre **G4 — Terminer un mandat**
|
|
||||||
2. Sélectionne l'affectation active, saisit une note de transition
|
|
||||||
3. Les permissions sont retirées instantanément et le poste redevient disponible
|
|
||||||
4. **Rappel** : les mandats ne se terminent jamais automatiquement
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Saisie hebdomadaire (pendant/après la réunion)
|
|
||||||
|
|
||||||
### Collecte 7e Tradition (S1)
|
|
||||||
1. Le jour de la réunion, à partir de l'heure prévue, le trésorier ouvre **S1**
|
|
||||||
2. La date est renseignée automatiquement
|
|
||||||
3. Saisir le montant et indiquer qui a l'argent ce soir
|
|
||||||
4. Un second membre confirme le montant (le même membre ne peut pas saisir et confirmer)
|
|
||||||
5. L'onglet **mensuel** affiche toutes les collectes du mois avec date, montant, qui a saisi et qui détient l'argent
|
|
||||||
|
|
||||||
### Autres saisies hebdomadaires
|
|
||||||
- **Animateur** : S4 (thème + annonces)
|
|
||||||
- **Resp. jetons** : S2 (si anniversaire ou nouveau)
|
|
||||||
- **Resp. littérature** : S3 (si vente — le montant sera visible dans la trésorerie pour confirmation)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Trésorerie (S1T)
|
|
||||||
|
|
||||||
Le module Trésorerie s'ouvre sur l'état des résultats. Les opérations de modification sont réservées aux postes exécutifs.
|
|
||||||
|
|
||||||
### Soldes
|
|
||||||
- **Solde banque** : calculé depuis le registre comptable
|
|
||||||
- **Disponible** : banque − engagements non débités − réserves affectées
|
|
||||||
- **Encaisse** : cash reçu mais pas encore déposé à la banque
|
|
||||||
- **Réserves** : soldes calculés depuis l'historique des mouvements de réserves
|
|
||||||
- **En circulation** : collectes pas encore remises au trésorier
|
|
||||||
|
|
||||||
### À recevoir
|
|
||||||
Deux catégories :
|
|
||||||
1. **Collectes** non encore reçues par le trésorier — bouton « Accuser réception »
|
|
||||||
2. **Ventes de littérature** non remises — le responsable de la littérature vend, puis le trésorier confirme qu'il a reçu l'argent via « Confirmer la remise »
|
|
||||||
|
|
||||||
### Registre
|
|
||||||
Journal détaillé des transactions : collectes, ventes, dépenses, contributions et opérations bancaires. Le registre comptable est la source de vérité des soldes.
|
|
||||||
|
|
||||||
### Opérations
|
|
||||||
Trois fonctions :
|
|
||||||
- **Dépôt** : enregistrer un dépôt bancaire provenant de l'encaisse ou d'un don direct
|
|
||||||
- **Retrait** : enregistrer un retrait de la banque vers l'encaisse
|
|
||||||
- **Virement** : transférer des montants entre les réserves
|
|
||||||
|
|
||||||
### Flux mensuel recommandé
|
|
||||||
1. Recevoir le relevé bancaire → vérifier le registre de trésorerie
|
|
||||||
2. Vérifier que le solde correspond → les écarts signalent des opérations non enregistrées ou une correction à saisir
|
|
||||||
3. Préparer l'état des résultats pour la réunion d'affaires
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Dépenses (S5)
|
|
||||||
|
|
||||||
### Saisir une dépense
|
|
||||||
Trois onglets : Saisir, Engagements, Historique.
|
|
||||||
- La dépense est créée avec `payé = Non` par défaut (engagement)
|
|
||||||
- Les méthodes chèque/virement créent un engagement visible dans l'onglet « Engagements »
|
|
||||||
- Pour les dépenses non courantes payées par chèque/virement, une résolution est attendue
|
|
||||||
|
|
||||||
### Confirmer un débit
|
|
||||||
Lorsque l'argent quitte effectivement le compte :
|
|
||||||
1. Trésorier ouvre S5 → onglet **Engagements**
|
|
||||||
2. Clique **Confirmer le débit** sur chaque dépense débitée
|
|
||||||
3. L'engagement disparaît et le solde disponible est mis à jour
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Gouvernance (C5)
|
|
||||||
|
|
||||||
### Soumettre une proposition
|
|
||||||
1. N'importe quel membre peut soumettre une proposition **en tout temps** (pas besoin d'une réunion d'affaires)
|
|
||||||
2. Le sujet est obligatoire ; la réunion d'affaires est optionnelle
|
|
||||||
3. Un autre membre doit **seconder** la proposition pour qu'elle soit recevable
|
|
||||||
|
|
||||||
### Transformer en résolution
|
|
||||||
1. L'exécutif transforme une proposition secondée en résolution
|
|
||||||
2. Les sections **ÉTANT DONNÉ QUE** et **LE GROUPE A DÉCIDÉ DE** sont obligatoires
|
|
||||||
3. Si adoptée, un numéro est attribué : `RES` pour une résolution, `NOM` pour une nomination, `DON` pour une contribution
|
|
||||||
|
|
||||||
### Rejeter une proposition
|
|
||||||
Un membre de l'exécutif peut rejeter une proposition en cours depuis C5.
|
|
||||||
|
|
||||||
### Lien avec le PV
|
|
||||||
Lors de la rédaction du PV (M1), le secrétaire peut **importer les propositions secondées** en un clic. Elles pré-remplissent la section décisions avec le sujet, le proposeur et le secondeur.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Réunion d'affaires mensuelle
|
|
||||||
|
|
||||||
### Avant la réunion
|
|
||||||
- Les membres soumettent leurs propositions via C5 (en tout temps)
|
|
||||||
- D'autres membres secondent les propositions recevables
|
|
||||||
|
|
||||||
### Pendant la réunion
|
|
||||||
1. **Secrétaire** : M2 (présences) → M1 (PV avec import des propositions)
|
|
||||||
2. **RSG** : M3 (rapport du district)
|
|
||||||
3. **Trésorier** : présente l'état des résultats et la position de trésorerie
|
|
||||||
4. **Exécutif** : transforme les propositions secondées en résolutions (C5)
|
|
||||||
|
|
||||||
### Après la réunion
|
|
||||||
Le secrétaire finalise le PV avec les décisions votées.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Envoi des contributions (M4)
|
|
||||||
|
|
||||||
1. Le trésorier ouvre **M4 — Envoi contributions**
|
|
||||||
2. Le montant disponible (après réserves) est affiché et pré-rempli
|
|
||||||
3. Sélectionner le destinataire (district par défaut) et la méthode (virement/chèque)
|
|
||||||
4. Enregistrer l'envoi
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Gestion des rapports PDF (C1)
|
|
||||||
|
|
||||||
| Rapport | URL API | Contenu |
|
|
||||||
|---------|---------|---------|
|
|
||||||
| État des résultats | `/api/rapports/etat-resultats/{annee}/{mois}` | Revenus + charges + excédent/déficit + trésorerie |
|
|
||||||
| Réunions du mois | `/api/rapports/reunions/{annee}/{mois}` | Réunions + thèmes |
|
|
||||||
|
|
||||||
> **Note :** les routes PDF nécessitent WeasyPrint installé sur le serveur.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Surveillance
|
|
||||||
|
|
||||||
### Vérifier que l'application tourne
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo systemctl status groupe-meditation
|
|
||||||
curl -s https://app.87-16.org/api/health
|
|
||||||
sudo journalctl -u groupe-meditation -f --no-pager
|
|
||||||
sudo tail -f /var/log/nginx/groupe-meditation-error.log
|
|
||||||
```
|
|
||||||
|
|
||||||
### Vérifier les sauvegardes
|
|
||||||
|
|
||||||
```bash
|
|
||||||
ls -la /var/backups/groupe-meditation/ | tail -5
|
|
||||||
```
|
|
||||||
|
|
||||||
### Statistiques base de données
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo -u postgres psql -d groupe_meditation -c "
|
|
||||||
SELECT schemaname, tablename, n_live_tup AS lignes
|
|
||||||
FROM pg_stat_user_tables
|
|
||||||
ORDER BY n_live_tup DESC;
|
|
||||||
"
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Opérations d'urgence
|
|
||||||
|
|
||||||
### L'API ne répond plus
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo systemctl restart groupe-meditation
|
|
||||||
sudo journalctl -u groupe-meditation --since "5 minutes ago"
|
|
||||||
```
|
|
||||||
|
|
||||||
### Un membre a oublié son PIN
|
|
||||||
|
|
||||||
Pas de récupération en libre-service (par design). L'exécutif doit :
|
|
||||||
1. Utiliser **G2** pour désactiver le membre
|
|
||||||
2. Créer une nouvelle invitation **G1**
|
|
||||||
3. Le membre se réinscrit avec un nouveau PIN
|
|
||||||
|
|
||||||
### Droit à l'oubli
|
|
||||||
|
|
||||||
1. Exécutif ouvre **G2 — Gérer les membres**
|
|
||||||
2. Sélectionne le membre → **Droit à l'oubli**
|
|
||||||
3. Le prénom et l'ID demeurent pour préserver l'historique
|
|
||||||
4. Le nom, le téléphone, l'identifiant de connexion, le PIN, les préférences de notification, les abonnements push et la date d'abstinence sont effacés ou neutralisés
|
|
||||||
5. Le compte ne peut plus être réactivé
|
|
||||||
|
|
||||||
### Restaurer la base après incident
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo systemctl stop groupe-meditation
|
|
||||||
sudo -u postgres dropdb groupe_meditation
|
|
||||||
sudo -u postgres createdb -O grpmed groupe_meditation
|
|
||||||
sudo -u postgres psql -d groupe_meditation -c "GRANT ALL ON SCHEMA public TO grpmed;"
|
|
||||||
pg_restore -U grpmed -h 127.0.0.1 -d groupe_meditation \
|
|
||||||
/var/backups/groupe-meditation/grpmed_DERNIER.dump
|
|
||||||
sudo systemctl start groupe-meditation
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Matrice des modules par rôle
|
|
||||||
|
|
||||||
| Module | RSG | RSG sub | Trés. | Secr. | Anim. | Litt. | Jetons | Tous |
|
|
||||||
|--------|:---:|:-------:|:-----:|:-----:|:-----:|:-----:|:------:|:----:|
|
|
||||||
| C1-C9 Consultation | | | | | | | | ✓ |
|
|
||||||
| S1 Collecte | ✓ | ✓ | ✓ | ✓ | | | | |
|
|
||||||
| S1T Trésorerie | | | ✓ | | | | | |
|
|
||||||
| S2 Remise jeton | | | | | | | ✓ | |
|
|
||||||
| S3 Vente litt. | | | | | | ✓ | | |
|
|
||||||
| S4 Rapport réunion | | | | | ✓ | | | |
|
|
||||||
| S5 Dépense | | | ✓ | | | | | |
|
|
||||||
| M1 PV | | | | ✓ | | | | |
|
|
||||||
| M2 Présences | | | | ✓ | | | | |
|
|
||||||
| M3 Rapport RSG | ✓ | ✓ | | | | | | |
|
|
||||||
| M4 Contributions | | | ✓ | | | | | |
|
|
||||||
| M5 Inventaire | | | | | | ✓ | | |
|
|
||||||
| M6 Commander jetons | | | | | | | ✓ | |
|
|
||||||
| G1-G9 Gestion | ✓ | ✓ | ✓ | ✓ | | | | |
|
|
||||||
|
|
||||||
> Le RSG substitut a exactement les mêmes accès que le RSG — continuité assurée.
|
|
||||||
> Un membre peut cumuler plusieurs postes. L'écran affiche l'union de tous ses modules.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Contacts et références
|
|
||||||
|
|
||||||
- **aa87.org** — Site de la Région 87
|
|
||||||
- **BSG** — Bureau des Services généraux (aa.org)
|
|
||||||
- Documentation API : `https://app.87-16.org/api/docs`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
*«Nos leaders sont des serviteurs de confiance ; ils ne gouvernent pas.» — 2e Tradition*
|
|
||||||
|
|
@ -1,679 +0,0 @@
|
||||||
# Manuel de l'utilisateur
|
|
||||||
|
|
||||||
Application du Groupe Méditation, pour les membres AA, les serviteurs et les membres de l'exécutif.
|
|
||||||
|
|
||||||
Ce manuel explique les processus de l'application en langage d'usage. Il ne remplace pas les traditions, les procédures du groupe ou la conscience de groupe; il décrit comment l'application aide à les appliquer.
|
|
||||||
|
|
||||||
## 1. Principes généraux
|
|
||||||
|
|
||||||
L'application sert à garder ensemble les informations courantes du groupe :
|
|
||||||
|
|
||||||
- les rencontres hebdomadaires;
|
|
||||||
- les assemblées d'affaires;
|
|
||||||
- les propositions, décisions, nominations et contributions;
|
|
||||||
- les collectes, dépenses, réserves et rapports de trésorerie;
|
|
||||||
- les membres, postes, mandats et permissions;
|
|
||||||
- la littérature, les jetons, les événements et les rapports.
|
|
||||||
|
|
||||||
Chaque membre voit les sections auxquelles il a accès selon ses postes actifs. Un membre peut consulter plusieurs informations du groupe. Les actions qui modifient la vie du groupe ou les finances sont réservées aux membres autorisés, généralement les postes exécutifs.
|
|
||||||
|
|
||||||
Le compte `Sysadmin` sert à l'administration initiale et aux interventions exceptionnelles. Il a tous les accès.
|
|
||||||
|
|
||||||
## 2. Connexion et profil
|
|
||||||
|
|
||||||
### Se connecter
|
|
||||||
|
|
||||||
1. Ouvrir l'application.
|
|
||||||
2. Choisir le groupe si l'application en présente plusieurs.
|
|
||||||
3. Saisir son identifiant ou courriel.
|
|
||||||
4. Saisir son PIN à 4 chiffres.
|
|
||||||
5. Cocher `Se souvenir de moi` seulement sur un appareil personnel.
|
|
||||||
6. Appuyer sur `Connexion`.
|
|
||||||
|
|
||||||
Si la connexion échoue, vérifier l'identifiant, le PIN et le groupe sélectionné. En navigation privée, la session ne réutilise pas les anciens caches ou anciennes données du navigateur.
|
|
||||||
|
|
||||||
### Se déconnecter
|
|
||||||
|
|
||||||
Le bouton `Déconnexion` est disponible dans l'entête des pages. Sur un appareil partagé, il faut toujours se déconnecter.
|
|
||||||
|
|
||||||
### Gérer son profil
|
|
||||||
|
|
||||||
Le module `Profil` permet de modifier ses informations personnelles :
|
|
||||||
|
|
||||||
- prénom;
|
|
||||||
- nom;
|
|
||||||
- téléphone;
|
|
||||||
- courriel ou identifiant;
|
|
||||||
- date d'abstinence;
|
|
||||||
- PIN.
|
|
||||||
|
|
||||||
Un membre peut aussi choisir les types de changements pour lesquels il souhaite être notifié, lorsque les notifications sont disponibles sur son appareil.
|
|
||||||
|
|
||||||
Le profil explique aussi quelles données personnelles sont conservées et pourquoi. Il affiche les postes actifs du membre et les modules visibles afin que chacun puisse comprendre d'où viennent ses accès.
|
|
||||||
|
|
||||||
### Notifications
|
|
||||||
|
|
||||||
Les notifications push sont optionnelles. Le membre choisit les catégories de changements qui l'intéressent depuis son profil. Les notifications dépendent aussi du navigateur, du téléphone et de l'autorisation donnée par l'utilisateur.
|
|
||||||
|
|
||||||
## 3. Navigation
|
|
||||||
|
|
||||||
L'application est organisée par contextes.
|
|
||||||
|
|
||||||
### Accueil
|
|
||||||
|
|
||||||
La page `Accueil` regroupe ce qu'un membre consulte souvent :
|
|
||||||
|
|
||||||
- choses à faire maintenant;
|
|
||||||
- état général du groupe;
|
|
||||||
- événements;
|
|
||||||
- littérature;
|
|
||||||
- profil;
|
|
||||||
- principes d'utilisation;
|
|
||||||
- mode papier;
|
|
||||||
- modules de consultation.
|
|
||||||
|
|
||||||
### Rencontres
|
|
||||||
|
|
||||||
La page `Rencontres` sert aux activités de la rencontre hebdomadaire. Les rencontres sont présentées sous forme de tuiles. Une tuile fermée montre l'essentiel : date, heure, sujet et animation. En l'ouvrant, les boutons liés à cette rencontre apparaissent.
|
|
||||||
|
|
||||||
### Assemblées
|
|
||||||
|
|
||||||
La page `Assemblées` sert aux assemblées d'affaires. Les assemblées sont aussi présentées sous forme de tuiles. Chaque assemblée regroupe les présences, l'ordre du jour, le rapport du trésorier, les décisions, les contributions, les postes à pourvoir et le rapport PDF.
|
|
||||||
|
|
||||||
### Gestion
|
|
||||||
|
|
||||||
La page `Gestion` regroupe les modules d'administration :
|
|
||||||
|
|
||||||
- gestion des membres;
|
|
||||||
- gestion des postes;
|
|
||||||
- gestion des mandats;
|
|
||||||
- paramètres du groupe;
|
|
||||||
- trésorerie;
|
|
||||||
- inventaire;
|
|
||||||
- journal.
|
|
||||||
|
|
||||||
Les boutons visibles dépendent des permissions du membre.
|
|
||||||
|
|
||||||
## 4. Rencontres hebdomadaires
|
|
||||||
|
|
||||||
### Planifier une rencontre
|
|
||||||
|
|
||||||
Un membre de l'exécutif peut planifier une rencontre.
|
|
||||||
|
|
||||||
1. Aller à `Rencontres`.
|
|
||||||
2. Appuyer sur `Planifier une rencontre`.
|
|
||||||
3. Choisir une date permise.
|
|
||||||
4. Renseigner le sujet, l'animateur et les notes utiles.
|
|
||||||
5. Créer la rencontre.
|
|
||||||
|
|
||||||
Les dates offertes respectent le jour de réunion configuré dans les paramètres du groupe. Les dates sont présentées de manière à éviter de choisir accidentellement une mauvaise année.
|
|
||||||
|
|
||||||
### Modifier une rencontre
|
|
||||||
|
|
||||||
Un membre de l'exécutif peut ouvrir une tuile de rencontre et utiliser l'action de modification pour corriger les informations de la rencontre.
|
|
||||||
|
|
||||||
### Saisir la collecte
|
|
||||||
|
|
||||||
Chaque rencontre peut avoir une seule collecte.
|
|
||||||
|
|
||||||
1. Ouvrir la tuile de la rencontre.
|
|
||||||
2. Appuyer sur `Collecte`.
|
|
||||||
3. Saisir le montant.
|
|
||||||
4. Indiquer qui détient l'argent.
|
|
||||||
5. Enregistrer.
|
|
||||||
|
|
||||||
La collecte suit ensuite son processus de confirmation et de réception par le trésorier. Lorsque le trésorier accuse réception, la transaction utilise la date de la collecte.
|
|
||||||
|
|
||||||
### Saisir une vente
|
|
||||||
|
|
||||||
Les ventes de littérature et les ventes de jetons sont saisies depuis la rencontre.
|
|
||||||
|
|
||||||
1. Ouvrir la tuile de la rencontre.
|
|
||||||
2. Appuyer sur `Ventes`.
|
|
||||||
3. Choisir le type de vente.
|
|
||||||
4. Renseigner l'article, la quantité, le montant et le membre qui détient l'argent.
|
|
||||||
5. Enregistrer.
|
|
||||||
|
|
||||||
L'argent d'une vente est traité comme l'argent d'une collecte : il doit être remis au trésorier avant d'entrer dans l'encaisse.
|
|
||||||
|
|
||||||
### Jetons et gâteaux
|
|
||||||
|
|
||||||
Les remises de jetons et les gâteaux servent aux statistiques et à la mémoire du groupe. Elles ne retirent pas automatiquement de jetons de l'inventaire. Seules les ventes de jetons affectent l'inventaire.
|
|
||||||
|
|
||||||
### Rapport PDF de rencontre
|
|
||||||
|
|
||||||
Chaque tuile de rencontre offre un bouton `Rapport PDF`. Le rapport est destiné à être imprimé au format lettre. Il rassemble les informations associées à la rencontre.
|
|
||||||
|
|
||||||
## 5. Assemblées d'affaires
|
|
||||||
|
|
||||||
### Planifier une assemblée
|
|
||||||
|
|
||||||
Un membre de l'exécutif peut planifier une assemblée d'affaires.
|
|
||||||
|
|
||||||
1. Aller à `Assemblées`.
|
|
||||||
2. Appuyer sur `Planifier une assemblée`.
|
|
||||||
3. Choisir une date permise.
|
|
||||||
4. Ajouter une note si nécessaire.
|
|
||||||
5. Créer l'assemblée.
|
|
||||||
|
|
||||||
Les dates offertes respectent les paramètres du groupe : jour de réunion et rang de l'assemblée mensuelle, par exemple première, deuxième, troisième, quatrième ou dernière réunion du mois.
|
|
||||||
|
|
||||||
### Comprendre la tuile d'assemblée
|
|
||||||
|
|
||||||
Une tuile d'assemblée contient le résumé de l'assemblée. En l'ouvrant, les sections de travail apparaissent :
|
|
||||||
|
|
||||||
- `Invitation`;
|
|
||||||
- `PV précédent`;
|
|
||||||
- `Présences`;
|
|
||||||
- `Rapport trésorier`;
|
|
||||||
- `Donner au suivant`;
|
|
||||||
- `Postes à pourvoir`;
|
|
||||||
- `Décisions`.
|
|
||||||
|
|
||||||
Le bouton `Rapport PDF` produit le procès-verbal et le rapport imprimable de l'assemblée. Le rapport PDF est le document officiel à consulter ou imprimer.
|
|
||||||
|
|
||||||
### Invitation à l'assemblée
|
|
||||||
|
|
||||||
L'application peut préparer un texte d'invitation à copier-coller. Ce texte contient un lien invité donnant accès à la page de l'assemblée en lecture seule.
|
|
||||||
|
|
||||||
Le lien invité :
|
|
||||||
|
|
||||||
- ne demande pas d'authentification;
|
|
||||||
- est contrôlé par une période de validité;
|
|
||||||
- ne montre pas de lien BBB permanent;
|
|
||||||
- sert à consulter l'ordre du jour ou les informations de l'assemblée.
|
|
||||||
|
|
||||||
### Présences
|
|
||||||
|
|
||||||
Les présences d'assemblée sont saisies dans la section `Présences`.
|
|
||||||
|
|
||||||
1. Ouvrir la tuile de l'assemblée.
|
|
||||||
2. Appuyer sur `Présences`.
|
|
||||||
3. Cocher les membres présents.
|
|
||||||
4. Enregistrer.
|
|
||||||
|
|
||||||
Une nouvelle saisie remplace la précédente pour cette assemblée.
|
|
||||||
|
|
||||||
### Procès-verbal précédent
|
|
||||||
|
|
||||||
Le procès-verbal précédent peut être consulté depuis l'assemblée courante. S'il n'est pas encore adopté, un exécutif peut le corriger puis l'adopter.
|
|
||||||
|
|
||||||
L'adoption demande :
|
|
||||||
|
|
||||||
- un proposeur;
|
|
||||||
- un secondeur;
|
|
||||||
- le contenu final corrigé au besoin.
|
|
||||||
|
|
||||||
L'adoption se fait en une seule étape avec le bouton `Adopter`.
|
|
||||||
|
|
||||||
### Rapport du trésorier
|
|
||||||
|
|
||||||
Avant de décider les contributions, le groupe doit adopter le rapport du trésorier.
|
|
||||||
|
|
||||||
1. Ouvrir la tuile de l'assemblée.
|
|
||||||
2. Appuyer sur `Rapport trésorier`.
|
|
||||||
3. Choisir un proposeur.
|
|
||||||
4. Choisir un secondeur.
|
|
||||||
5. Ajouter une correction ou une note si nécessaire.
|
|
||||||
6. Appuyer sur `Adopter le rapport`.
|
|
||||||
|
|
||||||
Une fois adopté, le rapport est cristallisé : il devient l'historique consultable et imprimable de la période concernée.
|
|
||||||
|
|
||||||
### Donner au suivant
|
|
||||||
|
|
||||||
Les contributions se décident pendant l'assemblée d'affaires.
|
|
||||||
|
|
||||||
1. Le rapport du trésorier doit d'abord être adopté.
|
|
||||||
2. Ouvrir la section `Donner au suivant`.
|
|
||||||
3. Choisir le destinataire.
|
|
||||||
4. Saisir le montant.
|
|
||||||
5. Choisir la méthode, par exemple chèque ou virement.
|
|
||||||
6. Choisir le proposeur et le secondeur.
|
|
||||||
7. Créer l'envoi.
|
|
||||||
|
|
||||||
L'application crée alors une décision de type `Contribution`. La contribution devient un engagement financier. Elle ne modifie pas le solde bancaire tant que le trésorier ne confirme pas le débit dans la trésorerie.
|
|
||||||
|
|
||||||
Le destinataire `District 87-16` existe par défaut et ne peut pas être supprimé.
|
|
||||||
|
|
||||||
### Postes à pourvoir pendant l'assemblée
|
|
||||||
|
|
||||||
La section `Postes à pourvoir` affiche les postes vacants.
|
|
||||||
|
|
||||||
Pour un poste vacant, un membre peut :
|
|
||||||
|
|
||||||
- postuler lui-même;
|
|
||||||
- proposer un autre membre, si l'interface lui en donne le droit.
|
|
||||||
|
|
||||||
Une nomination exige une décision du groupe. Elle demande un proposeur et un secondeur. Une nomination adoptée reçoit un numéro de type `NOM`.
|
|
||||||
|
|
||||||
### Décisions pendant l'assemblée
|
|
||||||
|
|
||||||
La section `Décisions` permet de travailler les propositions.
|
|
||||||
|
|
||||||
Un membre peut soumettre une proposition avec un objet et des détails. Une proposition n'a pas de type au départ.
|
|
||||||
|
|
||||||
Le cycle normal est :
|
|
||||||
|
|
||||||
1. proposition soumise;
|
|
||||||
2. proposition secondée;
|
|
||||||
3. adoption ou rejet par l'exécutif selon la décision du groupe.
|
|
||||||
|
|
||||||
Pour adopter une proposition comme résolution, l'exécutif doit renseigner :
|
|
||||||
|
|
||||||
- `ÉTANT DONNÉ QUE`;
|
|
||||||
- `LE GROUPE A DÉCIDÉ DE`.
|
|
||||||
|
|
||||||
Pour rejeter une proposition, l'exécutif doit aussi renseigner `ÉTANT DONNÉ QUE`, afin de conserver la raison historique du rejet.
|
|
||||||
|
|
||||||
Une résolution adoptée reçoit un numéro de type `RES`.
|
|
||||||
|
|
||||||
## 6. Gouvernance et décisions
|
|
||||||
|
|
||||||
Le module `Gouvernance` présente les décisions du groupe.
|
|
||||||
|
|
||||||
### Soumettre une proposition
|
|
||||||
|
|
||||||
1. Aller dans `Gouvernance` ou dans la section `Décisions` d'une assemblée.
|
|
||||||
2. Saisir l'objet de la proposition.
|
|
||||||
3. Ajouter les détails nécessaires.
|
|
||||||
4. Soumettre.
|
|
||||||
|
|
||||||
L'objet est obligatoire. Les détails servent à comprendre l'intention.
|
|
||||||
|
|
||||||
### Seconder une proposition
|
|
||||||
|
|
||||||
Un membre peut appuyer une proposition avec le bouton `Je seconde`. Un exécutif peut aussi seconder pour un autre membre depuis une liste déroulante.
|
|
||||||
|
|
||||||
Un membre ne doit normalement pas seconder sa propre proposition. Le compte `Sysadmin` peut le faire pour des interventions administratives ou de démonstration.
|
|
||||||
|
|
||||||
### Transformer en décision
|
|
||||||
|
|
||||||
Une proposition secondée peut devenir une décision du groupe. Les types de décisions sont :
|
|
||||||
|
|
||||||
- `Résolution`, préfixe `RES`;
|
|
||||||
- `Nomination`, préfixe `NOM`;
|
|
||||||
- `Contribution`, préfixe `DON`.
|
|
||||||
|
|
||||||
Les nominations et contributions sont des décisions du groupe avec leurs propres processus.
|
|
||||||
|
|
||||||
### Historique
|
|
||||||
|
|
||||||
L'historique des résolutions permet de consulter les décisions adoptées et leurs détails. Les rapports PDF de résolutions présentent les décisions prises en groupe.
|
|
||||||
|
|
||||||
## 7. Trésorerie
|
|
||||||
|
|
||||||
Le module `Trésorerie` est consultable par les membres selon les permissions. Les actions de modification sont réservées au trésorier ou aux exécutifs.
|
|
||||||
|
|
||||||
### Page d'accueil de la trésorerie
|
|
||||||
|
|
||||||
La page d'accueil présente :
|
|
||||||
|
|
||||||
- positions de trésorerie;
|
|
||||||
- réserves;
|
|
||||||
- éléments à traiter.
|
|
||||||
|
|
||||||
Les positions de trésorerie incluent :
|
|
||||||
|
|
||||||
- solde bancaire;
|
|
||||||
- encaisse;
|
|
||||||
- disponible;
|
|
||||||
- engagements;
|
|
||||||
- réserves.
|
|
||||||
|
|
||||||
Le montant de l'encaisse est considéré disponible. Le solde disponible n'est pas une réserve : il correspond au solde bancaire moins les réserves et engagements.
|
|
||||||
|
|
||||||
### Résultats
|
|
||||||
|
|
||||||
La page `Résultats` présente l'état des résultats pour un mois choisi :
|
|
||||||
|
|
||||||
- revenus;
|
|
||||||
- charges;
|
|
||||||
- excédent ou déficit.
|
|
||||||
|
|
||||||
Le bouton `Rapport PDF` produit le rapport mensuel. Le rapport PDF utilise l'état des résultats du mois précédent et les positions de trésorerie en date du dernier jour du mois précédent.
|
|
||||||
|
|
||||||
### Registre
|
|
||||||
|
|
||||||
Le registre affiche les transactions, les plus récentes d'abord. Il peut être filtré par mois, année et type de transaction.
|
|
||||||
|
|
||||||
Le registre permet de suivre :
|
|
||||||
|
|
||||||
- collectes reçues;
|
|
||||||
- ventes reçues;
|
|
||||||
- dépenses payées;
|
|
||||||
- contributions débitées;
|
|
||||||
- dépôts;
|
|
||||||
- retraits;
|
|
||||||
- virements de réserves.
|
|
||||||
|
|
||||||
### Éléments à traiter
|
|
||||||
|
|
||||||
La section `À traiter` regroupe les mouvements qui attendent une action.
|
|
||||||
|
|
||||||
On peut y trouver :
|
|
||||||
|
|
||||||
- dépenses soumises;
|
|
||||||
- dépenses bancaires en attente de débit;
|
|
||||||
- contributions en attente de débit;
|
|
||||||
- collectes à recevoir;
|
|
||||||
- ventes à recevoir.
|
|
||||||
|
|
||||||
Tous les membres autorisés peuvent voir ces éléments. Seuls les exécutifs ou le trésorier peuvent confirmer les mouvements.
|
|
||||||
|
|
||||||
### Dépenses
|
|
||||||
|
|
||||||
Un membre peut soumettre une dépense en son nom.
|
|
||||||
|
|
||||||
Un exécutif peut soumettre une dépense au nom d'un autre membre.
|
|
||||||
|
|
||||||
La date normale est la date de soumission. Le compte `Sysadmin` peut saisir une date antérieure pour inscrire des informations à posteriori.
|
|
||||||
|
|
||||||
Le processus est :
|
|
||||||
|
|
||||||
1. le membre soumet la dépense;
|
|
||||||
2. le trésorier ou l'exécutif la traite;
|
|
||||||
3. si elle est payée en encaisse, l'encaisse est ajustée immédiatement;
|
|
||||||
4. si elle est payée par chèque ou virement, elle devient un engagement;
|
|
||||||
5. le débit bancaire est confirmé plus tard quand il apparaît;
|
|
||||||
6. la dépense peut être rejetée tant qu'elle n'est pas traitée.
|
|
||||||
|
|
||||||
Une dépense bancaire ne peut pas être acceptée si le solde disponible ne le permet pas.
|
|
||||||
|
|
||||||
### Collectes et ventes reçues
|
|
||||||
|
|
||||||
Quand le trésorier reçoit l'argent d'une collecte ou d'une vente, il accuse réception. L'argent entre alors dans l'encaisse.
|
|
||||||
|
|
||||||
Pour une collecte, la date de transaction est la date de la collecte.
|
|
||||||
|
|
||||||
### Dépôts et dons
|
|
||||||
|
|
||||||
Un dépôt peut provenir de deux sources :
|
|
||||||
|
|
||||||
- l'encaisse;
|
|
||||||
- un don direct au compte bancaire.
|
|
||||||
|
|
||||||
Un dépôt depuis l'encaisse déplace l'argent de l'encaisse vers la banque. Un don direct augmente la banque sans diminuer l'encaisse.
|
|
||||||
|
|
||||||
### Retraits
|
|
||||||
|
|
||||||
Un retrait déplace de l'argent de la banque vers l'encaisse. Il ne doit pas rendre les réserves impossibles à couvrir.
|
|
||||||
|
|
||||||
### Réserves
|
|
||||||
|
|
||||||
Une réserve représente une partie du solde bancaire affectée à un usage précis.
|
|
||||||
|
|
||||||
Règles importantes :
|
|
||||||
|
|
||||||
- une réserve se crée à zéro;
|
|
||||||
- son montant ne se modifie pas directement;
|
|
||||||
- les changements passent par un virement;
|
|
||||||
- une réserve ne peut être supprimée que si son solde est zéro;
|
|
||||||
- le total des réserves ne doit pas dépasser le solde bancaire.
|
|
||||||
|
|
||||||
### Virements entre réserves
|
|
||||||
|
|
||||||
La fonction `Virement` permet de déplacer un montant :
|
|
||||||
|
|
||||||
- du disponible vers une réserve;
|
|
||||||
- d'une réserve vers le disponible;
|
|
||||||
- d'une réserve vers une autre réserve.
|
|
||||||
|
|
||||||
Ces mouvements sont virtuels, mais ils apparaissent au registre pour conserver l'historique.
|
|
||||||
|
|
||||||
## 8. Postes, mandats et permissions
|
|
||||||
|
|
||||||
### Postes à pourvoir
|
|
||||||
|
|
||||||
Le module `Postes à pourvoir` affiche les postes disponibles sous forme de tuiles.
|
|
||||||
|
|
||||||
En ouvrant un poste, le membre peut voir :
|
|
||||||
|
|
||||||
- description;
|
|
||||||
- candidats;
|
|
||||||
- bouton `Postuler`;
|
|
||||||
- bouton `Proposer`.
|
|
||||||
|
|
||||||
`Postuler` sert à proposer sa propre candidature. `Proposer` sert à proposer un autre membre.
|
|
||||||
|
|
||||||
### Gestion des postes
|
|
||||||
|
|
||||||
La gestion des postes permet aux exécutifs de définir la structure de service du groupe.
|
|
||||||
|
|
||||||
Pour chaque poste, on peut gérer :
|
|
||||||
|
|
||||||
- nom;
|
|
||||||
- catégorie;
|
|
||||||
- description;
|
|
||||||
- attentes;
|
|
||||||
- permissions;
|
|
||||||
- abolition ou réactivation.
|
|
||||||
|
|
||||||
Le bouton `Permissions` permet d'associer ou dissocier les modules accessibles à un poste. Les permissions d'un membre viennent de ses postes actifs.
|
|
||||||
|
|
||||||
### Gestion des mandats
|
|
||||||
|
|
||||||
La gestion des mandats sert à suivre les affectations :
|
|
||||||
|
|
||||||
- qui occupe quel poste;
|
|
||||||
- depuis quelle date;
|
|
||||||
- quel mandat est terminé;
|
|
||||||
- quelles rotations sont prévues.
|
|
||||||
|
|
||||||
Terminer un mandat conserve l'historique. Une nouvelle affectation peut ensuite être créée.
|
|
||||||
|
|
||||||
## 9. Membres
|
|
||||||
|
|
||||||
### Gestion des membres
|
|
||||||
|
|
||||||
Les exécutifs peuvent gérer les membres :
|
|
||||||
|
|
||||||
- consulter les membres actifs, inactifs et anonymisés;
|
|
||||||
- créer un compte pour un membre;
|
|
||||||
- générer des invitations;
|
|
||||||
- désactiver ou réactiver le droit de connexion d'un membre;
|
|
||||||
- corriger certaines informations;
|
|
||||||
- utiliser les actions administratives permises.
|
|
||||||
|
|
||||||
Le droit à l'oubli est distinct de la désactivation. Il conserve l'ID et le prénom pour préserver l'historique, mais efface ou neutralise les autres renseignements personnels et empêche toute réactivation du compte.
|
|
||||||
|
|
||||||
Le compte `Sysadmin` est protégé contre la désactivation et le droit à l'oubli.
|
|
||||||
|
|
||||||
### Invitations de membres
|
|
||||||
|
|
||||||
Une invitation permet à un nouveau membre de créer son compte. Le code d'invitation expire et ne peut servir qu'une seule fois.
|
|
||||||
|
|
||||||
### Impersonification
|
|
||||||
|
|
||||||
Le compte `Sysadmin` peut impersonifier un membre pour diagnostiquer, corriger ou démontrer une situation. Les actions restent journalisées avec l'information d'impersonification.
|
|
||||||
|
|
||||||
## 10. Littérature et jetons
|
|
||||||
|
|
||||||
### Consulter la littérature
|
|
||||||
|
|
||||||
Le module `Littérature` affiche le catalogue :
|
|
||||||
|
|
||||||
- titre;
|
|
||||||
- catégorie;
|
|
||||||
- prix;
|
|
||||||
- quantité;
|
|
||||||
- alertes de stock bas.
|
|
||||||
|
|
||||||
### Gérer l'inventaire
|
|
||||||
|
|
||||||
Le responsable de la littérature ou l'exécutif peut :
|
|
||||||
|
|
||||||
- ajouter un titre;
|
|
||||||
- modifier un titre;
|
|
||||||
- ajuster les quantités;
|
|
||||||
- suivre les stocks.
|
|
||||||
|
|
||||||
L'inventaire initial peut être chargé depuis le fichier de prix prévu au déploiement.
|
|
||||||
|
|
||||||
### Ventes de littérature
|
|
||||||
|
|
||||||
Les ventes sont saisies lors d'une rencontre. Une vente diminue l'inventaire et crée un montant à remettre au trésorier. Lorsque le trésorier reçoit l'argent, l'encaisse est mise à jour.
|
|
||||||
|
|
||||||
### Jetons
|
|
||||||
|
|
||||||
Les remises de jetons servent aux statistiques. Les ventes de jetons affectent l'inventaire. Les commandes suggérées s'appuient sur l'utilisation récente.
|
|
||||||
|
|
||||||
## 11. Événements et calendrier
|
|
||||||
|
|
||||||
Le module `Événements` affiche :
|
|
||||||
|
|
||||||
- anniversaires de sobriété;
|
|
||||||
- événements créés par le groupe;
|
|
||||||
- événements passés et futurs.
|
|
||||||
|
|
||||||
Les filtres peuvent être combinés. Les exécutifs peuvent créer ou supprimer des événements.
|
|
||||||
|
|
||||||
Le calendrier permet aussi de consulter certains éléments liés aux serviteurs et au district, selon les modules disponibles.
|
|
||||||
|
|
||||||
## 12. Rapports PDF
|
|
||||||
|
|
||||||
Les rapports PDF servent à imprimer ou archiver les informations du groupe.
|
|
||||||
|
|
||||||
Les rapports importants sont :
|
|
||||||
|
|
||||||
- rapport de rencontre;
|
|
||||||
- rapport d'assemblée d'affaires;
|
|
||||||
- rapport de trésorerie;
|
|
||||||
- registre des résolutions;
|
|
||||||
- rapports disponibles selon les modules actifs.
|
|
||||||
|
|
||||||
Le rapport d'assemblée d'affaires tient lieu de procès-verbal imprimable. Il reprend les intrants de l'assemblée.
|
|
||||||
|
|
||||||
Le rapport de trésorerie présente les résultats du mois précédent et les positions de trésorerie à la fin de ce mois.
|
|
||||||
|
|
||||||
### Mode papier
|
|
||||||
|
|
||||||
Le module `Mode papier` offre des formulaires vierges imprimables pour :
|
|
||||||
|
|
||||||
- rencontre hebdomadaire;
|
|
||||||
- assemblée d'affaires;
|
|
||||||
- trésorerie.
|
|
||||||
|
|
||||||
Ces formulaires servent de plan de secours. Ils permettent de continuer les activités du groupe si l'application ou le réseau ne sont pas disponibles, puis de ressaisir les données plus tard.
|
|
||||||
|
|
||||||
### Principes d'utilisation
|
|
||||||
|
|
||||||
Le module `Principes d'utilisation` rappelle que l'application est un outil de service. Elle soutient le groupe, mais ne remplace pas la conscience de groupe, la discussion ni les processus papier lorsque nécessaires.
|
|
||||||
|
|
||||||
## 13. Journal
|
|
||||||
|
|
||||||
Le journal conserve les actions modificatrices faites dans l'application.
|
|
||||||
|
|
||||||
Il aide à répondre aux questions :
|
|
||||||
|
|
||||||
- qui a fait quoi;
|
|
||||||
- quand l'action a été faite;
|
|
||||||
- depuis quel chemin de l'application;
|
|
||||||
- avec quel résultat technique.
|
|
||||||
|
|
||||||
Le journal présente deux niveaux : l'historique métier, qui explique les changements importants en langage courant, et le journal technique, qui montre les appels API enregistrés.
|
|
||||||
|
|
||||||
Les consultations simples ne sont pas journalisées comme actions modificatrices. Le journal est réservé aux exécutifs.
|
|
||||||
|
|
||||||
Le journal doit servir à comprendre les changements et protéger l'historique, pas à surveiller les membres.
|
|
||||||
|
|
||||||
Tous les modules ne sont pas équivalents en journalisation. Les actions techniques sont enregistrées largement par l'API. L'historique métier détaillé, avec raison et valeurs avant/après, existe pour les processus sensibles déjà instrumentés : trésorerie, réserves, collectes, dépenses, gouvernance, procès-verbaux, rencontres, contributions, littérature et gestion des membres.
|
|
||||||
|
|
||||||
## 14. Modifications simultanées
|
|
||||||
|
|
||||||
Il peut arriver que deux membres exécutifs travaillent sur la même information en même temps.
|
|
||||||
|
|
||||||
Pour éviter qu'une personne écrase sans le savoir le travail d'une autre, l'application vérifie la version de certaines données sensibles au moment de l'enregistrement :
|
|
||||||
|
|
||||||
- décisions et propositions;
|
|
||||||
- procès-verbaux;
|
|
||||||
- collectes;
|
|
||||||
- dépenses;
|
|
||||||
- contributions à débiter;
|
|
||||||
- réserves;
|
|
||||||
- destinataires de contributions;
|
|
||||||
- rencontres;
|
|
||||||
- inventaire de littérature.
|
|
||||||
|
|
||||||
Si une donnée a changé pendant qu'elle était ouverte à l'écran, l'application refuse l'enregistrement et demande de recharger les données. Dans ce cas, il faut revenir à la liste ou recharger la page, relire l'information à jour, puis refaire l'action si elle est encore pertinente.
|
|
||||||
|
|
||||||
Le journal permet ensuite de voir qui a effectué les changements.
|
|
||||||
|
|
||||||
## 15. Paramètres du groupe
|
|
||||||
|
|
||||||
Les paramètres du groupe définissent notamment :
|
|
||||||
|
|
||||||
- nom du groupe;
|
|
||||||
- coordonnées;
|
|
||||||
- jour de réunion;
|
|
||||||
- heure de réunion;
|
|
||||||
- rang de l'assemblée d'affaires mensuelle.
|
|
||||||
|
|
||||||
Ces paramètres influencent les dates offertes dans les rencontres, assemblées et collectes. Une mauvaise configuration peut rendre certaines dates indisponibles.
|
|
||||||
|
|
||||||
## 16. Données de démonstration et remise à zéro
|
|
||||||
|
|
||||||
Le compte `Sysadmin` dispose d'actions spéciales pour l'administration :
|
|
||||||
|
|
||||||
- remettre la base de données à zéro;
|
|
||||||
- initialiser une base fictive de démonstration.
|
|
||||||
|
|
||||||
Ces actions effacent les données courantes. Elles sont prévues pour les tests, les démonstrations ou les environnements non productifs. Elles ne doivent pas être utilisées sur une base en production sans décision explicite.
|
|
||||||
|
|
||||||
## 17. Bonnes pratiques
|
|
||||||
|
|
||||||
- Utiliser l'application sur un appareil personnel lorsque possible.
|
|
||||||
- Se déconnecter sur un appareil partagé.
|
|
||||||
- Vérifier la date avant de saisir une rencontre, une assemblée ou une collecte.
|
|
||||||
- Utiliser les rapports PDF pour les documents imprimés.
|
|
||||||
- Ne pas contourner la conscience de groupe : les décisions importantes doivent passer par proposition, secondeur et adoption.
|
|
||||||
- Saisir les remises d'argent dès que possible afin que l'encaisse et les rapports restent fiables.
|
|
||||||
- Garder les postes et permissions à jour pour que chaque membre voie les bons modules.
|
|
||||||
- Consulter le journal en cas de doute sur une modification.
|
|
||||||
|
|
||||||
## 18. Résumé des principaux processus
|
|
||||||
|
|
||||||
### Proposition vers résolution
|
|
||||||
|
|
||||||
1. Un membre soumet une proposition.
|
|
||||||
2. Un membre la seconde.
|
|
||||||
3. L'exécutif renseigne les sections décisionnelles.
|
|
||||||
4. Le groupe adopte ou rejette.
|
|
||||||
5. L'application conserve l'historique.
|
|
||||||
|
|
||||||
### Nomination
|
|
||||||
|
|
||||||
1. Un poste est disponible.
|
|
||||||
2. Un membre postule ou est proposé.
|
|
||||||
3. Une nomination est décidée par le groupe.
|
|
||||||
4. L'application crée la décision `NOM`.
|
|
||||||
5. Le mandat est actif ou refusé selon le traitement.
|
|
||||||
|
|
||||||
### Contribution
|
|
||||||
|
|
||||||
1. Le rapport du trésorier est adopté.
|
|
||||||
2. Le groupe décide une contribution.
|
|
||||||
3. L'application crée une décision `DON`.
|
|
||||||
4. La contribution devient un engagement.
|
|
||||||
5. Le trésorier confirme le débit bancaire.
|
|
||||||
|
|
||||||
### Collecte
|
|
||||||
|
|
||||||
1. La collecte est saisie pour une rencontre.
|
|
||||||
2. Le montant est confirmé.
|
|
||||||
3. Le trésorier reçoit l'argent.
|
|
||||||
4. L'encaisse est mise à jour.
|
|
||||||
|
|
||||||
### Dépense
|
|
||||||
|
|
||||||
1. Un membre soumet une dépense.
|
|
||||||
2. Le trésorier ou l'exécutif la traite.
|
|
||||||
3. Elle est payée par encaisse ou engagée par banque.
|
|
||||||
4. Le débit bancaire est confirmé si nécessaire.
|
|
||||||
5. Le registre conserve la transaction.
|
|
||||||
|
|
||||||
### Réserve
|
|
||||||
|
|
||||||
1. Une réserve est créée à zéro.
|
|
||||||
2. Un virement affecte de l'argent à la réserve.
|
|
||||||
3. Les mouvements sont historisés.
|
|
||||||
4. La réserve peut être supprimée seulement si son solde revient à zéro.
|
|
||||||
Loading…
Reference in a new issue