Evolution #22

Renseigner accueil de groupe dans les sessions

Added by Denis LIARD about 12 years ago. Updated over 10 years ago.

Status:Fermé Start date:04/28/2010
Priority:Urgent Due date:
Assignee:Grégory MARIGOT - TEICEE % Done:

100%

Category:-
Target version:ProxyEPN 2.1
Version ProxyEPN:1.1.1

Description

A004 – 25/03/10
Log : animateur
Fenêtre : Programme/Session/atelier
Proposition : pouvoir renseigner le fait qu'un groupe est positionné sur une session de type atelier afin d'alimenter les stats (exemple école).

Associated revisions

Revision 433
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #22: Ajout du champs 'group_nb' dans la table des usagers pour la gestion future des inscription de groupes

Revision 461
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #22: Gestion de la notion de groupe (avec nb de personne par défaut) sur la création/édition des fiches usagers

Revision 463
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #22: Gestion des inscriptions de groupes sur les sessions (nb de personnes pris en compte sur les ateliers)

Revision 464
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #22: Amélioration du retour d'info après inscription (liste des sessions complètes, nb de personnes pour les comptes de groupes)

Revision 465
Added by Grégory MARIGOT - TEICEE about 11 years ago

FIX #22: Controles et bridages sur modification d'inscription pour éviter un dépassement du nombre max d'inscrits sur un atelier

History

Updated by Grégory MARIGOT - TEICEE about 12 years ago

  • Status changed from Nouveau to In Progress
  • Assignee set to Grégory MARIGOT - TEICEE
  • Version ProxyEPN set to 1.1.1

L'idée actuellement pour permettre une gestion simple des groupes est la suivante :

  • Définir un nouveau type de session, nommé par ex "Atelier de groupe"
  • Ce type de session serait très proche des sessions d'atelier, pour lesquels on renseigne un nombre de participants. Sauf que ce nombre, au lieu de n'être que le nombre prévu d'usagers, serait directement considéré comme le nombre d'inscrits.
  • Ceci permet de ne pas avoir à inscrire chacun des participants, tout en fournissant un nombre d'usagers qui pourra être exploité dans les statistiques.

A ce stade, les participants sont totalement anonymes, nous n'en avons que le nombre.
Peut-être est-il souhaitable d'identifier un minimum le groupe ?

Les possibilités que j'imagine :
  • Se contenter des infos libres de la session, son nom et sa description, pour détailler de manière informative (mais non "traitable" d'un point de vue stats) de quoi/qui il s'agit.
  • Ajouter un champs spécifique pour décrire la nature du groupe (champs libre ? choix parmis une liste de types de groupe ?)
  • Attacher un contact unique, mais qui peut correspondre à un groupe particulier plutot qu'à une personne. Ceci permettrait d'avoir des données statistiques (tranche d'age, etc..) mais elles seront alors communes au groupe (éventuellement ajouté un booléen sur les contacts pour flagger ceux correspondant à des groupes).
  • Avoir une notion réelle et complète de groupes, en plus des contacts. Les groupes sont gérés à part entière, avec les données qui leur sont propres.
  • Pousser la gestion des groupes précédente jusqu'à gérer l'appartenance des contacts dans les groupes. L'identification des usagers et les données stats sont totales... Mais celà signifie que tous les membres doivent exister individuellement sous forme de contacts.

Il me semble que l'intérêt des groupes va au delà de la simplification des inscriptions, que la création individuelle de tous les contacts membres est généralement superflue.
Mais si la finalité est principalement la génération des rapports statistiques, avoir simplement le nombre d'usager sans autre information n'est peut-être pas suffisant ?

Bref, la solution recherchée est sans doute un juste milieu à déterminer en fonction des réels besoins et de la simplicité d'usage attendue...

Les questions sont posées, j'attends les retours ;)

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • % Done changed from 0 to 10

Modifications publiées sur le svn (r433) :

Différenciation sur les fiches usagers

Dans l'optique de cette évolution, un champs a d'ors et déjà été ajouté dans la table des usagers afin de contenir une information numérique : le nombre de personne physique représentée par cette fiche.

Par défaut ce nombre est à 1, il serait possible sur le formulaire de création/édition d'un usager de préciser qu'il s'agit d'un compte de type "groupe" auxquel cas le nombre devient modifiable.

L'idée est de conserver les types de sessions actuelles et de voir pour y intégrer la prise en compte de cette valeur. Idéalement le nombre précisé sur la fiche ne serait qu'une valeur par défaut redéfinissable au moment de l'inscription à une session.

Modification de la base de données :

ALTER TABLE sf_guard_user_profile ADD group_nb SMALLINT NOT NULL DEFAULT '1' AFTER internet_options;

Note: tant que ce champs n'est pas utilisé il reste masqué dans l'interface.

Updated by Denis LIARD about 11 years ago

  • Priority changed from Normal to Urgent

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • Target version set to ProxyEPN 2.1

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • % Done changed from 10 to 40

Modifications publiées sur le svn (r461) :

Le champs group_nb précédement introduit dans la table sf_guard_user_profile est maintenant utilisé par le module usager de l'application :
  • Sur un formulaire de création/édition le champs est présent, dans un input hidden
  • Une checkbox est ajoutée sour le menu contextuel permettant d'afficher/masquer la saisie d'un nombre de personne
  • Par défaut si group_nb vaut 1, la checkbox est décochée et la zone de saisie est masquée
  • La validation du formulaire intègre l'état de la checkbox pour mettre à jour la valeur de l'input hidden
  • Si la checkbox est décochée, group_nb vaut 1, sinon il prend la valeur de la zone de saisie

Aussi la fiche d'un usager indique s'il s'agit d'un "compte de groupe" (group_nb > 1) ou non, avec dans le 1er cas l'indication du nombre de personnes par défaut indiqué.

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • % Done changed from 40 to 100

Modifications publiées sur le svn (r463 et r464) :

Utilisation d'un compte de groupe

Un compte usager de type "groupe" est déterminé par sa valeur group_nb. Celle-ci est laissée à 0 pour les usagers normaux, un compte de groupe peut donc avoir à présent une valeur par défaut de 1 personne.

Après inscription sur une session, les comptes de groupes indiquent un nombre de personnes leur correspondant. Fixé par défaut à l'inscription avec la valeur indiquée sur la fiche, il peut ensuite être modifié sur la fiche de la session.

Le nombre d'inscrits d'une session prend en compte le nombre de personnes des groupes éventuellement inscrits.

Modifications de la base de données

ALTER TABLE sf_guard_user_profile CHANGE group_nb group_nb SMALLINT NOT NULL DEFAULT 0;

UPDATE sf_guard_user_profile SET group_nb=0 WHERE group_nb=1;

ALTER TABLE session_user ADD group_nb SMALLINT NOT NULL DEFAULT 1;

Amélioration des messages de retour

  • Sessions complètes :
    Lorsqu'une inscription est créée sur une série de sessions, si ne serait-ce qu'une session est complète alors l'opération est annulée. Le retour d'info indique la liste des sessions pleines (avec titre, date, horaires et nombres d'inscrits).
  • Inscription d'un groupe :
    Lorsqu'un compte de type groupe est inscrit sur une ou plusieurs sessions, le nombre de personne est mis par défaut à la valeur renseignée sur la fiche usager.
    Si une session ne disposait pas d'assez de places disponibles, le nombre de personne est fixé au maximum possible, soit le nombre de places restantes.
    Le retour d'info indique la liste des sessions sur lesquelles le compte a été inscrit avec les nombres de personnes fixés sur chaque (+ une note si la session a été remplie).

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • Status changed from In Progress to Résolu

Modifications publiées sur le svn (r465) :

La modification d'une inscription ne doit plus pouvoir entrainer un dépassement du nombre max d'inscrits :
  • Si l'inscription modifiée représente plusieurs personnes, le nombre est bridé pour ne pas dépasser la limite, à condition qu'il puisse rester au moins 1 personne.
  • Si l'inscription ne représente qu'une personne (ou que la condition précédament citée ne pouvait être satisfaite), alors l'état "Préinscrit" est forcé afin de l'exclure du décompte d'inscrits.

La bulle info en retour informe l'utilisateur dans de telles situations.

Updated by Grégory MARIGOT - TEICEE over 10 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF