Projects
Projects
Advanced search...
Active
Inactive
HubSessions API ask/itemStatus

Le service ask/itemStatus vous permet de récupérer une information textuelle au sujet du statut du point et de l'éventuelle décision qui aurait été prise sur ce point, lorsque cette information est disponible.

L'information qui est toujours disponible est l'état du point. Les différents états possibles sont listés ci-dessous. D'un HubSessions à l'autre, les termes utilisés peuvent malheureusement varier. Les termes utilisés ci-dessous sont ceux qui sont les plus fréquemment utilisés.

État Explication
En création Il s'agit de l'état initial du point, dans lequel il se trouve dès sa création, qu'elle ait été initiée via l'API ou par un être humain en chair et en os.
Dans cet état, le point n'est visible qu'aux personnes ayant le rôle de créateur au sein du groupe défini comme ayant proposé le point.
Proposé Lorsqu'un créateur propose le point, celui-ci il arrive dans l'état proposé et est soumis pour pré-validation par un prévalidateur, typiquement, un·e chef·fe de service.
Prévalidé Lorsqu'un prévalidateur prévalide le point, celui-ci arrive dans l'état prévalidé et est soumis à validation par un validateur, typiquement un·e chef·fe de département.
Validé Lorsqu'un validateur valide un point, celui-ci "quitte" le groupe proposant et son éventuelle hiérarchie, pour arriver dans les mains des gestionnaires de séances, qui peuvent décider de l'affecter à l'ordre du jour de l'une ou l'autre séance.
Publié Lorsqu'un ordre du jour provisoire est publié, chaque point qui y est inclus passe également dans l'état publié.
Gelé Lorsqu'un order du jour définitif est publié, chaque point qui y est inclus passe dans l'état gelé. Ce "gel" fait référence au fait qu'a priori, vu l'imminence de la réunion, plus aucune modification d'est censée être apportée au point.
Pré-accepté À partir du moment où la séance a lieu, les décisions sont prises sur chaque point. Quelque temps après, ses gestionnaires publieront les décisions provisoires de la séance : la séance passera dans l’état « PV provisoire publié » et chaque point sera affecté à un état de décision. Un point accepté passera dans l’état appelé « (Pré)-accepté ».
Retiré Alternativement, un point peut ne pas être (pré-)accepté mais être retiré. Cela signifie qu’aucune décision ne va être prise sur ce point, mais qu’il va néanmoins rester acté dans la séance, au lieu de disparaître purement et simplement.
Reporté Il s’agit du troisième état de décision sur un point. Un point reporté apparaîtra comme tel dans le procès-verbal. Une copie du point sera établie et sera retournée au groupe proposant. Cette copie pourra parcourir à nouveau le chemin de validation, jusqu’à être inséré dans une séance ultérieure. Dans ce cas, un lien sera établi entre un point reporté, qui sera conservé dans sa séance d’origine, et la copie qui fera partie d’une séance ultérieure.
Accepté Après d’éventuelles modifications mineures, voire orthographiques, le procès-verbal définitif de la séance sera publié et celle-ci passera dans l’état « PV définitif publié ». À ce moment, tous les points pré-acceptés passeront dans l’état accepté.
Refusé L'entité décisionnelle organisant les séances peut décider de refuser un point qui lui a été soumis. Il s’agit du dernier état de décision qui peut s’appliquer à un point.

Notez que tous les états tels que listés ci-dessus peuvent ne pas être d'application sur certains HubSessions. En effet, il existe de nombreuses adaptations de workflow qui, lorsqu'activées sur un HubSessions particulier, peuvent changer les règles et par exemple supprimer l'une ou l'autre étape.

Par exemple, sur certains HubSessions, les points en création sont directement validés.

Autre exemple: les processus de publication de l'ordre du jour et du PV des séances peuvent ne comporter qu'une étape unique, et non deux comme décrit ci-dessus.

  • Dans un processus de publication de l'ordre du jour en une seule étape, les points validés sont directement gelés.
  • Dans un processus de publication du PV d'une séance en une seule étape, les points qui ne sont ni retirés, ni reportés, ni refusés, sont directement acceptés et "sautent" l'étape de pré-acceptation.

Comme d'habitude, veuillez vous adresser à votre référent HubSessions pour connaître les croustillants détails des workflows tels qu'adaptés dans l'HubSessions que vous attaquez.

Au-delà de l'état du point, 2 autres informations peuvent également se retrouver dans l'information de statut telle que retournée par le service ask/itemStatus.

  1. Le texte de la décision officielle prise sur le point. Cette décision peut aussi s'appeler délibération dans certains HubSessions. Ce champ n'est pas toujours rempli: il peut ne pas être applicable pour certains points. Certains HubSessions peuvent introduire, dans ce champ, des informations spécifiques, telles les valeurs de vote, si vote il y a eu sur le point.
  2. Un commentaire sur la décision. Au-delà du texte officiel de la décision, un commentaire moins formel peut accompagner le texte, donnant par exemple un détail sur les raisons pour lesquelles le point a été accepté, refusé ou reporté. Ce champ-ci peut aussi être vide.

Type de requête

Requête HTTP GET

Données en entrée

Les paramètres de la requête sont les suivants:

  • itemId (obligatoire) · L'identifiant du point pour lequel vous souhaitez récupérer les informations de statut. Cet identifiant est, par exemple, présent parmi les données de retour du service create/item.
  • language (optionnel): la langue dans laquelle vous souhaitez récupérer le statut. Notez que seules certaines parties du statut seront traduites dans cette langue; pour d'autres parties, les informations seront retournées dans la langue dans laquelle elles ont été rédigées.

Exemple de requête

<siteUrl>/ask/itemStatus?itemId=56432&language=fr

Données de retour

Bien qu'exprimées en XML, les données de retour ne se conforment pas au format de retour standardisé.  Voici plusieurs exemples.

Lorsque le point vient d'être créé ou est encore dans une des étapes préalables du processus, seul l'état du point peut être inclus, sous cette forme.

<?xml version="1.0" encoding="utf-8" ?>
<itemStatus>&lt;p&gt;Le point distant a le statut « En création ».&lt;/p&gt;</itemStatus>

Le tag itemStatus contient du code XHTML dont les caractères <, > et & sont échappés par les entités XML correspondantes. Si vous n'avez pas encore reconstitué mentalement le champ XHTML non échappé, voici un coup de pouce.

L'exemple suivant montre le statut d'un point pré-accepté pour lequel une décision a été encodée, ainsi qu'un commentaire sur la décision. Il s'agit d'un exemple réel dont les données ont été viciées par un esprit retors dans un but de respect de la confidentialité.

<?xml version="1.0" encoding="UTF-8"?>
<itemStatus>&lt;p&gt;Le point distant a le statut « (Pré-)accepté ».&lt;/p&gt;&lt;p&gt;Vu les articles 66-6° et 333 de la nouvelle loi communale ;&lt;/p&gt;
&lt;p&gt;Vu les lois coordonnées sur le Conseil d’Etat du 1er avril 1975 ;&lt;/p&gt;
&lt;p&gt;Vu la décision du Gouvernement malonnois de généraliser, en l'honneur des 20 ans du format ODF, l'usage de celui-ci dans l'administration;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Considérant que le lobby MAFAG & oC a introduit une requête en suspension et annulation à l'encontre de cette décision;&lt;/p&gt;
&lt;p&gt;Que la commune a l'opportunité en tant que 'demandeur du standard' d'intervenir dans la procédure au Conseil d'Etat en tant que partie intervenante;&lt;/p&gt;
&lt;p&gt;Qu'il y a lieu, au vu des enjeux du dossier, à également défendre la légalité de la décision;&lt;/p&gt;
&lt;p&gt;Que l’autorisation du Conseil communal est requise à cet effet ;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;DECIDE :&lt;/p&gt;
&lt;p&gt;1°) d’introduire une requête en intervention auprès du Conseil d'Etat dans le cadre du recours introduit sur la décision susvisée ;&lt;/p&gt;
&lt;p&gt;2°) de déverser par hélicoptère des tracts incitant la population à vénérer les logiciels libres ;&lt;/p&gt;
&lt;p&gt;3°) de désigner Me MOGLEN pour représenter la Commune et défendre ses intérêts.&lt;/p&gt;&lt;p&gt;Approuvé / Goedgekeurd&lt;p&gt;&lt;/p&gt;&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Bon anniversaire ODF!&lt;/p&gt;&lt;p&gt;Pérennité des données enfin assurée.&lt;/p&gt;&lt;/p&gt;</itemStatus>

Vous constaterez que l'ensemble des informations se retrouve dans le même tag, et donc le même champ de texte XHTML. Dans l'exemple, le commentaire de la décision arrive après la mention Approuvé / Goedgekeurd.