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.
- rename `dossiers_id_with_notifications` to `followed_dossiers_with_notifications`,
- rename `notifications_per_procedure` to `procedures_with_notifications`,
- return an ActiveRecord::Relation instead of the result of the query, so that the call place can compose it,
- `merge` with the wanted Dossier scope in the call places, don’t bother passing it as a parameter,
- use the “state” (now “scope”) parameter as a scope method that can be just applied on `Dossier`.
This is used in /procedures#show and /procedures#index, to display badges on the “suivis” and “traités” tabs of each procedure. Rails cache helps when it’s the exact same query, but it’s not the case for different tabs.
I’m not certain it’ll be a visible performance improvement but it shouldn’t hurt.
* Get rid of the “reopen” event, merge it with “publish” (it’s the same code)
* Remove the “availability” states; “available with brouillon” makes no sense since the brouillons path are always uuids
* Instead of checking if publish can happen, just try it and handle the errors
It is actually the same thing as Gestionnaire.procedures. It already included the procedures with paths as well as the archived procedures, and in production, there were no Gestionnaire for who procedures was returning a different result than visible_procedures (expect for two baddata brouillon procedures with a nil path).
In addition, Procedure.path is now nonnull, which means the Procedure.avec_lien scope is pointless.
Finally, the current spec showed that the only procedure not visible to the gestion was the one he was not assigned to.
