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".
It looks like the resolution of a merge conflict introduced the wrong
ordering of schema statements. Rails wants to sort tables alphabetically
and running `./bin/rails db:migrate` on a fresh database altered the
schema.rb file. This should be fixed here.
Rails also omits the default setting of `precision: 6` since Rails 7.
The vouchers feature was developed during the upgrade to Rails 7.
Using the clever concurrency testing borrowed from SubscriptionPlacementJob, but I thought a shorter pause time (just 100ms) would be sufficient.
I considered doing this with a new 'state' field (upcoming/open/close), but decided to keep it simple.
Although we won't be allowing multiple in the this PR, we certainly plan to in the future.
The migration helper add_reference couldn't handle the custom column name, so I had to put it together manually.
This will store the URL for each user that wants a notification.
We probably don't need URL validation (it's not done on Enterprise for example). It could be validated by browser input, and anyway will be validated if the webhook actually works or not.
Inspired by Keygen: https://keygen.sh/blog/how-to-build-a-webhook-system-in-rails-using-sidekiq/
