I had to change some specs to keep them simple but I don't think
anything is broken. In one case, it would have needed a lot more setup
to make the spec work. But in production, the permissions are never used
with ModelSet, for example.
We improved the email address validation to check the domain for
existing DNS entries. But our default user has the example.com domain
which is not resolved by my internet service provider.
I couldn't find a better way to deactivate this one check than
overriding the method in the validator. The code does not affect other
parts of the app unless you run multiple rake tasks in the same command
line with the database setup.
Line items which reference a master variant is a scenario that in theory shouldn't have been valid or even possible for at least 5-6 years, and these old bits of data in theory should have been cleaned up at the time those changes were made. But a couple of servers have some really old data that's not in a nice state.
Here we can just flip the is_master flag to false for those specific (legacy data) cases before deleting any other master variants, to keep the legacy line item data intact.
These shouldn't technically exist, but apparently they can be present if the dataset is old enough. They can trigger a foreign key violation if they are present when a master variant is deleted, so they need to be dropped if present.
These shouldn't technically exist, but apparently they can be present if the dataset is old enough. They can trigger a foreign key violation if they are present when a master variant is deleted, so they need to be dropped if present.
There are three main components:
1. The invoice model
2. order serializers: serialize the order for the invoice
3. data presenters: the object that will be use to access the order's serialize data
It should only be true or false. This was flagged by Rubocop. I also
added another Rubocop suggestion and combined two migrations because
they are related.
This reduces the migration run time from 9.6 seconds to 0.16 seconds on
a production database.
* Simplify model naming.
* Remove unnecessary model code.
* Use Rails `missing` scope for efficient simplicity.
* Add `down` method for rollback instead of running `change` again.
