2.4.0

• BREAKING: Changed AddressChangedHandler to handle only AddressChangedEvent instead of all events of IAddressEvent interface. remp/crm#2448
  • If you have event which implements IAddressEvent and depends on processing by AddressChangedHandler, you need to change event (let it extend (override) AddressChangedEvent) or make new handler which will handle your event.
• IMPORTANT: Added column payments.invoice_number_id. remp/crm#2448
  • This migration could take a long time, depending on the size of your payments table. It took ~10 minutes to migrate 800MB table. Consider to run it at off-peak times.
• Added (optional) generation of the invoice number for all paid payments ignoring missing invoice address and setting to disable invoicing (user or admin). remp/crm#2448
  • This is non breaking change. Config generate_invoice_number_for_paid_payment is disabled by default.
  • If invoice cannot be generated, invoice number is generated and connected to payment. When user fulfills conditions to generate invoice (adds invoice address or enables invoicing), an invoice is generated with this invoice number. This is practical if accounting requires to have invoices in order of the purchase dates.
• Added tests for invoice generation, updated few thrown messages & cleaned handlers. remp/crm#2448
• Added column invoices.updated_date & InvoicesRepository->update(). remp/crm#2448
• Changed column invoices.buyer_country_id to nullable. remp/crm#2448
• Moved responsibility to check address into InvoicesRepository->isPaymentInvoiceable(). remp/crm#2448
  • We will need to rely on isPaymentInvoiceable() as "all knowing". No need to duplicate address check outside of it.
• Removed duplicate check isPaymentInvoiceable() before InvoiceGenerator->generate(). remp/crm#2448
  • InvoiceGenerator->generate() has to perform isPaymentInvoiceable() before generating invoice (we cannot rely on caller in this case). No need to call it twice.