Cahier des charges : Projet plateforme associative
Les besoins sont tous représentés par un item dans la catégorie lui correspondant.
Les passages surlignés en vert sont sujets à discussion.
Plate-forme associative
Réglementation
- La plateforme doit comporter une page mentions légales sur laquelle sera décrite les informations sur l’hébergeur. (GInfo, UA, OVH ?)
- La plateforme doit comporter une charte d’utilisation des données personnelles.
- Les personnes ayant accès au serveur de production doivent être clairement identifiées (administrateurs de la plate-forme)
- Les personnes ayant des droits sur la plateforme (administrateurs) doivent être clairement identifiés et indiqués sur une page
Aspect
- La plateforme doit avoir sa propre identité visuelle, reconnaissable facilement par la communauté centralienne.
- La page d’accueil du site doit permettre l’accès facile à la connexion et à l’inscription.
Hébergement
- La plateforme doit être disponible uniquement sous HTTPS.
- L’hébergement de celle-ci doit être monitoré par une machine externe pouvant prévenir les administrateurs en cas de down.
- Seules des personnes ayant connaissance des proccess de déploiement et de maintenance pourront accéder à la plateforme de production.
Module membres
Que doit-on savoir sur les membres ? Pourquoi ?
De manière obligatoire :
- Nom & prénom (Identification unique)
- Date de naissance (Identification unique)
- Adresse e-mail (Identification unique)
- Promotion entrante (Identification unique. Prévoir le cas prof/personnel)
- Données techniques :
- Datetime d’inscription
- Consentement sur l’affichage des cotisations d’une personne sur son profil
- Datetime de dernière connexion (NULL si jamais fait)
- Dernière IP connue ? (Besoin pour raison légales ? Idk)
- Informations supplémentaires facultatives :
- Numéro de téléphone (Information de contact supplémentaire)
- Permis (Voiture, moto, bateau, …?)
- Régime alimentaire (Allergies, aliment non consommé, vg…)
- Compétences ?
- Réseaux sociaux (FB, Twitter, Linkedin…)
- Photo de profil ?
- Les membres pourront avoir un rang sur la plate-forme :
- Membre
- Administrateur
- Distinction dans le rang entre centralien/non centralien ?
L’inscription
- 2 modes d’inscription différents : Centraliens & extés.
- Aucun mot de passe ne doit être saisi sur la page d’inscription (pc publics…)
- Inscription d’un centralien :
- Celui-ci entre son nom d’utilisateur centrale, ainsi que Nom, prénom, date naissance, nom d’utilisateur centrale, numéro de tél et promo entrante.
- A l’issue de cette saisie un mail est envoyé à username@centrale-marseille.fr avec un mot de passe généré aléatoirement.
- Inscription d’un exté :
- Même proccess avec adresse mail au lieu de nom d’utilisateur.
- Vérification si l’adresse mail contient @centrale-marseille.fr, @ec-m.fr, @egim-mrs.fr etc…
- Nom d’utilisateur généré par l’application en fct du nom/prénom. Préfixe ? (extXXXX) → MAIL
- Stand rentrée : Prévoir un moyen pour que les admins plateforme aient la liste des correspondances username/nom prénom pour aider les éventuelles personnes qui ne connaîtraient pas leur nom d’utilisateur.
- Au moment d’une cotisation par une asso : Possibilité d’ajouter un utilisateur avec données mini (Nom, Prénom, Contact (mail/tel), date naissance) + envoi de mail avec la possibilité
Interface utilisateur
Données personnelles
Module associations
Données à avoir sur les associations
- Obligatoire :
- Nom
- Logo
- Type (Asso, sous-com…) et dépendance (asso parente)
- Information de contact (Adresse mail, postale, n° tél)
- Serait bien (rendre obligatoire ?)
- Documents légaux (Statuts, réglement intérieur) → Dans tous les cas sur demande n’importe qui doit avoir accès à ces documents.
- Date de création
- Facultatif
- Site web
- Réseaux sociaux (FB, Twitter)
Gestion des associations
- Création
- L’association est créée dans l’application par un administrateur.de la plate-forme.
- L’administrateur donne les droits sur l’application à une personne gérant l’association
- Pour les sous-com :
- Liste des cotisants hérités de l’asso parente
- Les sous com peuvent rajouter que des rangs.
- Rôles
- La gestion d’une association est indépendante de la liste des cotisants
- Différents rôles dans une association ? Consultation, édition, secrétariat ?
- Dans le cas de rôles différents :
- Consultation : Membre de la team, consulte les cotisants, données mais ne peut en rajouter.
- Secrétariat : a la main sur la liste des cotisants
- Edition (Admin) : a la main sur tous les aspects de l’asso
- Les accès sont attribués à un compte de la plateforme.
- Configuration :
- La configuration de l’asso doit permettre d’éditer toutes les données du premier point
- La config doit également permettre de configurer les durées types des cotisations
- La config doit permettre d’éditer des mentions particulières sur les bulletins de cotisation
Gestion des adhérents
- Cotisations
- Uniquement les personnes habilités pourront ajouter/supprimer des adhérents
- Une adhésion doit comporter les informations suivantes :
- Adhérent
- Date de début (Par défaut date du jour)
- Durée (Non entrée en BDD : sert à la date de fin)
- Date de fin (Calculée en fonction de la durée entrée)
- Moyen de paiement (Avec possibilité de champ texte pour infos complémentaires)
- Ajouté par ? (Traçabilité interne ?)
- Information complémentaire ? Sous forme de champ texte.
- Lors de l’ajout d’une adhésion, l’adhérent reçoit une notification (mail?) comprenant son bulletin d’adhésion.
- Lors de l’ajout d’une adhésion, une case à cocher exprime le consentement de l’adhérent. La personne effectuant la saisie doit avoir eu l’autorisation de récupérer les données personnelles de la personne, à l’oral ou à l’écrit.
- Lors de l’adhésion d’un membre, les données personnelles de celui-ci (contact) deviennent accessible par l’association.
- Rangs :
- Toute personne ayant le droit secrétariat aura le droit d’assigner un rang à un utilisateur.
- Le rang sera un constitué d’un champ de texte et d’un champ année.
Groupes (en projet, non adopté)
- Une association doit pouvoir créer des groupes, hiérarchiques (Un groupe peut en contenir d’autres), ces groupes peuvent contenir des adhérents.
- Dans l’idée que j’ai, on fait un groupe par mandat, par pôle, par… jsp. Les membres d’un groupe sont membres de tous les groupes parents du groupe… ) Ceci permettra une gestion assez fine dans les outils de gestion asso plus tard, et permettra une traçabilité dans tous les cas.
- Les membres d’un groupe peuvent avoir une information texte en plus. (Par exemple : poste…)
Certains adhérents du groupe peuvent être responsable du groupe et ainsi ajouter/supprimer des personnes.
- Les personnes habilités doivent pouvoir lister les personnes du groupe et voir facilement leur statut de cotisation.
- Il doit être possible d’extraire facilement les données sur les membres d’un groupe. (CSV, vcard, PDF+QRCODE?)
- Des personnes n’étant pas membres de l’association peuvent être ajoutées à des groupes de celles-ci.
- Cas d’utilisation : personnes intéressés, présence à un événement, participation à une activité ne nécessitant pas la cotisation…
- Un groupe peut être liée à une mailing list centrale, les membres étant ajouté dans le groupe sont automatiquement ajoutés à la ML → à voir coté technique.
Module connexion
Le module connexion doit permettre à l’utilisateur de se connecter à des applications extérieures et d’accéder après consentement explicite aux ressources précédemment explicitées. Les plateforme externes n’auront accès ni plus ni moins à ce que l’utilisateur peut accéder. (Délégation de droits)
Applications externes
- Les applications externes seront ajoutées par les administrateurs de la plate-forme.
- L’utilisation de celle-ci se fera à l’aide d’un jeu de clés publiques/privées unique à chaque application et identifiant celle-ci.
- Les utilisateurs doivent pouvoir créer des applications de test pour le développement, limitées dans les ressources.
- Les applications externes seront configurées pour demander certains droits aux utilisateurs. Elles n’auront pas accès à plus d’informations que nécessaire.
- Les applications externes devront respecter une charte/convention, leur déléguant la responsabilité sur les données qu’elles hébergent et leur donnant un cadre sur l’utilisation des ressources de la plateforme.
API
- Le protocol utilisé sera OAuth2. (Standardisé et utilisé par FB, Twitter, correspond exactement au besoin)
- L’API se présentera sous la forme d’une API REST.
- Des codes d’exemple et une documentation publiques seront mises en place.
- L’API permettra d’accéder aux objets suivants selon la visibilité de l’utilisateur :
- Utilisateur courant (consultation/édition si droit )
- Associations (consultation)
- Cotisants associations (consultation si droit/édition si droit)
- Groupes associations (consultation si droit/édition si droit)