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
In a9a4f6e2a8, a task to migrate
ProcedurePresentation's filters was added.
This task added a "migrated: true" key to all migrated filters.
Now that this task has run, we can safely remove the extra key.
In a previous version of this commit, the migration would fail for
invalid ProcedurePresentation records. This is now fixed.
In a9a4f6e2a8, a task to migrate
ProcedurePresentation's filters was added.
This task added a "migrated: true" key to all migrated filters.
Now that this task has run, we can safely remove the extra key.
- Make `champ.dossier` a requirement;
- Move the dossier_id assignation to `before_validation` (otherwise
the record is invalid, and never gets saved);
- Allow specs to only build the champ (instead of saving it to the
database), which bypasses the requirement to have a dossier.
Fixes a task that since became invalid:
> NameError: uninitialized constant SeekAndDestroyExpiredDossiersJob
> /lib/tasks/deployment/20191203142402_enable_seek_and_destroy_job
L'intention est de distinguer ce type d'erreur avec les erreurs serveur
5xx.
Lorsque l'api est appelé par un Job, les erreurs serveur seront retry, car éphémères.
Alors que les erreurs de type BadFormatRequest ou ResourceNotFound n'ont
pas être retried.
Test helpers are separated between two files: spec_helper and
rails_helper. This separation is meant to allow tests that do not
require Rails (like testing standalone libs) to boot faster.
The spec_helper file is always loaded, through `--require spec_helper`
in the `.rspec` config file. When needed, the rails_helper file is
expected to be required manually.
This is fine, but:
- Many test files have a redundant `require 'spec_helper'` line;
- Many test files should require `rails_helper`, but don't.
Not requiring `rails_helper` will cause the Rails-concerned section of
the test environment not to be configured–which may cause subtle bugs
(like the test database not being properly initialized).
Moreover, Spring loads all the Rails files on preloading anyway. So the
gains from using only `spec_helper` are thin.
To streamline this process, this commit:
- Configures `.rspec` to require `rails_helper` by default;
- Remove all manual requires to spec_helper or rails_helper.
Reference: https://stackoverflow.com/questions/24145329/how-is-spec-rails-helper-rb-different-from-spec-spec-helper-rb-do-i-need-it
The `conversations_count` we previously used counts replies, but also
all conversations that were tagged or re-tagged during the month – with
made counting the actual work spent on user support brittle.
Counting the replies is a better estimation of what we get.
Unfortunately this also removes the filtering-by-tag feature. To
mitigate this, the reports are now scoped to a specific mailbox. This
allows to create extra mailboxes for conversations that should't be
counted in the stats.