Le service ‹identifiant_séance›/xml permet de récupérer les données d'une séance.
Le concept de séance est un des concepts principaux d’HubSessions. Il regroupe les métadonnées d’une séance ainsi que ses états (ou étapes), depuis sa création jusqu’à son archivage. Par conséquent, il n’y a pas réellement, dans HubSessions, de concept d’Ordre du jour ou de Procès-verbal: on parle plutôt d’états (states) d’une séance. Les états d’une séance sont les suivants.
État (state) |
En français |
Terme alternatif |
Description |
created |
En création |
- |
Un gestionnaire de séance (GS) a créé une séance en mode « privé » et est en train d’y travailler. Personne, à part les autres GS et lui-même, ne peut voir cette séance et les points qui sont en train d’y être insérés. |
published |
Publiée |
Ordre du jour provisoire publié |
Un GS a décidé de publier l’ordre du jour de la séance. Il s’agit d’un ordre du jour provisoire, qui peut encore évoluer avant la tenue de la séance : des modifications peuvent être apportées aux points déjà insérés, des points en retard (parfois nommés urgents ou encore en communication) peuvent être ajoutés. |
frozen |
Gelée |
Ordre du jour définitif publié |
Nous sommes quelques minutes, heures ou la veille de la séance et un GS a décidé de geler son ordre du jour : plus rien n’y sera changé avant la tenue de la séance. L’ordre du jour est considéré comme définitif. |
decided |
Décidée |
Procès-verbal provisoire publié |
La séance a eu lieu, et les décisions sur chaque point ont été prises et encodées. Cette étape correspond à la publication du procès-verbal (PV) provisoire de la séance. Il est provisoire : des détails peuvent encore être modifiés ou des coquilles corrigées. |
closed |
Clôturée |
Procès-verbal définitif publié |
La dernière touche a été ajoutée : le PV définitif est publié. |
archived |
Archivée |
- |
Il s’’agit de l’état final d’une séance dans HubSessions. |
Type de requête
Requête HTTP GET
Données en entrée
L'identifiant de la séance est inclus dans l'URL du service, qui n'accepte aucun paramètre.
Exemple de requête
Appeler le service pour une séance dont l'identifiant est 689 se fait via l'URL suivante.
<siteUrl>/689/xml
Données de retour
Une requete HTTP GET sur l’URL d’une séance retourne ses méta-données dans le format suivant. Le résultat peut cependant varier (présence de certains tags ou non) en fonction d'une série de paramètres de configuration.
<Meeting type="object" id="321" iid="321" className="Meeting">
<!-- Main metadata -->
<title>27/03/2023 (06:40)</title>
<creator>admin</creator>
<created type="DateTime">2023/03/08 09:08:38.352583 GMT+1</created>
<modified type="DateTime">2023/03/08 09:08:38.352583 GMT+1</modified>
<state>decided</state>
<committee>namur:4</committee>
<meetingType>166:cp</meetingType>
<meetingTypeName><acronym title="Séance plénière">Plénière</acronym></meetingTypeName>
<date type="DateTime">2023/03/27 06:40:00 GMT+2</date>
<startDate type="DateTime">2023/03/27 06:40:00 GMT+2</startDate>
<endDate type="DateTime">2023/03/27 08:40:00 GMT+2</endDate>
<quorum type="float">50.0</quorum>
<observations/>
<number type="int">1</number>
<firstItemNumber type="int">-1</firstItemNumber>
<!-- History -->
<record type="object" className="History">
<data type="list" count="4">
<e type="object" className="Trigger">
<transition>decide</transition>
<login>admin</login>
<state>decided</state>
<date type="DateTime">2023/04/03 15:24:33.296679 GMT+2</date>
<comment/>
</e>
<e type="object" className="Trigger">
<transition>freeze</transition>
<login>admin</login>
<state>frozen</state>
<date type="DateTime">2023/04/03 15:24:29.947273 GMT+2</date>
<comment/>
</e>
<e type="object" className="Trigger">
<transition>publish</transition>
<login>admin</login>
<state>published</state>
<date type="DateTime">2023/04/03 15:24:26.320642 GMT+2</date>
<comment/>
</e>
<e type="object" className="Trigger">
<transition>_init_</transition>
<login>admin</login>
<state>created</state>
<date type="DateTime">2023/03/08 09:08:38.352583 GMT+1</date>
<comment/>
</e>
</data>
<modified type="DateTime">2023/03/08 09:08:38.352583 GMT+1</modified>
</record>
<!-- Items, in the order of their discussion -->
<items type="list" count="3">
<e><siteUrl>/348/xml</e>
<e><siteUrl>/349/xml</e>
<e><siteUrl>/357/xml</e>
</items>
<!-- The number of late items -->
<lateCount type="int">0</lateCount>
<!-- Participants -->
<participants type="list" count="26">
<e>http://localhost:8000/322/xml</e>
<e>http://localhost:8000/323/xml</e>
...
</participants>
<!-- Meeting-wide annexes -->
<annexes type="list" count="0"/>
</Meeting>
Les attributs id et iid du tag principal Meeting représentent l’identifiant de base de données interne à HubSessions concernant cette séance.
Métadonnées principales
La séance partage une base de métadonnées commune à tout objet Appy : un titre (tag title), un créateur (tag creator), une date de création (tag created), de dernière modification (tag modified) et un état (tag state, un parmi ceux identifiés dans le tableau précédent).
S'il s'agit d'un HubSessions multi-comités, le comité au sein duquel la séance est définie est également présent via le tag committee. Ce tag contient l'identifiant logique du comité. Si celui-ci dispose d'un identifiant externe, le tag contiendra les identifiants logique et externe, séparés par le caractère « : ».
Au sein d’HubSessions, une séance peut disposer d’un type. Un type de séance peut représenter diverses choses, par exemple : le fait que la séance soit en présentiel ou non, ou encore le fait qu’il s’agisse d’une séance plénière ou d’un groupe de travail. Ce type est matérialisé ici par les tags meetingType et meetingTypeName. Le tag meetingType contient l’identifiant numérique du type et un identifiant logique. L’identifiant numérique permet d’accéder à la page XML qui donne plus de détails au sujet du type. L’URL de cette page est construite comme ceci :
<siteURL>/<identifiant_type_séance>/xml
Un jeu de dates est ensuite décrit.
- La date de la séance est la date (et l’heure) telle qu’annoncée lors de la publication de la séance. Ce tag est toujours présent.
- Les tags startDate et endDate donnent, respectivement, la date et l’heure précise de début et de fin de la séance. Il se peut que ces dates soient approximatives tant que la séance n’a pas eu lieu. Il se peut qu'un HubSessions n'ait pas activé ces dates.
- Si la gestion fine des participants est activée, et que la notion de participant ayant un droit de vote est activée également, le tag quorum donne le pourcentage de participants ayant un droit de vote, en-dessous duquel la séance ne peut avoir lieu.
- Le tag observations, au contenu XHTML, peut être encodé par un gestionnaire de séance pour donner des détails sur la séance. Son contenu est informatif et libre et peut servir à diverses usages, à l’appréciation du gestionnaire.
- Les séances sont numérotées dans un HubSessions, bien que ce numéro ne soit pas nécessairement exploité et affiché dans l'interface utilisateur. Le tag number reprend ce numéro, qui est un entier séquentiel. Attention : une séance non encore publiée est numérotée -1. Chaque point de la séance sera également numéroté, via un numéro séquentiel indépendant des séances, global. Ce numéro, pour le premier point de cette séance, sera stocké dans le tag firstItemNumber quand la séance sera clôturée. Avant cette étape, il vaudra -1.
Historique
Le tag record est de format similaire à ceux d’autres objets tels les points ou les dossiers. Ici, la séance est décidée et son historique reprend l’ensemble des étapes qui ont été parcourues (les transitions de workflow) pour en arriver là. Notez que, dans cet historique, on peut y trouver des étapes de retour en arrière. Par exemple, si un gestionnaire de séance a publié le PV définitif trop tôt (transition close), il se peut qu’il change d’avis et fasse revenir la séance dans l’état précédent (decided) via la transition backToDecided.
Points
La liste des points discutés lors de cette séance se trouve dans le tag items, dans l’ordre précis dans lequel les points ont été abordés en séance. Cette liste contient l’URL de chaque point discuté, qui mène à la page XML d’un point tel que décrit par le service ‹identifiant_point›/xml.
<items type="list" count="3">
<e><siteUrl>/348/xml</e>
<e><siteUrl>/349/xml</e>
<e><siteUrl>/357/xml</e>
</items>
Autres tags
Parmi les derniers tags repris, on trouve :
- le tag lateCount, qui compte le nombre de points qui ont été insérés après que l’ordre du jour provisoire ait été publié (transition publish) ;
- le tag participants, qui liste les URLs des participants à cette séance. Ceci, c'est si la gestion fine des participants est activée. Dans le cas contraire, ce tag est absent et remplacé par le tag assembly, qui liste les noms des participants dans un champ de texte brut;
- le tag annexes, qui liste d’éventuelles annexes qui seraient définies au niveau global d’une séance. Chaque URL d'annexe contenue dans cette liste mène à la page XML d’une annexe telle que décrite par le service ‹identifiant_annexe›/xml.