I am experiencing another problem with Price Sets and Financial Types after upgrading from 5.42.1 to 5.43.0. These seems to be due to enabling and disabling CiviContribute in the past.

The latest problem is not being able to update a membership:

TypeError: Argument 1 passed to CRM_Financial_BAO_Order::setPriceSetID() must be of the type int, null given, called in /home/covsa/domains/a.covs.nl/public_html/sites/all/modules/civicrm/CRM/Financial/BAO/Order.php on line 902 in CRM_Financial_BAO_Order->setPriceSetID() (regel 465 van /home/covsa/domains/a.covs.nl/public_html/sites/all/modules/civicrm/CRM/Financial/BAO/Order.php).

Trying to create a new price set:

SELECT id, entity_id FROM civicrm_entity_financial_account WHERE ( account_relationship = AND entity_table = 'civicrm_financial_type' ) ORDER BY entity_id [nativecode=1064 ** You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AND entity_table = 'civicrm_financial_type' ) ORDER BY entity_id' at line 4]

Now if I enable CiviContribute, the problems vanish.

What should I do?

  • try to solve these leftovers;
  • enable CiviContribute but prohibit users to use it.

I think there are a couple things in civi that unintentionally depend on civicontribute. Easier to hide/remove menu items than fight it.

  • though i would suggest these were intentionally dependent - certainly any membership process that involves payments has to involve civicontribute
    – petednz - fuzion
    Nov 7 '21 at 20:49
  • Agreed but I think there are some paths where it's all free stuff even when only handled through the backend that still hit code like this. Not sure if this particular one is one of them but I've seen that kind of dependence before.
    – Demerit
    Nov 7 '21 at 20:56
  • @petednz-fuzion, You are right. But in our situation we do not care what the contribution is, as it is the responsibility to each member organization to set it and get it. Nov 9 '21 at 18:35
  • Furthermore, if this is a coupled dependency, then why bother splitting it into two components (and have the hassle when one of them is disabled)? Nov 9 '21 at 18:36
  • Issue found: lab.civicrm.org/dev/core/-/issues/702 Nov 9 '21 at 18:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.