ProxyEPN

Modifications de la base de données pour les ateliers :¶

Les changements concernant les sessions de type atelier, avec la suppression des "modules d'atelier" au profit d'une simple liste de thèmes catégorisés, impliquent d'importantes modifications sur les tables de la BDD :

• La table 'initiations' qui contenait les "modules" est transformée en 'workshop_theme', les modules actuels devenant les futurs thèmes (et leurs thèmes devenant les catégories).

• La table de liens 'session_initiation' est renommée en 'session_workshop', elle reste utilisée pour ajouter des champs extras propres aux sessions de type atelier.

• Il existait un doublon entre le champs extra 'comments' et le champs 'feedback' des sessions. C'est ce dernier qui sera conservé, pouvant être utile pour d'autres types de sessions. La colonne 'comments' est donc supprimée après copie de ses données vers les champs 'feedback' qui étaient vides.

• Les "modules" contenaient un champs 'goals' (objectifs) qui n'a plus lieu d'être dans la nouvelle table gérant simplement des thèmes. Par contre il peut être pertinent en champs extra sur chaque session de type atelier. Cette colonne est donc supprimée après que son contenu ait été copié vers une nouvelle colonne de la table de liens 'session_workshop'.

• Beaucoup d'autres colonnes contenant des infos propres aux "modules d'atelier" sont également supprimées, ainsi que les tables annexes pour les versions, les fichiers et les questions.

• Deux champs sont passés en type 'boolean' (des tinyint en fait sous MySQL, à 0 ou 1). Ils étaient auparavant en varchar (y ou n) et en int (0, 1, 2), leurs valeurs auront été migrées pour correspondre au nouveau type.

• Les index ainsi que les clés étrangères ont été redéfinies proprement pour supprimer les doublons et être cohérents avec la charte de nommage.

Détail des commandes SQL pour effectuer la migration des tables et données :

ALTER TABLE session_initiation DROP FOREIGN KEY session_initiation_FK_1, DROP FOREIGN KEY session_initiation_FK_2;
ALTER TABLE session_initiation DROP FOREIGN KEY session_initiation_ibfk_1, DROP FOREIGN KEY session_initiation_ibfk_2;

UPDATE session,session_initiation SET feedback=comments WHERE session.id=session_id AND feedback='';
ALTER TABLE session_initiation DROP comments;

ALTER TABLE session_initiation ADD goals TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '' AFTER initiation_id;
UPDATE session_initiation,initiations SET goals=in_goals WHERE initiation_id=initiations.id;

UPDATE session_initiation SET subscription_by_user=1 WHERE subscription_by_user='y';
UPDATE session_initiation SET subscription_by_user=0 WHERE subscription_by_user='n';
ALTER TABLE session_initiation CHANGE subscription_by_user subscription_by_user TINYINT(1) NOT NULL DEFAULT '0';

ALTER TABLE session_initiation DROP INDEX idx_id;
ALTER TABLE session_initiation DROP INDEX session_initiation_FI_1;
ALTER TABLE session_initiation DROP INDEX session_initiation_FI_2;

ALTER TABLE session_initiation CHANGE initiation_id workshop_theme_id INT(11) NOT NULL;
ALTER TABLE session_initiation ADD INDEX (workshop_theme_id);

RENAME TABLE session_initiation TO session_workshop;

ALTER TABLE initiations DROP in_goals, DROP in_course, DROP in_evaluation, DROP in_language, DROP in_share, DROP in_necessary, DROP in_prolongation, DROP in_duration, DROP in_nb_part, DROP in_id_share, DROP in_last_id_share;
ALTER TABLE initiations CHANGE in_id id INT(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE initiations CHANGE in_label label VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
ALTER TABLE initiations CHANGE in_comment description TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL;
ALTER TABLE initiations CHANGE in_status active TINYINT(1) NOT NULL DEFAULT '1';
ALTER TABLE initiations CHANGE in_it_id category INT(11) NOT NULL;

UPDATE initiations SET active=1 WHERE active=0;
UPDATE initiations SET active=0 WHERE active=2;
RENAME TABLE initiations TO workshop_theme;

ALTER TABLE session_workshop ADD CONSTRAINT session_workshop_FK_1 FOREIGN KEY (session_id) REFERENCES session (id) ON DELETE CASCADE;
ALTER TABLE session_workshop ADD CONSTRAINT session_workshop_FK_2 FOREIGN KEY (workshop_theme_id) REFERENCES workshop_theme (id) ON DELETE CASCADE;

DROP TABLE initiations_questions;
DROP TABLE initiations_versions;
DROP TABLE initiations_files;

Modifications publiées sur le svn (r353) :

Mise en place du module permettant l'administration des thèmes d'atelier.¶

Les thèmes sont la version très allegée de ce qu'étaient auparavant les modules d'atelier. A présent, ils définissent uniquement un titre, une description et un état actif/inactif, en étant classés par catégories.
La liste des catégories provient toujours des listes administrables, par contre elle a été renommée de initiations_themes en workshop_theme.

Modifications publiées sur le svn (r355) :

Mise en place du nouveau système de sessions¶

Les 4 types principaux¶

A présent, les différents types de sessions sont regroupés en 4 types principaux :

• free : pour les accès libres autonomes (1) et accompagnés (2)
• training : pour les téléformations (3)
• workshop : pour les ateliers (4)
• events : pour les évenements locaux (5), réseaux (6) ou mise à disposition (7)

L'intéret de ces regroupements est la similarité des sessions les constituants, autant dans leurs propriétés, leurs logiques, que leurs utilisations.

Le premier impact concerne les formulaires de création / édition des sessions, qui sont désormais générés pour l'un des 4 types principaux, sans changement de l'un à l'autre à la volée. Ceci impliquait beaucoup de lourdeur et de complexité pour adapter la forme et les champs du formulaire vu les différences parfois fondamentales.

Ce nouveau principe, s'il permet des formulaires plus simples et plus fiables, impose les contraintes suivantes :

• Une session existante ne peut plus changé de type principal : ayant peu de sens celà a été jugé inutile (par contre il est toujours possible de changer par exemple un accès libre autonome en accompagné, ou un évenement local en évenement réseau).
• La création d'une nouvelle session doit être initiée en indiquant son type principal avant de pouvoir accéder au formulaire adéquat. Celà est rendu possible soit par une première page de sélection entre les 4 types, ou directement par la présence de 4 liens de créations.

Nouvelle définition des accès libres¶

Auparavant les sessions libres représentaient les plages d'ouvertures d'une salle pour accueillir des accès libres. Ces sessions devaient donc être toutes créées au préalable pour ensuite y effectuer les enregistrements des éventuels usagers.
Ce système pouvait être pénible à l'usage, les accès libres étant souvent ouverts autant que peut l'être un EPN, celà représentait beaucoup de sessions à définir... L'usage d'un système de récurrence n'est pas une solution ultime, la définition d'une récurrence étant complexe tant au niveau du code que pour l'ergonomie des formulaires.

A présent le changement est radical : les sessions libres enregistrées correspondent simplement à l'utilisation d'un poste par un usager sur une tranche horaire. Donc pour chaque usagers en accès libre correspond une session à part, par contre il n'y a plus de définition de session potentiellement vide à créer systématiquement en amont.

Cette réorganisation offre plusieurs avantages, en particulier au niveau du code où les données des sessions ont pu être mieux uniformisérs entre les différents types, ce qui facilitera les fonctionnalités à suivre (comptages des utilisateurs, statistiques, occupation des postes, historique et parcours des usagers).

idées à suivre...¶

Pour autant, avec cette multitude de sessions libres individuelles, il n'est pas exclu de pouvoir les regrouper artificiellement à l'affichage dans l'interface (selon la date et la salle). Ceci permettrait de proposer des présentations plus compactes et plus pratiques (fiche globale listant les accès individuels, bloc commun dans une vue de calendrier global).

Une autre idée consiste à ce que chaque EPN puisse définir ses "préférences" sur les accès libres, de manière générale : horaires pour chaque salles sur une semaine normale. Ces informations pourront avoir un double intérêt : d'une part présenter aux usagers les plages d'accès, d'autre part être utilisées en valeurs par défaut sur les formulaires de création.

La notion de groupe est également envisagée : certaines fiches d'usager ne sont pas personnelles mais correspondent à un groupe de personne, dont l'identité de chacun importe peu et qu'il serait donc fastidieux de définir individuellement (ex: la classe CM2 de telle école).
C'est fiches particulières devront être référencées comme telles (case à cocher sur la fiche) afin d'être correctement interprétées dans le comptage des utilisateurs sur une session.
Pour un accès libre, préciser qu'il s'agit d'un groupe pourra restreindre le choix de l'usager à ces seules fiches, rendre la sélection d'ordinateurs multiple, et faire apparaitre un champs de saisie afin d'indiquer le nombre de personnes présentes.

De plus, il est toujours envisagé de pouvoir alimenter semi-automatiquement la liste des sessions via une API web. Ainsi un outils tiers effectuant une analyse de logs pourra remonter les informations de connexion des usagers, l'animateur n'ayant plus qu'à rectifier/compléter/valider la création de la session correspondante.

Modifications de la base de données¶

Les changements décrits précédements, ajoutés à quelques renommages de champs, adaptations de types et autres contraintes de clés étrangères, amènent à d'importants changements de la BdD.

Les opérations SQL suivantes permettent une migration des tables depuis la version EpnAdmin-CTN, autant sur les structures que sur les données :

UPDATE session_initiation SET subscription_by_user=1 WHERE subscription_by_user='y';
UPDATE session_initiation SET subscription_by_user=0 WHERE subscription_by_user='n';
ALTER TABLE session_initiation CHANGE subscription_by_user registration TINYINT(1) NOT NULL DEFAULT '0';

ALTER TABLE session_initiation ADD goals TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '' AFTER initiation_id;
ALTER TABLE session_initiation ADD people_max SMALLINT NOT NULL DEFAULT '1' AFTER goals;

UPDATE session_initiation,initiations SET goals=in_goals WHERE initiation_id=in_id;
UPDATE session_initiation, session SET people_max=nbr_of_people WHERE session_id=session.id;

UPDATE session,session_initiation SET feedback=comments WHERE session.id=session_id AND feedback='';
ALTER TABLE session_initiation DROP comments;
ALTER TABLE session_initiation DROP status;

RENAME TABLE session_initiation TO session_workshop;
ALTER TABLE session_workshop CHANGE initiation_id theme_id INT NULL;

ALTER TABLE session_workshop DROP INDEX idx_id;
ALTER TABLE session_workshop DROP INDEX session_initiation_FI_1;
ALTER TABLE session_workshop DROP INDEX session_initiation_FI_2;

ALTER TABLE session_workshop ADD PRIMARY KEY (session_id);
ALTER TABLE session_workshop ADD INDEX (theme_id);

ALTER TABLE initiations DROP in_goals, DROP in_course, DROP in_evaluation, DROP in_language, DROP in_share,
DROP in_necessary, DROP in_prolongation, DROP in_duration, DROP in_nb_part, DROP in_id_share, DROP in_last_id_share;
ALTER TABLE initiations CHANGE in_id id INT(11) NOT NULL AUTO_INCREMENT;
ALTER TABLE initiations CHANGE in_label label VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
ALTER TABLE initiations CHANGE in_comment description TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL;
ALTER TABLE initiations CHANGE in_status active TINYINT(1) NOT NULL DEFAULT '1';
ALTER TABLE initiations CHANGE in_it_id category INT(11) NOT NULL;

UPDATE initiations SET active=1 WHERE active=0;
UPDATE initiations SET active=0 WHERE active=2;

DROP TABLE initiations_questions;
DROP TABLE initiations_versions;
DROP TABLE initiations_files;
RENAME TABLE initiations TO workshop_theme;
ALTER TABLE workshop_theme ADD INDEX (category);

CREATE TABLE `workshop_resource` (
 `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
 `theme_id` INT NOT NULL,
 `legend` VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
 `description` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL,
 `filepath` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
 `filesize` INT NOT NULL,
 `filetype` VARCHAR(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
 `language` VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
 `tags` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
 `status` TINYINT NOT NULL DEFAULT '1',
 `created_at` DATETIME NULL DEFAULT NULL,
 `created_by` INT NULL DEFAULT NULL,
 `updated_at` DATETIME NULL DEFAULT NULL,
 `updated_by` INT NULL DEFAULT NULL
) ENGINE=InnoDB CHARACTER SET utf8 COLLATE utf8_unicode_ci;

ALTER TABLE workshop_resource ADD INDEX theme_id (theme_id);
ALTER TABLE workshop_resource ADD INDEX tags (tags);
ALTER TABLE workshop_resource ADD FOREIGN KEY (theme_id) REFERENCES workshop_theme (id);

CREATE TABLE `workshop_bookmark` (
 `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
 `theme_id` INT NOT NULL,
 `legend` VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
 `description` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL,
 `url` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
 `type` VARCHAR(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
 `language` VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
 `tags` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
 `status` TINYINT NOT NULL DEFAULT '1',
 `created_at` DATETIME NULL DEFAULT NULL,
 `created_by` INT NULL DEFAULT NULL,
 `updated_at` DATETIME NULL DEFAULT NULL,
 `updated_by` INT NULL DEFAULT NULL
) ENGINE=InnoDB CHARACTER SET utf8 COLLATE utf8_unicode_ci;

ALTER TABLE workshop_bookmark ADD INDEX theme_id (theme_id);
ALTER TABLE workshop_bookmark ADD INDEX tags (tags);
ALTER TABLE workshop_bookmark ADD FOREIGN KEY (theme_id) REFERENCES workshop_theme (id);

RENAME TABLE session_remote_training TO session_training;
ALTER TABLE session_training DROP INDEX idx_id;
ALTER TABLE session_training DROP INDEX session_remote_training_FI_1;
ALTER TABLE session_training DROP INDEX session_remote_training_FI_2;

ALTER TABLE session_training CHANGE user_id user_id INT NULL DEFAULT NULL;
ALTER TABLE session_training ADD PRIMARY KEY (session_id);
ALTER TABLE session_training ADD INDEX (user_id);

UPDATE session_training SET training_status='1' WHERE training_status='y';
UPDATE session_training SET training_status='0' WHERE training_status='n';
ALTER TABLE session_training CHANGE training_status completed TINYINT(1) NOT NULL DEFAULT '0';
ALTER TABLE session_training CHANGE training_company_id company_id INT NOT NULL;

ALTER TABLE session_computer CHANGE computer_id computer_id INT NULL;

RENAME TABLE users_courses TO session_user;
ALTER TABLE session_user CHANGE uc_status status VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'required';
ALTER TABLE session_user CHANGE uc_id_session session_id INT NOT NULL;
ALTER TABLE session_user ADD user_id INT NULL AFTER session_id;
UPDATE session_user SET user_id=uc_id_user;
ALTER TABLE session_user DROP uc_id_user;
ALTER TABLE session_user DROP uc_id_initiation;

ALTER TABLE session_user DROP INDEX users_courses_FI_1;
ALTER TABLE session_user DROP INDEX users_courses_FI_2;
ALTER TABLE session_user ADD INDEX session_id (session_id);
ALTER TABLE session_user ADD INDEX user_id (user_id);

RENAME TABLE session TO session_old;

CREATE TABLE session (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `type_id` SMALLINT NOT NULL,
  `name` VARCHAR(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  `description` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL,
  `room_id`    INT NOT NULL,
  `date`       DATE NOT NULL,
  `time_from`  TIME NOT NULL,
  `time_until` TIME NOT NULL,
  `people_nb` SMALLINT NULL DEFAULT '1',
  `instructor_id` INT NULL DEFAULT NULL,
  `supervisor` VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `network_name` VARCHAR(200) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `show_in_feeds` TINYINT NOT NULL DEFAULT '0',
  `feedback` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL,
  `chain_key` INT NULL DEFAULT NULL,
  `created_at` DATETIME NULL DEFAULT NULL,
  `created_by` INT NULL DEFAULT NULL,
  `updated_at` DATETIME NULL DEFAULT NULL,
  `updated_by` INT NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB CHARACTER SET utf8 COLLATE=utf8_unicode_ci;

ALTER TABLE session ADD INDEX room_id (room_id);
ALTER TABLE session ADD INDEX instructor_id (instructor_id);
ALTER TABLE session ADD INDEX chain_key (chain_key);

UPDATE session_old SET nbr_of_people=se_count WHERE type_id=3;
UPDATE session_old SET parent_id=id WHERE parent_id IS NULL AND recurrency=1;

INSERT INTO session (id, chain_key, type_id, name, description, room_id,
`date`, time_from, time_until, people_nb, instructor_id, supervisor, network_name,
show_in_feeds, feedback, created_at, created_by, updated_at, updated_by)
(SELECT id, parent_id, type_id, name, description, room_id, `date`, time_from, time_until,
nbr_of_people, facilitator_id, supervisor, network_name, show_in_feeds,
feedback, created_at, created_by, updated_at, updated_by
FROM session_old WHERE type_id>2);

INSERT IGNORE INTO session (id, chain_key, type_id, name, description, room_id,
`date`, time_from, time_until, people_nb, instructor_id, supervisor, network_name,
show_in_feeds, feedback, created_at, created_by, updated_at, updated_by)
(SELECT id, parent_id, type_id, name, description, room_id, `date`, time_from, time_until,
nbr_of_people, facilitator_id, supervisor, network_name, show_in_feeds,
feedback, created_at, created_by, updated_at, updated_by
FROM session_user INNER JOIN session_old ON session_id=session_old.id
WHERE type_id<3);

INSERT INTO session (type_id, name, description, room_id, `date`, time_from, time_until,
instructor_id, supervisor, network_name, show_in_feeds, feedback, created_at, created_by, updated_at, updated_by)
(SELECT type_id, name, description, room_id, `date`, us_begin, us_end, facilitator_id, supervisor,
 us_id_user, show_in_feeds, us_id_equipment, created_at, created_by, updated_at, updated_by
 FROM uses INNER JOIN session_old ON us_id_session=session_old.id);

DELETE session_computer FROM session_computer LEFT JOIN session
ON session_id=session.id WHERE session.id IS NULL;

INSERT INTO session_computer (session_id, computer_id)
(SELECT id, feedback FROM session WHERE type_id<=2);

INSERT INTO session_user (session_id, user_id, status)
(SELECT id, network_name, type_id FROM session WHERE type_id<=2);

UPDATE session SET feedback='', network_name='' WHERE type_id<=2;

UPDATE session_user SET status='autonome' WHERE status='1';
UPDATE session_user SET status='accompagné' WHERE status='2';

INSERT INTO session_user (user_id, session_id, status)
(SELECT user_id, session_id, 'formation' FROM session_training);
ALTER TABLE session_training DROP user_id;

-- substitution des animateurs supprimés par des animateurs existants
UPDATE session SET instructor_id=28 WHERE instructor_id=12;
UPDATE session SET instructor_id=28 WHERE instructor_id=20;
UPDATE session SET instructor_id=35 WHERE instructor_id=19;
UPDATE session SET instructor_id=26 WHERE instructor_id=18;
UPDATE session SET instructor_id=620 WHERE instructor_id=364;

ALTER TABLE session ADD FOREIGN KEY (room_id) REFERENCES room (id);
ALTER TABLE session ADD FOREIGN KEY (instructor_id) REFERENCES sf_guard_user (id) ON DELETE SET NULL;

ALTER TABLE session_workshop ADD FOREIGN KEY (session_id) REFERENCES session (id) ON DELETE CASCADE;
ALTER TABLE session_workshop ADD FOREIGN KEY (theme_id) REFERENCES workshop_theme (id) ON DELETE SET NULL;

ALTER TABLE session_training ADD FOREIGN KEY (session_id) REFERENCES session (id) ON DELETE CASCADE;

ALTER TABLE session_computer ADD FOREIGN KEY (session_id) REFERENCES session (id) ON DELETE CASCADE;
ALTER TABLE session_computer ADD FOREIGN KEY (computer_id) REFERENCES equipment_computer (id) ON DELETE SET NULL;

ALTER TABLE session_user ADD FOREIGN KEY (session_id) REFERENCES session (id) ON DELETE CASCADE;
ALTER TABLE session_user ADD FOREIGN KEY (user_id) REFERENCES sf_guard_user (id) ON DELETE SET NULL;

DROP TABLE uses;
DROP TABLE session_old;

UPDATE session SET type_id = type_id + 1 WHERE type_id > 2;
UPDATE session SET type_id = 3 WHERE type_id = 8;

TODO¶

Pour le moment, le code gère les fonctionnalités de base : liste / ajout / édition / suppression.
Les formulaires sont adaptés aux différents types de sessions. la sélection de la salle recharge la liste des animateurs et des ordinateurs. Les fiches présententent l'ensemble des informations de manière encore un peu brute et exhaustive.

Pour compléter cette première version, il est nécessaire :

• d'affiner la présentation des fiches
• de filtrer la liste des sessions pour les utilisateurs normaux (visitor/user)
• de gérer les inscriptions d'usagers et changements d'état aux ateliers
• de rendre utilisable la notion de sessions liées (via l'attribut chain_key)
• de remettre en place un calendrier avec vues par semaines

Gestion des inscriptions aux sessions¶

Modifications publiées sur le svn (r356) :

Ajout des actions pour inscrire / modifier / retirer un usager d'une session.
Seules sont concernées les sessions de type Atelier où les inscriptions sont multiples.
La fiche de la session présente la liste des inscrits, un lien pour les retirer ainsi qu'un formulaire pour en ajouter. Le nombre d'inscrits de la fiche est maintenu à jour, le nombre max de participants est controllé.

TODO: Il n'y a pas pour le moment de prise en compte du 'status' d'une inscription

Une purge de plusieurs méthodes obsolètes a également été effectuée.

Liste des sessions en vue calendrier¶

Modifications publiées sur le svn (r357) :

Le calendrier javascript fait son retour pour afficher le planning des sessions.
Le mode de vue peut être hebdomadaire (sur 7 ou 5 jours) ou journalier. Les types de filtres utilisés pour la liste sont disponibles (structure, salle, type, mois) et s'appliquent pour recharger la liste des évenèments à afficher (via AJAX). Des évènements partageant une tranche horaires seront affichés cote-à-cote plutot que superposés.

Le plugin jQuery vient à l'origine du projet 'WeeklyCalendar' :
http://www.redredred.com.au/new-jquery-weekly-calendar-plugin/
Mais ce dernier semble mal supporter les dernières versions de jQuery, et d'ailleurs son auteur conseil de se reporter sur un fork actif du projet :
https://github.com/themouette/jquery-week-calendar
La version utilisée ici est un nouveau fork personnel du précédent, afin d'apporter quelques modifications/correction selon les besoins :
https://github.com/proxyconcept/jquery-week-calendar

Améliorations des fiches et formulaires des sessions¶

Modifications publiées sur le svn (r358) :

Diverses rectifications, meilleur présentation des fiches selon leur type, amélioration de certains formulaires pour faciliter leur saisie...

Le menu contextuel propose les 4 liens de création de sessions sur les pages de liste mais aussi de création. Une entrée vers le calendrier est ajoutée au menu principal. Au passage le menu d'accessibilité est masqué avec la CSS par défaut.

Les formulaires d'éditions indiquent désormais la durée de la session en minutes, valeur mise à jour automatiquement en manipulant les sélecteurs d'horaires. De plus, un widget jQuery-UI de type slider est ajouté pour sélectionner directement une durée (de 15mn à 120mn par pas de 15mn), permettant de positionner automatiquement l'heure de fin d'après l'heure de début.

Concernant les téléformations, davantage d'informations sont disponibles sur la fiche (concernant le thème : catégorie et description). Sur le formulaire, le sélecteur de thème dispose désormais des catégories pour les regrouper.

La génération automatique des noms des sessions a changé :

• Pour les accès libre, le nom de base est "Accès libre". Avant chaque enregistrement d'une fiche, le nom de l'usager est concaténé à la suite. La méthode getName() est réécrite pour supprimer automatiquement ce nom, tandis qu'une méthode getFullName() permet d'obtenir la version intégrale.
• Pour les téléformations, le principe est le même sauf qu'il n'y a pas de nom de base, le champs "name" devenant éditable dans le formulaire. Le nom de l'usager sera toujours absent dans le champs texte, et bien entendu il sera ajouté/modifié à chaque enregistrement.
• Les autres types de sessions ne sont pas impactés, le nom restant tel qu'il doit être défini dans le formulaire.

Filtrage bas-niveau des sessions personnelles¶

Modifications publiées sur le svn (r360) :

Lorsqu'un utilisateur de ProxyEPN ne dispose pas d'un rôle particulier (simple usager ou visiteur anonyme), si l'accès à la liste des sessions est souhaitable, pour autant il ne doit voir que les sessions "publiques". Les sessions personnelles (accès libres et téléformations) doivent absolument être filtrées des résultats et rendu non accessible. Exception faite cependant pour un utilisateur authentifié sur ses propres sessions personnelles.

Pour celà l'objet Context dispose désormais en propriétés supplémentaires du rôle et de l'id de l'utilisateur. Ces données peuvent ainsi être utilisée dans la génération des critères de recherche de sessions pour les restreindre.

En appliquant ces conditions à ce niveau, elles deviennent systématiques et assurent la fiabilité des résultats quelque soit l'usage qui est en fait (liste future, passée, calendrier, homepage, flux, etc). A ce titre, une condition du type "exclude_teleformation" précédemment utilisée n'a plus lieu d'être.

Clonage et sessions liées¶

Modifications publiées sur le svn (r363) :

Pour finaliser les fonctionnalités de base des sessions, il fallait traiter le cas des sessions liées (utilisées typiquement pour des séries de téléformations ou d'ateliers). Il n'est pas question de récurence, principe généralement lourd et pas spécialement adapté à la situation.

Le chainage de sessions¶

Un identifiant (le chain_key) est utilisé comme lien commun à plusieurs sessions. A noter qu'il n'y a pas non plus de notion de session "mère" : le chain_key est un identifiant quelconque (et non un id de session) commun à toute les sessions d'une même série.

A la création/édition de sessions de type formation ou atelier, le chainage peut être établi. Un sélecteur propose la liste des autres sessions du même type, celles faisant déjà parti d'un chainage étant présentées en premier et regroupées en un choix unique (les dates sont indiquées pour chaque choix, avec dans le cas d'une série la première et la dernière date).

Quand un chainage est défini, il apparait sur les fiches de chacune des sessions concernées : la liste complète des sessions liées est affichée par ordre chronologique.

Le clonage de session¶

Le clonage est une fonctionnalité pratique pour créer une nouvelle session à partir d'une session existante. Ainsi un nouveau lien de création est disponible sur chaque fiche de session pour la "cloner". Le formulaire de création est alors déjà préinitialisé avec toutes les infos semblables à la session d'origine (y compris les tables annexes), mais c'est bien une nouvelle session indépendante qui sera créée.

Une exception est faite pour la date et les horaires : ils ne sont pas hérités de la session d'origine mais laissé par défaut à la date actuelle, comme pour une nouvelle session classique.

Cette fonctionnalité est applicable à toute session, quelque soit sont type. Néanmoins elle se trouve particulièrement adaptée aux sessions utilisant le chainage : une session clone propose par défaut d'établir le chainage avec sa session d'origine.

Chainage et inscriptions (cf #19)¶

Pour les sessions utilisant les inscriptions d'usagers (ie les ateliers), si la session fait parti d'une série, alors est offerte la possibilité d'inscrire un usager également sur toutes les autres sessions liées (ou seulement sur celles qui suivent).

Note : à voir s'il est pertinent de laisser les deux choix (toutes / suivantes) ou si le formulaire gagnerait en simplicité avec uniquement l'option la plus utile.

Si l'inscription demandée est multiple, les tests sont effectués au préalable pour savoir si elle est possible sur toutes les sessions concernées. Si ce n'est pas le cas (l'une des sessions serait complète !) alors aucune inscription n'est effectuée.

TODO: Chainage et autres opérations (cf #11)¶

Si le chainage est pris en compte sur les inscriptions, on peut attendre qu'il le soit aussi sur les désinscriptions (pouvoir retirer un usager de toutes les sessions liées d'un atelier).

Les autres cas sont plus complexes et concernent l'édition d'une session faisant partie d'une série. Actuellement la modification d'un champs ne concerne que la session éditée. Parfois on pourrait souhaiter que la modification affecte toutes les sessions liées... mais ce n'est pas toujours le cas !

Un cas particulier serait celui de l'usager attaché à une téléformation : s'il est modifié sur une session il parait dans ce cas logique de reporter le changement sur toute la série.

A défaut de pouvoir ainsi identifier un besoin clair, pour lequel la mise à jour sur toutes les fiches parait évident et sûr (applicable systématiquement), la modification d'un champs pour toute la série n'est pas simple à proposer.

Modifications publiées sur le svn (r423, r428) :

Gestion de l'état des inscriptions (ateliers)¶

Liste des états¶

Les inscriptions d'un usager sur une session contient une info d'état. Celle-ci est simplifiée à la liste suivante : Préinscrit / Inscrit / Absent / Désinscrire.

Les noms des états sont constitués d'une lettre, c'est cette valeur qui est mémorisée dans la BdD. La classe statique SessionUserPeer possède des constantes pour y accéder :

• SessionUserPeer::REQUEST = 'R' (Préinscrit)
• SessionUserPeer::PRESENT = 'P' (Inscrit)
• SessionUserPeer::ABSENT = 'A' (Absent)
• SessionUserPeer::DELETE = 'D' (Désinscrire)

De plus pour les présenter dans l'interface, la liste définie dans le fichier 'data/lists/register_status.ini' offre une correspondance entre les lettres et un libellé.

A noter que l'état 'D' est particulier puisqu'il ne doit jamais être trouvé dans la BdD : quand on choisit de passer une inscription sur l'état "Désinscrire", elle est tout simplement supprimée.

Etat initial¶

A l'inscription d'un usager par un animateur, l'état est directement mis à "P: Inscrit".
Cet état vaut à la fois pour signifier inscrit/présent/effectué, donc nul besoin de le metter à jour en général.

Si les inscriptions sont permises directement par les usagers (évolution à venir), l'état initial devra alors être "R: Préinscrit". Ceci nécessite alors une validation de la part d'un animateur pour confirmer la demande de l'usager et passer son inscription en "Inscrit".

A noter que les "préinscrits" ne sont pas comptabilisés dans le nombre de personnes inscrites.

Pour les autres types de sessions qui n'ont pas utilité de cet état, il est simplement initialisé par le nom du type (free, training...) mais sans que cette donnée n'ait à être exploitée.

Modification de l'état¶

La fiche d'une session présente la liste des utilisateurs inscrits avec l'état. Si l'utilisateur dispose des droits suffisant, alors l'état se trouve dans un sélecteur permettant de le changer et de valider.

Les états ne sont modifiables que un par un, la validation entraine un rechargement de la fiche. Le compteur du nombre d'inscrit est automatiquement mis à jour en tenant compte des états (exclusion des préinscrits) dès qu'une inscription est enregistrée/supprimée.

Migration de la base de données¶

La liste des états ayant changée et s'étant réduite, les opérations suivantes sont à effectuer :

DELETE FROM session_user WHERE status = 'désinscrire';
UPDATE session_user SET status = 'P' WHERE status = 'inscrit(e)';
UPDATE session_user SET status = 'P' WHERE status = 'effectué';
UPDATE session_user SET status = 'P' WHERE status = 'problème (exclu(e))';
UPDATE session_user SET status = 'A' WHERE status = 'absent(e)';
UPDATE session_user SET status = 'A' WHERE status = 'en retard - refusé(e)';
UPDATE session_user SET status = 'free' WHERE status = 'autonome';
UPDATE session_user SET status = 'free' WHERE status = 'accompagné';
UPDATE session_user SET status = 'training' WHERE status = 'formation';
UPDATE session_user SET status = 'P' WHERE status = 'required';

Une fois cela fait, le champs people_nb des sessions de type atelier mériterait d'être recalculé en fonction des inscriptions effectives dans la BdD :

UPDATE session SET people_nb=(SELECT count(user_id) FROM session_user WHERE session_id=id AND status!='R') WHERE type_id=4;

UPDATE session, session_workshop SET people_max = people_nb WHERE type_id=4 AND session_id=id AND people_nb>people_max;