This includes the following emails:
Manager invitation email: reply to inviting enterprise
Authorize payment email: reply to distributor
Order cancellation email: reply to distributor
Shipment notification email: reply to distributor
When the invoices feature is enabled, for every order, we check if
1. a new invoice must be generated
2. or, the latest invoice needs to be updated
the invoice rendrer input depends on the invoices flag.
if the feature is enabled, the input is supposed to be an invoice presenter
This construct was previously used in Spree to switch out the user class with a dummy class during certain tests. We don't use this any more, so it's just mess.
🔥
DRY code and have more consistency. We always use "Terms of service" now
and not "Terms of Service" or "Terms and conditions". The latter is used
for the shop's terms, not the platform terms.
Here we were rendering an entire PDF, then passing that PDF into the job queue as an *argument* containing the entire binary of the PDF in a massive string. This means the job object itself would contain that entire PDF. That's bad queueing!
We now create the PDF *during* the job (not before it), and pass simple arguments.
We had a very prominent footer showing how to get in contact with the
local instance people but most users need to get in contact with the
enterprise they are buying from. So removing all those details and
replacing them by a simple "powered by" line will hopefully direct
attention to the shop's contact details.
Fixes#6435 i.e. If the customer paid for their order by Stripe/Paypal then the Enterprise needs to know that the order was cancelled in order to arrange a refund. Refunds are not automatically processed when an order is cancelled.
This will send a very basic email to the shop, it only includes a link to view the cancelled order in the admin area initially.
I created a CustomerOrderCancellation object here because orders can be cancelled in two ways (1) by the customer, so an email should be sent to the shop. (2) by the shop, so an email doesn't need to be sent. However the code for cancelling order happens in Order#cancel via the state machine. Rather than passing some sort of parameter into #cancel to indicate whether it is a customer or shop cancelled order it might be clearer to have a CustomerOrderCancellation object, there could be other differences between customer or shop cancelled orders in future maybe.
- Partial is used by both the invoice pdf and the order confirmation email
- separate scss file for new payment list table
- extracted outstanding balance logic (also changed in payments view.. admin/orders/RXXX/payments)
- translations in shared.payments_list and lazy loaded
