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.

  • 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
  • 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.
  • 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.

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 ?
  • 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é
  • 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)
  • 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
  • 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.
  • 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.

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)

  • 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.
  • 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)
  • projets/mca/cdc.txt
  • Dernière modification : 14/11/2018 11:26
  • de rgrondin