This will let us branch by abstraction. All existing calls to
`#outstanding_balance` will go through `OrderBalance` hence, will
check the feature toggle.
Note that by default, `OrderBalance` will end up calling
`#old_outstanding_balance`. As the name states, that's exactly what
`#outstanding_balance` was so far. This means no consumers will see any
change in behavior. We just added on item in the call stack (sort of).
This moves them to a more unit-like style where the mailer methods are
the subjects. However, I did so only for the methods that show order
balance and thus we want to be extra sure of their coverage.
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.
DEPRECATION WARNING: `#deliver` is deprecated and will be removed in Rails 5. Use `#deliver_now` to deliver immediately or `#deliver_later` to deliver through Active Job.
The way we set up email sending completely changes with Spree 2. This
change encapsulates that code in a single method so that it can be
changed easily and doesn't create further merge conflicts while we are
still working on the master branch and the Spree upgrade.
A bug introduced in a9c37c162e caused the
creation of confirmation emails for shops to fail. The email template
got fixed now and the email address from the database is displayed if
present.
