====== 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)