We had a validation rule for milestones which made sure either the
status or the description was present. However, since the description is
now translatable, the validation error wasn't being displayed in the
admin form.
Moving the validation rule to the translation object fixes the problem.
However, the translation object needs to check an attribute in the
milestone object in order to know whether the description is required or
not. This is tricky because by default it loads the milestone object
from the database, meaning it doesn't work with new records and it
ignores params sent by the browser.
The solution is to manually assign the globalized model before
validating the object. It's a hack, but apparently Rails doesn't provide
a better way to handle this case [1].
[1] https://github.com/rails/rails/issues/32024
Not doing so might cause the following test to use translations for
only one locale. This scenario happens if the previous test executes
I18n.reload!, which resets I18n.config.backend's "@translations"
instance variable.
So, the sequence could be as follows:
1. The previous tests sets `@translations = nil`
2. This test stubs `available_locales` to `[:en]`
3. `@translations` gets only translations for `en`
4. The following test doesn't find translations for Spanish and fails
We make the tests considerably faster, we make them more robust against
changes in the number of records shown per page, and we generate enough
records so the chance of randomly getting the same results twice in a
row is extremely low.
We were having problems under certain conditions with Travis and
Knapsack where tasks were still being loaded twice and so they were
being executed twice.
When we insert a record in PostgreSQL and we specify the ID, the
internal ID sequence for that table isn't updated.
In order to keep the original IDs so we didn't break any foreign keys,
we specified the IDs when copying the table, resulting in a table having
its ID sequence with a value of an existing record. When trying to
insert a new record, we got a `PG::UniqueViolation` exception.
Updating the sequence after the data migration might not be the most
elegant solution, but it's easy to do and it's already been tested on a
production environment.
Calling `load_tasks` in several files made rails load the tasks several
times, and so they were executed several times when called.
Since the milestone migration can't be executed twice in a row (it would
fail with duplicated ID records), loading the tasks several times made
the milestone migrations task specs fail.
