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)