Currently it works like any other payment method you can select on
checkout. It will eventually be added automatically to the order, when a
customer has credit available.
13220 Fixes affiliate sales spec
13220 Use before_create to update product name
13220 Fixes rubocop warnings
13220 Update product_name in line_item in specs
13220 Fix before_create lint
13220 Add spec for checking product_name is not set in reports
13220 Fixes rubocop issue
13220 Add migrations for updating the existing line items
13220 Fixing lint issues
13220 Set product_name in line_item before doing validation
13220 Fix linter issues
13220 Fixes spec
13220 Fixes linter issues
13220 Review comments
13220 Review comments
13220 Add default product name
13220 Use product_name instead of variant product name when using line item
13220 Fix specs
13220 Revert change in affiliate_sales_data_spec
CL-13220 Store variant name in line_item
13220 Default variant name to original variant's full name for line_items
13220 Add missing frozen string literal
13220 Add spec for full_variant_name
13220 Remove UpdateProductNameInLineItems and AddNotNullToProductNameInLineItems migrations
13220 Remove presence validation for product_name
13220 Use full_product_name which defaults to variant product name if empty
I will need this in the following commit. For existing specs where no variant is specified, a product with variant will be created (I think this is what the line item factory would have done before).
Rewrite the loop "break unless a = order.next! while !order.delivery?" to correct the offenses. Not adding a helper because the change was only needed in a couple of places.
I'm not dropping the database table just yet. Let's keep this change
reversible without data loss. And dropping the table would break the
currently running app code during deploy. We can do that another time.
A Vine voucher is really a specific type of FlatRate voucher but because
a Vine voucher can be used by mutiple enterprise, it can be considered
different enough to warrant it's own class.
It still share a lot of the behaviour of a FlatRate voucher, so to avoid
duplication, all the shared functionality have been moved to a
Vouchers::FlatRatable concern.
Creating a variant actually create an extra one via the associated
product, as it will create a "standard variant".
As far as I can see there is no way around it, but it should be fixed
once the Product refactor is finished, and product becomes product
group.
Added a comment on the variant factory to explain the problem.
It's not ideal as it will slow down the test suite a little, but I think
it's better to write the code the way you would expect it, and it will
eventually get fixed.
Add new text key admin.order.edit.additional_tax_included_in_price
Add spec file for additional tax display. Add new trait for enterprise fee and calculator factory
