groupe-meditation/docs/30_REGLES_METIER.md

9 KiB

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.

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.