* 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>
* store prefill params in session
Instead of using query params on /dossier/new, we assume the user comes
from /commencer/:path, which is the new prefill link.
There, we store the prefill params in session, and use them to prefill
the dossier when creating it, in /dossiers/new.
* spec: cover the case
* review: serialize with json instead of yaml
* review: rename method
* review: store only query params
* review: comment why we dont override already stored params
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.
