Changes to CiviContribute Component Settings not saved

As reported in Mattermost

Anyone have any idea why the CiviContribute Component Settings page would not be updating values on save? Everything up to the “Enabled Deferred Revenue” field saves fine, but nothing below it (although Civi reports “Your changes have been saved”.  Civi v5.24.3 running on WordPress).

Reproduced on 5.25 RC and master in WP and Drupal 7.

added regression sig:bug labels

It's a weird form - I thought we had unravelled it OK - but I guess not. Maybe we should stick all the stuff that depends on invoicing in a separate form

@eileen Strictly speaking I am not sure when this first became a bug. I test by saving settings the first time, this is on subsequent submissions to the form. I do think a separate form would be the best way forward, but would think we'd target master for that.

To reproduce, I tried a few fields on 5.21(.3-ish) and 5.24(.4-ish). Note:

• Default invoice payment page: This appears below "Enabled Deferred Revenue" on my screen.
  • 5.21: OK
  • 5.22: OK
  • 5.23: OK
  • 5.24: OK
• Enable Tax and Invoicing: This is a toggle which activates a large block of settings.
  • 5.21: OK
  • 5.22: OK
  • 5.23: OK
  • 5.24: OK
• Credit Notes Prefix: Note that this field changed positions between 5.21 (where it's under Enable Tax and Invoicing) and 5.24 (where it's available regardless).
  • 5.21: OK
  • 5.22: OK
  • 5.23: Problematic
  • 5.24: Problematic
• Due Date: Note that this appears under Enable Tax and Invoicing
  • 5.21: OK
  • 5.22: OK
  • 5.23: Problematic
  • 5.24: Problematic

So maybe the issue is with fields that are (or were) under the heading of Enable Tax and Invoicing.

(EDIT: Updated with 5.22 and 5.23.)

Yes - it is the tax & invoicing fields :-(

We did a conversion & it seemed to work & yet...

I think ideally either

1. these wouldn't be dependent on that setting - they are only vaguely related or
2. the form would just show & hide them depending on some more complex magic

So I pulled up a debugger as submitted an updated due_date (old=10; new=15), and it looks like the settings are getting passed into Civi::settings()->set(...) as you'd expect.

Tracing that, I now see that there are magic bits to split the array contribution_invoice_settings into several smaller settings. So the new due_date is actually saved... as invoice_due_date (rather than as contribution_invoice_settings.due_date).

It seems perhaps the magic bits need to provide a more complete facade? Compare the content of contribution_invoice_settings and invoice_due_date after saving:

For a complete facade, you'd expect that invoice_due_date and contribution_invoice_settings.due_date would always present the same value?

https://github.com/civicrm/civicrm-core/pull/17181

Thanks for your work on this, folks -

@eileen - do you have a steer on how we would switch on VAT inclusive reporting in invoices in the meantime? Would we need to manually update the database for now?

mentioned in commit c8419967

mentioned in commit 84d52986

mentioned in commit 8f2a141a

mentioned in commit 1807fca4

mentioned in commit be177277

mentioned in commit 4ee17c61

mentioned in commit 2b2f4d7f

mentioned in commit 8c85aeba

mentioned in commit 598006c3

mentioned in commit ac90350f

changed milestone to %5.24.6

Hi @marcusjwilson The best suggestion is to download install/upgrade 5.24.6 and then check the invoice settings on the CiviContribute Component settings screen to make sure they are correct

As the PR has been merged and a fixed version has been released I am going to close this

closed

mentioned in issue #1712 (closed)