ProxyEPN

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

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.

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

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

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.