* feat(dossier): prefill drop down list champ
* decorate the types de champ to avoid if / else
In order to avoid doing if this a drop down ? / else at several places,
we decorate the types de champ and let the decorator give the possible
and example values.
* show all possible values when there are too many
* allow to prefill 'other' option
* review: remove duplicate
* review: refactor for readability
* validate that value is in options
* review: exclude disabled options
* extract parent for yes no and checkbox champs
* checkbox stores true / false instead of on / off
* normalize blank value to nil
* normalize invalid value to false
* after party task: normalize checkbox values
* after party task: normalize yes_no values
* add base controller for public api
* add dossiers controller with basic checks
* create the dossier
* ensure content-type is json
* prefill dossier with given values
* mark a dossier as prefilled
When a dossier is prefilled, it's allowed not to have a user.
Plus, we add a secure token to the dossier, which we will need later to set a
user after sign in / sign up.
* set user as owner of an orphan prefilled dossier
When a visitor comes from the dossier_url answered by the public api,
the dossier is orphan:
- when the user is already authenticated: they become the owner
- when the user is not authenticated: they can sign in / sign up / france_connect
and then they become the owner
So here is the procedure:
- allow to sign in / sign up / france connect when user is unauthenticated
- set dossier ownership when the dossier is orphan
- check dossier ownership when the dossier is not
- redirect to brouillon path when user is signed in and owner
* mark the dossier as prefilled when it's prefilled
(even with a GET request, because it will be useful later on, for
exmample in order to cleanup the unused prefilled dossiers)
* system spec: prefilling dossier with post request
* feat(demarche): description
Show the description of an opendata procedure (published or draft),
with help about how to prefill a dossier for this procedure.
Co-authored-by: Damien Le Thiec <damien.lethiec@gmail.com>
Actuellement, on fait le choix de ne pas avoir d'éléments porteurs à la
fois d'aria-label et title.
Bien qu'en principe l'aria-label quand elle est gérée par un navigateur,
prenne précédence sur le title, en pratique un bug dans NVDA cumule les 2
et rend la navigation difficile.
On prend donc le parti (provisoire?) de n'avoir que l'un ou l'autre.
Nous gardons le title si l'info qu'il contient est également pertinente
pour les navigateurs graphiques qui l'affichent en guise de tooltip ;
autrement on bascule sur l'aria-label qui est plus largement supporté
par les navigateurs a11y.
