Before this commit, the monthly dossiers count was serialized into the
Stat record using human-formatted dates, as:
```ruby
s.dossiers_in_the_last_4_months = {
"octobre 2021"=>409592,
"novembre 2021"=>497823,
"décembre 2021"=>38170,
"janvier 2022"=>0
}
```
Turns out the ordering of keys in a serialized hash is not guaranteed.
After a round-trip to the database, the keys will be wrongly sorted.
Instead we want to save raw Date objects, which will preserve the
ordering. The date formatting can be applied at display-time by the
controller.
Fix#6848
Context: we want to validate public and private types_de_champ
separately.
Before we validated the whole revision (and then validators themselves
enumerated all champs, public and private).
Now we validate the actual public types_de_champ, which will let us
validate separately the private types_de_champ.
Errors generated by the `invisible-catcha` gem are reported as
`flash[:error]` (which differs from Rail's usual `flash[:alert]`).
We probably shouldn't use flash[:error] in our own codebase; but we can
handle its use in third-party libraries.
Errors generated by the `invisible-catcha` gem are reported as
`flash[:error]` (which differs from Rail's usual `flash[:alert]`).
Avoid crashing when the flash level passed to this helper is not known.
For an unknown reason, ActiveRecord::Base.connected? does not work anymore in dev. It returns false negative.
This simple workaround can timeout. The caller has to monitor the response time.
fix(profil_controller#update_email): changing email from current_user.email to current_user.email destroy current user. whoops ☠️'
Update config/locales/en.yml
Co-authored-by: Pierre de La Morinerie <pierre.de_la_morinerie@beta.gouv.fr>
Update config/locales/fr.yml
Co-authored-by: Pierre de La Morinerie <pierre.de_la_morinerie@beta.gouv.fr>
Update spec/controllers/users/profil_controller_spec.rb
Update config/locales/fr.yml
Co-authored-by: Pierre de La Morinerie <pierre.de_la_morinerie@beta.gouv.fr>
Update spec/controllers/users/profil_controller_spec.rb
fix(spec): broken due to typo
This fixes an issue where, by default, links to private attachments are
reported to Matomo.
This is benign: attachments URLs can be filtered out server-side, and
expire after one hour anyway. But we don't want to ship an insecure
configuration by default.
use dedicated archives queue
As the used disk space will increase, we want a fined grain control
move zip logic in dedicated method
zip
wip
wip
fix(spec): pass spec in green
tech(improvements): avoid File.delete(folder), favor FileUtils.remove_entry_secure which is safer. Also wrap most of code that open file within blocks so it is cleaned when the block ends. Lastly use attachement.download to avoid big memory pressure [download in chunk, write in chunk] otherwise big file [124>1GO] are loaded in memory. what if we run multiple jobs/download in parallel ?
fix(spec): try to retry with grace
clean(procedure_archive_service_spec.rb): better retry [avoid to rewrite on open file]
lint(things): everything
This request currently times out almost every night in production.
It's because although Instructeurs are loaded in batches (default batch
size is 1000), loading all dossiers for 1000 instructeurs is slow.
Turns out the code executed after this query to compute notifications
doesn't even use these dossiers. Indeed it is faster not to preload
them: both the initial query and the total treatment time are shorter.
Here's a quick benchmark made locally (but using production data):
- Before this commit:
Benchmark.measure { pp Instructeur.includes(assign_to: { procedure: :dossiers }).where(assign_tos: { daily_email_notifications_enabled: true }).limit(100).m
ap(&:email_notification_data) }
Only the initial query : 35s
Total time : 97s
- Without preloading dossiers:
Benchmark.measure { pp Instructeur.includes(assign_to: :procedure).where(assign_tos: { daily_email_notifications_enabled: true }).limit(100).m
ap(&:email_notification_data) }
Only the initial query : 0.08s (400x faster)
Total time : 29s (3,3x faster)
Plus it doesn't timeout, of course.
