Cahier des charges : Projet plateforme associative [Wiki GInfo]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 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)