Validate that a dossier on a `for_individual?` procedure always has
an `individual` associated record.
For this, the individual needs to be built before the record is
validated (i.e. even before the `before_create` callback is run).
This should help with #4596: now if a dossier is created without an
`individual`, or if the `invividual` record is later removed, the
validation will fail.
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.
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.
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.
Now that `Instructeur.email` is merely an alias to `instructeur.user.email`,
and we changed every occurence of `instructeurs.pluck(:email)` to
`instructeurs.map(&:email)`, the new version using `map` may cause N+1 queries
if the users have not been preloaded.
It makes sense to always preload the user when fetching an Instructeur:
- Instructeur and User have a strongly coupled relationship
- It avoids N+1 queries everywhere in the app
Of course fetching an instructeur without needing its user will now do an
unecessary fetch of the associated user. But it seems better than leaving
a risk of N+1 queries in many places.
