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.
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.
Update app/models/customer.rb
Co-authored-by: Maikel <maikel@email.org.au>
Update spec/models/customer_spec.rb
Co-authored-by: Maikel <maikel@email.org.au>
Update spec/models/customer_spec.rb
Co-authored-by: Maikel <maikel@email.org.au>
authorize created_manually field to be set on APIv1
So it turns out all images uploaded before the ActiveStorage migration are internally set to "public-read", and all images uploaded after the migration are internally set to "private". This migration switches all images in S3 buckets back to "public-read".
