Currently, a number of dossiers in production are for procedures for
individuals, but don't have a `individual` object.
This is probably because creating the Individual from France Connect
infos fails – but fails quietly, and nullify the relationship.
As a first step, we now raise an exception when the creation from FC
infos fails. We will then identify the issue, and see if we can fix it –
or if we should be resilient to this kind of issues.
Before, when the "Add new champ" button was clicked, the new champ
was inserted after the **first** fully visible champ.
That was most of the time unexpected. The correct behavior would be to
insert the new champ after the **last** fully visible champ.
That's what this commit does. Now the "Add new champ" behavior feels
much less confusing.
it follows service-public.fr structure
- remove extraneous footer-link class
- remove extraneous space with `>` haml weird stuff
- homogenize json-style hash
- merge classes on ul
- use pseudo element for eye candy
client_key is exposed to the client via gon, so if we use it for sending email too we are exposing a key so anybody could send an email.
The current client_key has a different level of right and can't send emails so it's ok to expose it.
When inviting an instructeur, the code first looked up an existing
instructeur using the normalized (downcased) email address–but then
tried to promote it using the non-normalized version, which failed.
This fixes the issue by always using the normalized email.
Before the form attempted to read an email value from the Instructeur
model, and failed (because the empty Instructeur had no user yet).
We could let `Instructeur#email` return `nil` if there is no User –
but as a created Instructeur is always supposed to have a User, this
seems like a nice safeguard to keep.
So instead this commit rewrites the create form, which now doesn’t
depend on an Instructeur model. Seems easy enough for now.
It kind of worked until now, because the email field is disabled, and
thus never accessed.
But better make it clean, by accessing an object (User) where the email
field actually exists.
The `joins` are declared explicitely in order to associate a predictable
name to the joined table.
Otherwise, when the query is joined with `:users`, ActiveRecord will
alias the join automatically to solve the conflict. Unfortunately, the
automatic resolution means that the table name becomes unpredictable,
and thus unsuitable to perform queries on.
