Release 1.3.2

🇬🇧

Features

• Stamp authorizations: specific authorizations have been created for the DG75-L120 unit in order to protect uncontrolled updates on the Household Shared Bank of questions.

Fixes

• Catching a rare bug: a rare bug keeps being elusive, when every computed variable of a questionnaire vanish. In order to avoid saving a questionnaire tainted by this bug, an alert will be displayed. It will also helps the user to signal to the Pogues team and to gather information of the current context, which will hopefully helps to define and correct this bug.

Tech

• A new version of the API: the main implication here is that authentication is now needed when using the API (programmatically or through the Swagger UI). Note: the Swagger UI URL is now <host>/swagger-ui/index.html

🇫🇷

Fonctionnalités

• Habilitations sur un timbre : pour limiter les possibles modifications sur les questionnaires du TCM, des habilitations sont mises en places limitant les modifications sur le timbre DG75-L120 (DRTI).

Correctifs

• Attraper un bug rare : un bug rare nous échappe ; il fait disparaître les variables calculées d'un questionnaire. Pour éviter cette situation, nous avons mis en place un avertissement sur votre questionnaire s'il devait être atteint par ce bug. Il permettra également à l'équipe Pogues d'être averti et de disposer d'informations de contexte permettant de reproduire et de corriger le problème.

Tech

• Nouvelle version de l'API : le changement à retenir est l'obligation de s'authentifier pour utiliser l'API (programmatiquement ou via l'interface graphique de Swagger). À noter : la page de cette interface est désormais <host>/swagger-ui/index.html

Release 1.3.1

Hot fix :

🇬🇧
Version 1.3.0 introduced the VTL editor for the input of formulas et labels with suggestions when the chosen language of specifications is VTL. This version introduced also a simplification for the "historical" input fields when the chosen language of specification is XPath, and therefore the loss of certain functinalities : button to add a tooltip and to format the text.
Version 1.3.1 implements the old input fields with associated buttons (of version 1.2.0) when the chosen specification language is XPath.

🇫🇷
La version 1.3.0 introduit l'éditeur VTL pour la saisie des champs de formules et de libellés avec suggestions lorsqu'on choisit le langage de spécifications VTL. Cette version impliquait également une simplification des champs de saisies "historiques" lorsque le langage de spécifications est le XPath et la perte des boutons de saisies d'info-bulles et de mise en forme.
La version 1.3.1 rétablit les champs de saisie de la version 1.2.0 lorsque le langage Xpath est choisi.

Release 1.3.0

🇬🇧

Features

• Mandatory choices during questionnaire creation #520
  • data collection mode selection
  • language choice
  • flow logic choice

Fixes

• Some information was lost during merging #589
• We couldn't validate a question after adding two or more declarations at once #564
• The questionnaire ID appeared as a filter target #586

Tech

• Broken unit tests are fixed #571
• Pogues back-end is now using Spring boot InseeFr/Pogues-Back-Office#126

🇫🇷

Fonctionnalités

• Des choix obligatoires lors de la création d'un questionnaire #520
  • le choix des modes de collecte
  • le choix du langage
  • le choix du dynamisme

Correctifs

• Des informations étaient perdues lors de la fusion de questionnaire #589
• On ne pouvait valider de question après avoir ajouté deux déclarations ou plus d'un coup #564
• L'identifiant du questionnaire apparaissait dans les cibles de filtre #586

Tech

• Réparation de tests unitaires cassés #571
• Utilisation de Spring boot pour le serveur InseeFr/Pogues-Back-Office#126

Release 1.2.0

🇬🇧

Features

• Code card support: the instructions fields now implement the code card option. At the moment, it is a simple tagging that marks an instruction as only available in face-to-face and telephone modes, in a near future, a special display will be used in Queen.
  #569
• Home page: no more need to select your unit in the drop down list, it is now done automatically (using the unit linked to your account). By the way, the unit stamp list is now ordered 😄
  #505 / #521
• Visualise: after you clicked on the "Visualise" button, a spinner will appear when waiting for the generated questionnaire.
  #526

Tech

• Spring boot: the Pogues back-end now uses Spring boot as its core framework.
  #126

---

🇫🇷

Fonctionnalités

• Support de la carte code: les champs de déclarations supportent désormais l'option "carte code". C'est pour le moment un simple marqueur permettant de dire que cette instruction n'est disponible que pour le mode enquêteur (face-à-face ou téléphone), prochainement un visuel particulier sera utilisé dans l'application Queen.
  #569
• Page d'accueil: il n'est plus nécessaire de sélection le timbre de votre unité à la connexion, c'est fait automatiquement (à partir du timbre lié à votre compte). Par ailleurs, la liste des timbres est maintenant triée. 😄
  #505 / #521
• Visualiser: après avoir cliqué sur "Visualiser", un "spinner" apparaît, indiquant que la génération est bien lancée.
  #526

Tech

• Spring boot: la partie "serveur" de Pogues s'appuie désormais pleinement sur le framework Spring boot.
  #126

Release 1.1.0

🇬🇧

Features

• Measurement unit list upgrade: now supporting
  • Watt (W)
  • Kilowatt (kW)
  • Megawatt (MW)
  • Megawatt PCS (MW PCS)
  • Kilowatt thermique (kWth)
  • Tonnes
  • Tonnes matières sèches
  • Degrés celsius
  • Bars
  • Litres
    Issue #504

Fixes

• Input: Fixing a bug making the validation of a question impossible when the user wants to collect dates in a table Issue #537
• Merge: Fixing bug where merging two duplicated questionnaires doesn't work if sequences are from a copy of a questionnaire Issue #533
• Merge: Fixing bug where merging two questionnaires delete the owner part of the resulting questionnaire Issue #523

Techs

• Dependencies upgrade
• Feature flags: currently used for masking the referential code lists UI Issue #507

🇫🇷

Fonctionnalités

• Mise à jour de la liste des unités de mesure: elle contient désormais
  • Watt (W)
  • Kilowatt (kW)
  • Megawatt (MW)
  • Megawatt PCS (MW PCS)
  • Kilowatt thermique (kWth)
  • Tonnes
  • Tonnes matières sèches
  • Degrés celsius
  • Bars
  • Litres
    Issue #504

Corrections

• Champs: Validation impossible si l'on collecte des dates dans un tableau Issue #537
• Fusion: Impossible de fusionner si des séquences sont issues d'une copie de questionnaire Issue #533
• Fusion: La fusion détruit le timbre propriétaire du questionnaire Issue #523

Éléments techniques

• Mise à jour des dépendances
• Feature flags: utilisés dès à présent pour masquer la recherche de listes de codes référentielles. Issue #507

Release 1.0.0

CI refactoring : new action to create release

Release Candidate 1

First release candiate for Pogues UI

Improving Pogues 2016 - Final release

Content of this release:

• rich text edition for question labels and statements;
• multiple labels with conditions for questions;
• define statement position in the questionnaire;
• add new question types (single choice, multiple choice, tables);
• add support for page breaks;
• tag questions as mandatory;
• add non response modality;
• improve code list picker.

Rich text edition

Some labels can now hold rich text: question labels, question labels that use conditions and statement labels. They all use the same component with 4 buttons at the top to toggle inline style (bold and italic), to add links and to add contextual information. This last option is just additional information related to some text (in the rendered questionnaire, it could appear for instance as a tooltip on mouseover).

This component can be a single line input (question labels) or multiline field (statements). In the first case, "Return" key press will be ignored.

The component handles "copy/paste" actions. It only enables to paste raw text (rich text will be transformed to plain text before pasting), and line breaks will be removed (even when dealing with a multiline label).

This component generates some markdown compliant syntax where these elements are used:

• italic;
• bold;
• links with an url and no title that represents a real link;
• links with a title and a dot as url that represents some text with contextual information.

Markdown is used here to represent some structured text in the format expected by the Pogues model, i.e. a regular string. The purpose is to have a common representation between Pogues and the rendering server, not to offer a fully compliant markdown editor. Markdown won't be rendered as is, but will be further processed to generate the questionnaire.

If some markdown is typed in the generic input, it will be rendered as rich text in the label editor component.

More information here: #142

Implementation details

This component is based on draft-js.
Data filled in will be serialized to markdown when the component loses focus (former implementations triggered serialization each time content changed, but it seemed to cause performance issues).

draft-js uses what they call Entity to represent special objects with metadata, like a link. We use the same type of entity (LINK) for links and contextual informations. This is the data attached to the entity (url and title) that will enable distinction between them. A link is a LINK entity with an url and no title, a contextual information is a LINK entity with . as url and some information as a title.

Parsing and serializing of markdown is handled by draft-js-import-markdown and draft-js-export-markdown.

Multiple labels with conditions

A question can have multiple labels depending on conditions. By default, when a user creates a question with the generic input, the question will be considered to have no condition: the label filled in will be rendered all the time.

If then he adds some conditions with the "Add condition" button, he has to describe some conditions and some labels assigned to each of these conditions. The initial label for the question will not be valued anymore in the rendered questionnaire: only the labels assigned to conditions will be used.

There is no "else" condition. That means that's the user responsibility to describe all the possible options.

The conditions and the labels will be represented as a Velocity Template Language string. This option was chosen in order to represent the structured related to conditions as a regular string that fits in the model. See below for more information about it.

Implementation details

The first line of the VTL string will be a VTL single line comment with a JSON representation of the conditions. So the first line will look like:

##{\"label\":\"initial label\",\"conditions\":[{\"id\":\...

It is built with the result of JSON.stringify called on that kind of object:

{
  "label": "initial label",
  "conditions": [{
    "id": "randomid1",
    "label": "first label",
    "condition": "first_condition"
    }, {
    "id": "randomid2",
    "label": "second label",
    "condition": "second_condition"
  }]
}

This first line will be parsed by the application to build back the conditions without having to process the body of the VTL string (it is redundant).

The body of the VTL string represents the conditions with VTL #if and #elseif directives. With the conditions from the previous example, the whole string will look like:

##{\"label\":\"initial label\",\"conditions\":[{\"id\":\...
#if(first_condition)
first label
#elseif(second_condition)
second label
#end

Each label can be a markdown string (see above).

Define statement position in the questionnaire

We can now specify the position of a statement. Options are:

• before the question label;
• after the question label;
• after the response fields;
• as a foot note.

Add new question types (single choice, multiple choice, tables)

Pogues now supports different kinds of questions:

• simple: number, text, date, boolean;
• single choice: the user has to choose a single option within a code list;
• multiple choice; this format is made of:
  • an information axis, which is a code list;
  • a measure, which can be a code list or a boolean;
• tables, this format is made of:
  • one or two information axes;
  • some measures.

Concerning table questions:

• there can only be one measure if there are two axes;
• the user can ask for a total field, that the respondent will have to fill in, to be added to the questionnaire for each axis;
• instead of one or two information axes based on a code list, the user can choose to have only one information axis with no code list but a minimum and a maximum number of responses allowed;
• a measure can be made of a simple response or a single choice response.

The detailed rules behind each of this question types are out of scope for this document.

No matter the question type, when the definition of a response format requires to choose a code list, the user will be offered the option to create a new code list thanks to the code list picker.

The user can switch back and forth between response formats with no lost of information, which is convenient if he changes his mind.

Implementation details

The parsing/serialising process of response format is not trivial: the translation between Pogues model (the xml schema) and the user interface concepts is not straightforward. Hence, the source code has been divided into multiple files for each operation, parsing and serialising: it stays in the ./src/js/utils/response-format directory and is called by model-to-state-questionnaire.js (parsing) and state-to-model-questionnaire.js (serializing).

Related information about the model can be found here: https://github.com/InseeFr/Pogues-Model/blob/53c6151a237ed74d4e655b137a8e55735f141d96/src/main/resources/xsd/Questionnaire.xsd#L57-L94.

A dedicated reducer to handle response format information was created: response-format-by-id. We don't drop information when the user chooses a format instead of another. We just tag the current format to valued the right description, but keeping the old data in memory allows to switch back to the previous format with no lost of information.

Add support for page breaks

We can add a page break after a component (question or sequence). It will allow fine grained specification of the questionnaire layout. To add a page break, the user clicks on the horizontal arrow which appears on the left side of the component label when the mouse is over. The page break is represented with a horizontal line. The small cross on the left side enables to remove the page break.

Pogues will build groups of components (one group per page) based on these page breaks. This is additional information to the regular questionnaire representation (a tree of components).

Implementation details

Internally, Pogues stores information about the last component before each page break. When a component is moved or removed, the page break will then reference the component before the one that has just been moved or removed.

Outside of Pogues, this information is represented conforming to this part of the schema:

<xs:element name="ComponentGroup">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Name" type="xs:token"/>
      <xs:element name="Label" type="xs:token" maxOccurs="unbounded"/>
      <xs:element name="MemberReference" type="xs:token" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID" use="required"/>
  </xs:complexType>
</xs:element>

Names and labels are based on the page rank. In json, this information will look like this, where member references for the first page include all the components (no matter their depth) that should appear on the first page:

"ComponentGroup": [
  {
    "Name": "PAGE_1",
    "Label": "Components for page 1",
    "MemberReference": [
      "isoxwy7u",
      "isoy48wk"
    ],
    "id": "isrp627z"
  },
  {
    "Name": "PAGE_2",
    "Label": "Components for page 2",
    "MemberReference": [
      "isoybsd1",
      "isoxxg2x",
      "isoycgws"
    ],
    "id": "isrpd31w"
  }
]

Tag questions as mandatory

An option in the response format edition enables to indicate that answering this question is mandatory.

Add non response modality

This option is available for single choice questions. The goal is to provide a way to collect further information when the user did not answer a question. A non response modality is made of:

• a code and a label (comparable to a code within a code list);
• a ...