Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-06T05:03:19Zhttps://lab.civicrm.org/dev/core/-/issues/2260Can't set more than one bulk email even when the setting to allow more than o...2023-06-06T05:03:19ZDaveDCan't set more than one bulk email even when the setting to allow more than one is turned onI don't have a stake in this it just came up while reviewing a PR. It might be a good one for a newcomer to look at.
1. Administer - CiviMail - CiviMail Component Settings.
1. Turn on "Enable multiple bulk email address for a contact".
...I don't have a stake in this it just came up while reviewing a PR. It might be a good one for a newcomer to look at.
1. Administer - CiviMail - CiviMail Component Settings.
1. Turn on "Enable multiple bulk email address for a contact".
1. Edit a contact with 2 email addresses. Don't use inline editing use the full edit form. It works ok with the inline editing.
1. Try to set both emails to be bulk email (using the UI).
Since it works with inline, my guess is there's different javascript being loaded for the two forms, so maybe it's as simple as having the right javascript load. I haven't looked.https://lab.civicrm.org/dev/core/-/issues/2259Error messages when viewing Membership via Activity search2020-12-18T16:10:49ZTony Maynard-SmithError messages when viewing Membership via Activity searchOverview
----------------------------------------
**I have just tried using the system for something else, but reached the same screens without error. It's obviously more complicated than reported below.**
**Closing this issue. It loo...Overview
----------------------------------------
**I have just tried using the system for something else, but reached the same screens without error. It's obviously more complicated than reported below.**
**Closing this issue. It looks like Webform_civicrm is not completing the necessary field in the Activity record.**
I get a variety of Error messages when viewing a Membership record via the 'view' link in an Activity search. In some cases there is a message but the Membership record is still displayed, but in some the Membership record box is just blank.
The attached file contains some examples.
Reproduction steps
----------------------------------------
I have a configuration where the primary Membership belongs to a Household, and flows down to Individual Contacts via 'Household of/Member of' Relationships.
- The examples are obtained by going to the Activity tab on the Household Contact record, and clicking on the 'view' link against different Activities.
- The same errors occur if one does an Advanced Search, and specifies an Activity Search for the affected Activity types.
- The Errors are seen on the primary Household record, but not if similar Activities are selected on the Individual records.
Current behaviour
----------------------------------------
The attached document shows screenshots of the errors and the messages logged to the Drupal watchdog (redirected from CiviCRM.
Environment information
----------------------------------------
- CiviCRM 5.32.2, but also on 5.28.2.
- Drupal 7.77
- PHP 7.3, but also on PHP 7.2
[Activity_Errors.docx](/uploads/4afaa1b9a5c324ab14c2f0ab7c2d9b44/Activity_Errors.docx)
[Activity_Errors.pdf](/uploads/a9bfa71b5e6c4791d4dca8fd60e121cc/Activity_Errors.pdf)https://lab.civicrm.org/dev/core/-/issues/2257Translateability of on_behalf and honor_block_title for contribution pages2020-12-16T21:03:36ZAlanDixonTranslateability of on_behalf and honor_block_title for contribution pagesAs described here https://civicrm.stackexchange.com/questions/38441/how-do-i-translate-the-on-behalf-of-label/38442
Short version: those labels are customizable per contribution page and live in the civicrm_uf_join table as the 'module_...As described here https://civicrm.stackexchange.com/questions/38441/how-do-i-translate-the-on-behalf-of-label/38442
Short version: those labels are customizable per contribution page and live in the civicrm_uf_join table as the 'module_data' field, but the interface doesn't give you the multilingual field options.
It looks like there's just some code somewhere that should identify these fields as translatable so that the little translator popup gets attached.https://lab.civicrm.org/dev/core/-/issues/2256create contact: subtype retained after removal2024-02-29T05:03:24Zlcdwebcreate contact: subtype retained after removalTo recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype i...To recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype is created.
Actual result: the student subtype is retained.
I suspect what's happening is that on form submission the subtype field is getting reset via the URL param.
But it poses a question, as I think there are two ways we could approach this:
1. fix the form per the above. on submission, ensure we process the form field value and don't allow the URL param to reset it.
2. freeze the subtype field. one could argue that if I'm choosing to create a New Student I should be locked into that path. we could check to see if a URL param for subtype was passed and then freeze that field. the downside is that it would prevent you from setting multiple subtypes for the contact.
Would like to get some opinions/thoughts from the community before I work on a patch.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/2254Inline email edit form fails to set is_bulkmail flag2020-12-17T19:44:57ZRichInline email edit form fails to set is_bulkmail flagExpected behaviour: edit emails, check bulk on one of them, hit save: should show that that email is bulk.
Actual: no email is set bulk (and if one was, it's unset!)Expected behaviour: edit emails, check bulk on one of them, hit save: should show that that email is bulk.
Actual: no email is set bulk (and if one was, it's unset!)5.34.0RichRichhttps://lab.civicrm.org/dev/core/-/issues/2251Fatal error Incorrect datetime value: '0' for column 'transaction_date' when ...2023-07-28T05:03:22ZDaveDFatal error Incorrect datetime value: '0' for column 'transaction_date' when editing a participant record and recording payment with no received date1. Find a participant record that does not have payment recorded.
1. Edit it.
1. Minor problem: The payment section should be hidden until you click the record payment checkbox, but it suggests possibly something wrong with the javascrip...1. Find a participant record that does not have payment recorded.
1. Edit it.
1. Minor problem: The payment section should be hidden until you click the record payment checkbox, but it suggests possibly something wrong with the javascript. Similar thing with send confirmation receipt.
* Also if you're editing one from the stock sample data you get the word "Total" hanging alone in midair above it, but this might be a separate issue with the sample data which maybe didn't get updated for some kind of change in what it's looking for here. Doesn't happen with newly created ones.
1. Bigger problem: If you check the box and then fill out the amount (just the amount) and click save you get `Incorrect datetime value: '0' for column 'transaction_date' at row 1`.
* You can get this on a brand new participant registration too if you manually blank out the default received date, but you probably wouldn't do that in real life. Just it's obviously pointing to some incorrect handling of blanks.
I'm marking it a regression since doesn't happen in 5.28. And interestingly the javascript for the send confirmation checkbox works in 5.28, although the record payment checkbox is the same as master.
```
0 .../CRM/Core/Error.php(148): CRM_Core_Error::backtrace()
1 .../vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::handle(Object(DB_Error))
2 .../vendor/pear/db/DB.php(998): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "INSERT INTO `civicrm_financial_item` (`transaction_date` , `contact_id` , `de...")
3 .../vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "INSERT INTO `civicrm_financial_item` (`transaction_date` , `contact_id` , `de...")
4 .../vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "INSERT INTO `civicrm_financial_item` (`transaction_date` , `contact_id` , `de...", "DB_Error", TRUE)
5 .../vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
6 .../vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-1, NULL, NULL, "INSERT INTO `civicrm_financial_item` (`transaction_date` , `contact_id` , `de...", "1292 ** Incorrect datetime value: '0' for column 'transaction_date' at row 1")
7 .../vendor/pear/db/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
8 .../vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("INSERT INTO `civicrm_financial_item` (`transaction_date` , `contact_id` , `de...")
9 .../packages/DB/DataObject.php(2696): DB_common->query("INSERT INTO `civicrm_financial_item` (`transaction_date` , `contact_id` , `de...")
10 .../packages/DB/DataObject.php(1245): DB_DataObject->_query("INSERT INTO `civicrm_financial_item` (`transaction_date` , `contact_id` , `de...")
11 .../CRM/Core/DAO.php(638): DB_DataObject->insert()
12 .../CRM/Financial/BAO/FinancialItem.php(142): CRM_Core_DAO->save()
13 .../CRM/Contribute/BAO/Contribution.php(1137): CRM_Financial_BAO_FinancialItem::create((Array:9), NULL, (Array:1))
14 .../CRM/Contribute/BAO/Contribution.php(3765): CRM_Contribute_BAO_Contribution::createFinancialItemsForLine((Array:31), "changeFinancialType", (Array:1), (Array:1), (Array:30), FALSE, (Array:1), 8)
15 .../CRM/Contribute/BAO/Contribution.php(3595): CRM_Contribute_BAO_Contribution::updateFinancialAccounts((Array:31), "changeFinancialType")
16 .../CRM/Contribute/BAO/Contribution.php(215): CRM_Contribute_BAO_Contribution::recordFinancialAccounts((Array:31))
17 .../CRM/Contribute/BAO/Contribution.php(479): CRM_Contribute_BAO_Contribution::add((Array:31))
18 .../CRM/Event/Form/Participant.php(1330): CRM_Contribute_BAO_Contribution::create((Array:31))
19 .../CRM/Event/Form/Participant.php(944): CRM_Event_Form_Participant->submit((Array:29))
20 .../CRM/Core/Form.php(513): CRM_Event_Form_Participant->postProcess()
21 .../CRM/Core/QuickForm/Action/Upload.php(152): CRM_Core_Form->mainProcess()
22 .../CRM/Core/QuickForm/Action/Upload.php(119): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Event_Form_Participant), "upload")
23 .../packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Event_Form_Participant), "upload")
24 .../packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Event_Form_Participant), "upload")
25 .../CRM/Core/Controller.php(347): HTML_QuickForm_Page->handle("upload")
26 .../CRM/Event/Page/Tab.php(100): CRM_Core_Controller->run()
27 .../CRM/Event/Page/Tab.php(166): CRM_Event_Page_Tab->edit()
28 .../CRM/Core/Invoke.php(312): CRM_Event_Page_Tab->run((Array:4), NULL)
29 .../CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:12))
30 .../CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:4))
31 .../drupal/civicrm.module(459): CRM_Core_Invoke::invoke((Array:4))
32 .../includes/menu.inc(527): civicrm_invoke("contact", "view", "participant")
33 .../index.php(21): menu_execute_active_handler()
34 {main}
```https://lab.civicrm.org/dev/core/-/issues/2250Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDetermineP...2023-06-29T05:03:21ZDaveDNotice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent`Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in CRM_Contribute_BAO_Contribution->loadRelatedObjects() (line 2796 of .../CRM/Contribute/BAO/Contribution.php).`
It's not clear if t...`Notice: Undefined variable: CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromEvent in CRM_Contribute_BAO_Contribution->loadRelatedObjects() (line 2796 of .../CRM/Contribute/BAO/Contribution.php).`
It's not clear if this is an expected notice that's on the roadmap already someday to improve, or if this is an unexpected path that should no longer be possible.
I'm not sure exactly what the trigger is yet, but it can be reproduced on dmaster.demo with contact id 9 and contribution id 46 by just opening the contribution and saving it (turn off popups so you can see the error). The contribution looks like this:
![Untitled](/uploads/bd527b3d06d9d2f65b386f6369f11a08/Untitled.png)https://lab.civicrm.org/dev/core/-/issues/2249View participant form has a Save button??2020-12-12T14:11:15ZDaveDView participant form has a Save button??Secondary issue from https://lab.civicrm.org/dev/core/-/issues/2248
On the view participant form for an event participant there's a Save button which makes no sense. And if you click it it gives form validation errors.
Looks ok in 5.28...Secondary issue from https://lab.civicrm.org/dev/core/-/issues/2248
On the view participant form for an event participant there's a Save button which makes no sense. And if you click it it gives form validation errors.
Looks ok in 5.28. So it started sometime since then.https://lab.civicrm.org/dev/core/-/issues/2248Find Participants: Broken "Edit" button2020-12-12T23:13:08ZtottenFind Participants: Broken "Edit" buttonOverview
----------------------------------------
When viewing a "Participant" record, the "Edit" button is broken.
Reproduction steps
----------------------------------------
1. Navigate to "Events" => "Find Participants"
1. Enter some...Overview
----------------------------------------
When viewing a "Participant" record, the "Edit" button is broken.
Reproduction steps
----------------------------------------
1. Navigate to "Events" => "Find Participants"
1. Enter some search criteria (or blank criteria). Run the search.
1. On one of the "Participant" records, click "View"
1. The "View" screen has a button bar which includes an "Edit" button. Click it.
![Screen_Shot_2020-12-11_at_2.28.58_PM](/uploads/e8f42fa1f0221e28c20ee8515c37f3b8/Screen_Shot_2020-12-11_at_2.28.58_PM.png)
Current behaviour
----------------------------------------
The link appears malformed. In this example, note the snippet `&id=&cid=`
http://dmaster.127.0.0.1.nip.io:8001/civicrm/contact/view/participant?reset=1&id=&cid=&action=update&context=search&selectedChild=event&key=b931364305ae7cf0438a86ab9e03f59e71c3aab8fcdf09fc76b9208032c17bb4_1567
The request fails. The symptom depends on whether you use AJAX popups or not. If you're using separate pages (non-popups), then it fails with:
![Screen_Shot_2020-12-11_at_2.33.15_PM](/uploads/4c67fce41ca2e740356d47e5803a3be4/Screen_Shot_2020-12-11_at_2.33.15_PM.png)
Expected behaviour
----------------------------------------
Show the "Edit Participant" screen
Environment information
----------------------------------------
* __Browser:__ _Firefox
* __CiviCRM:__ _Master
* __PHP:__ 7.1
* __CMS:__ D7
* __Database:__ MySQL 5.7
* __Web Server:__ Apache5.32.2https://lab.civicrm.org/dev/core/-/issues/2247Organization Membership renew "Payment Processor Error Message: Invalid Relat...2023-08-04T05:03:25ZnicholashOrganization Membership renew "Payment Processor Error Message: Invalid Relationship"Overview
----------------------------------------
We have several Organizations unable to renew their membership using a Contribution Page that uses "Allow individuals to contribute and / or signup for membership on behalf of an organiza...Overview
----------------------------------------
We have several Organizations unable to renew their membership using a Contribution Page that uses "Allow individuals to contribute and / or signup for membership on behalf of an organization?" with the option required. Specifically when the Org itself has a Drupal login and tries to renew on behalf of itself.
Reproduction steps
----------------------------------------
1. Create new org and individual contacts, each with the same primary email address, and an “employee of” relationship between them
1. For the Org, create a Drupal user (clicked **Actions -> Create User Record**)
1. Create a **New Contribute Page**
1. Entered **Financial Type** as **Member Dues** and uncheck **Use a confirmation page?**
1. In the **Title** tab check **Allow individuals to contribute and / or signup for membership on behalf of an organization?** and selected **Organization Profile** as **On Behalf Of Organization** and **Copy** it removeing all fields except **Organization Name** and **Email (Main)** then set it to **Required**
1. **Amounts** tab: check **Payment Processor -> Credit card test** and check **Pay later option** and enter **Pay Later Instructions** and uncheck **Contribution Amounts section enabled**
1. **Memberships** tab: check **Membership Section Enabled?** and check any **Membership Types** and checked **Require Membership Signup**
1. Open the form Logged in or Masquerading as the new Org user
1. Select a **Membership** and and enter the **Organization Name** and **Email (Main)** which should be the same as the other Email field and select **I will send payment by check** and click **Contribute**
1. Got an error "**Payment Processor Error Message: Invalid relationship**".
You may need to edit the Membership to expire it then redo the form to get the error.
Current behaviour
----------------------------------------
On making a Contribution to renew the Org's Membership as a user associated with the Org, the form fails and shows a **Payment Processor Error Message: Invalid relationship** message
![image](/uploads/f085fe705cd8651724b1f68f7a08c26a/image.png)
Doing some digging, we found this to originate from CRM/Contact/BAO/Relationship.php in the create() function. There it is calling checkValidRelationship() with $params=[[contact_id_a] => 17783, [contact_id_b] => 17783, [relationship_type_id] => 4, [is_permission_a_b] => 1]. It seems that Civi is trying to check the relationship between the Org and Individual (type 4) but using the Org contact id for both contacts. So maybe Civi is confusing the two contacts as they have the same email.
Expected behaviour
----------------------------------------
A user logged in as an Org should be able to make a renewal contribution on behalf of themselves.
Environment information
----------------------------------------
* __CiviCRM:__ _CiviCRM 5.31.0_
* __CMS:__ _Drupal 7.74_
Comments
----------------------------------------
I tried to reproduce on dmaster but I didn’t appear to have permission to create a drupal user on the org contact, so was not able to test properly.https://lab.civicrm.org/dev/core/-/issues/2246Export selected entries in Membership search results when selecting fields: a...2020-12-12T06:15:37ZorigamiusaExport selected entries in Membership search results when selecting fields: all results are returned, not selected entriesOverview
----------------------------------------
When doing a Membership Search, selecting a subset of the results for export, and then selecting fields to export, the download file contains all results of the initial search, not the se...Overview
----------------------------------------
When doing a Membership Search, selecting a subset of the results for export, and then selecting fields to export, the download file contains all results of the initial search, not the selected subset.
Reproduction steps
----------------------------------------
1. Do a membership search and select a subset of the results for export.
2. Choose "Export Members".
2. On the "Export Options (step 2 of 3) page, choose "Select Fields to Export".
3. Then select some fields and download.
Current behaviour
----------------------------------------
The resulting download contains ALL results, not just the ones that were selected at the beginning.
By contrast, if you set the export to "Export PRIMARY fields", only the selected rows will be in the download file, as expected.
Expected behaviour
----------------------------------------
The download file should have only contained the rows that were selected at the beginning of the export process.
Environment information
----------------------------------------
This behavior happens on our CiviCRM 5.32.1/Drupal 7 site.
It can be reproduced on the CiviCRM Sandbox on Drupal, which is currently showing that it's running CiviCRM 5.34.alpha1, starting the search at https://dmaster.demo.civicrm.org/civicrm/member/search .
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ Safari
* __CiviCRM:__ both 5.32.1 and 5.34.alpha1
* __PHP:__ 7.3
* __CMS:__ Drupal 7.77https://lab.civicrm.org/dev/financial/-/issues/161Proposal: Allow different "EntityFinancialAccount" records for financial type...2020-12-17T18:41:27ZJonGoldProposal: Allow different "EntityFinancialAccount" records for financial types based on payment methodAs a bookkeeper, I want to record a contribution and have the financial account mapping be correct.
Because "payment method" influences the financial accounts, it's evolved from its original purpose of recording "cash, check, or credit ...As a bookkeeper, I want to record a contribution and have the financial account mapping be correct.
Because "payment method" influences the financial accounts, it's evolved from its original purpose of recording "cash, check, or credit card" to also defining the bank account. I.e. if you have two bank accounts (and use accounting integration), you can't record payment method as "check"; you need "check - bank A" and "check - bank B".
However, changing the payment method should (but can't) potentially change the expense account code. At present, **expense accounts are tied to the financial type only**.
In Raiser's Edge, you can specify an unlimited number of "EntityFinancialAccount" mappings for a "Financial Type". The mapping used is a combination of "Financial Type" and "Payment Method".
**Proposal:**
* We add a new optional field to `civicrm_entity_financial_account` called `payment_instrument_id`.
* `CRM_Financial_BAO_FinancialAccount::getFinancialAccountForFinancialTypeByRelationship()` takes an optional third parameter of `payment_instrument_id`. If the value isn't `NULL`, it returns a different set of financial accounts.
**Alternate proposal**
While researching, I saw [this comment](https://github.com/civicrm/civicrm-core/pull/14058#issuecomment-483848271) by @eileen that suggested that others also have a desire to modify the financial accounts recorded based on other factors (e.g. Campaign ID). So perhaps a hook in `CRM_Financial_BAO_FinancialAccount::getFinancialAccountForFinancialTypeByRelationship()` would be better. We'd need to pass in additional context for it to be meaningful. A contribution ID, or possibly a line item ID.
Pinging some folks I know maintain installs with complex finances - @lcdweb @JoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/2245missing code in contribution_recurring_notify template (Contributions - Recur...2024-02-28T05:03:22ZMariaVmissing code in contribution_recurring_notify template (Contributions - Recurring Start and End Notification)Dear core-team,
I've noticed that there is code missing in the system workflow template "Contributions - Recurring Start and End Notification". When I wanted to add a confirmation message in a donation page, it was not shown in the noti...Dear core-team,
I've noticed that there is code missing in the system workflow template "Contributions - Recurring Start and End Notification". When I wanted to add a confirmation message in a donation page, it was not shown in the notification email.
So I checked the template "Contributions - Receipt (on-line)" because it was working for single contributions.
And there I've found the following code snippet:
`{if $receipt_text}
{$receipt_text}
{/if}`
This is missing in the template for reccuring contributions.
I attach those files here. This is the way how we use it now.
I also changed a bit of the design and added i.e. {*Signature*} where we add the signature in all our projects.
Furthermore I've commented out the following part because it is impossible to translate this fully properly (More information [here](https://lab.civicrm.org/dev/translation/-/issues/53)) so that it is not usable if you do not use CiviCRM in English:
`{*{ts}Thanks for your recurring contribution sign-up.{/ts}
{ts 1=$recur_frequency_interval 2=$recur_frequency_unit 3=$recur_installments}This recurring contribution will be automatically processed every %1 %2(s){/ts}{if $recur_installments } {ts 1=$recur_installments} for a total of %1 installment(s){/ts}{/if}.
{ts}Start Date{/ts}: {$recur_start_date|crmDate}*}`
I hope this issue helps you to solve those problems.
Thanks for all your efforts!
[contribution_recurring_notify_html.tpl](/uploads/4b1187ebcaa6978c2aa2cd483a3517bb/contribution_recurring_notify_html.tpl)
[contribution_recurring_notify_text.tpl](/uploads/f3da3f4f8c7291b4bae1dcba4df62b9e/contribution_recurring_notify_text.tpl)https://lab.civicrm.org/dev/core/-/issues/2244No options displayed for the "Financial Type" field on the "Find Contribution...2020-12-11T05:57:10ZalicefruminNo options displayed for the "Financial Type" field on the "Find Contributions" form for non AdministratorsOverview
----------------------------------------
IF you are logged in to CiviCRM with a role that is not the "Administrator" role but has permissions to administer CiviCRM and access civicontribute ("CiviContribute: access CiviContribut...Overview
----------------------------------------
IF you are logged in to CiviCRM with a role that is not the "Administrator" role but has permissions to administer CiviCRM and access civicontribute ("CiviContribute: access CiviContribute")
AND you go to the "Find Contributions" search form (ex: https://dmaster.demo.civicrm.org/civicrm/contribute/search?reset=1)
THEN no options are displayed in the dropdown for the "Financial Type" field see screenshot below:
![noneFound](/uploads/523d192bc5bd403f6056570a0159badf/noneFound.png)
This issue can be recreated on https://dmaster.demo.civicrm.org I believe it is a regression, it worked as expected in 5.28.3.
Reproduction steps
----------------------------------------
1. log in to CiviCRM with a role that is not the "Administrator" role but has permissions to administer CiviCRM and access civicontribute ("CiviContribute: access CiviContribute"). (perhaps the demo user on https://dmaster.demo.civicrm.org)
1. Go to CiviCRM Admin Menu -> Search -> Find Contributions (https://dmaster.demo.civicrm.org/civicrm/contribute/search?reset=1)
1. Click on the "Financial Types" dropdown
Current behaviour
----------------------------------------
No options
Expected behaviour
----------------------------------------
should display available Financial Types.
Comments
----------------------------------------
Caching may have some effect on this.5.32.2https://lab.civicrm.org/dev/translation/-/issues/60Add created_date column to the civicrm_note table2020-12-10T16:42:40ZjasonmAdd created_date column to the civicrm_note tableAfter merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It would be helpful for note records to store both the c...After merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It would be helpful for note records to store both the created date and the last modified date and to display both dates in the notes list view at /civicrm/contact/view?reset=1&cid=xxxxxx![screenshot-a](/uploads/02cf8a02bae6cf03df9764d7203355db/screenshot-a.png)
![screenshot-b](/uploads/08a903e82015e10103afbf5003b24961/screenshot-b.png)
![screenshot-c](/uploads/bd09d47c2cfe945b1a5beb048fbcbe02/screenshot-c.png)https://lab.civicrm.org/dev/core/-/issues/2242CiviCRM Export, Saved Export Field Mapping that contains custom fields which ...2021-02-01T22:03:53Zjustinfreeman (Agileware)CiviCRM Export, Saved Export Field Mapping that contains custom fields which have been disabled or deleted are still loaded as "clear" values and cause the export download to fail with "DB Error: no such field"CiviCRM Export, Saved Export Field Mapping that contains custom fields which have been disabled or deleted are still loaded as "clear" values and cause the export download to fail with "DB Error: no such field".
This is complicated furt...CiviCRM Export, Saved Export Field Mapping that contains custom fields which have been disabled or deleted are still loaded as "clear" values and cause the export download to fail with "DB Error: no such field".
This is complicated further because the **user cannot remove the "clear" fields from the field export list at all** and as a result, renders the Saved Export Field Mapping defunct.
The disabled or deleted fields are listed on the field export page as "clear", see screenshot below.
![Screenshot_20201210_165641](/uploads/099da3249d6eb3734fab60d6adaacf58/Screenshot_20201210_165641.png)
Agileware Ref: CIVICRM-16275.35.0https://lab.civicrm.org/dev/financial/-/issues/160Allocation of "fee amount" is incorrect if fee is added after contribution is...2020-12-11T17:11:37ZJonGoldAllocation of "fee amount" is incorrect if fee is added after contribution is created#### Steps to replicate:
* Go to **Administer » CiviContribute » Payment Methods**. Note the default payment method.
* Also note a payment method that doesn't have the same financial account.
On a clean install, "Check" is the default ...#### Steps to replicate:
* Go to **Administer » CiviContribute » Payment Methods**. Note the default payment method.
* Also note a payment method that doesn't have the same financial account.
On a clean install, "Check" is the default method, and "Credit Card" has a different financial account. I'll use those in my example below.
* Create a contribution with payment method of credit card. Enter a fee amount, save, and note the contribution ID.
* Run the following SQL to view the financial account IDs of the transaction (my contribution ID is 96 below):
```sql
mysql> SELECT entity_id, amount, from_financial_account_id, to_financial_account_id, total_amount, fee_amount FROM civicrm_entity_financial_trxn ceft JOIN civicrm_financial_trxn cft ON ceft.financial_trxn_id = cft.id WHERE entity_table = 'civicrm_contribution' AND entity_id = 96;
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| entity_id | amount | from_financial_account_id | to_financial_account_id | total_amount | fee_amount |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| 96 | 18.00 | NULL | 12 | 18.00 | 4.00 |
| 96 | 4.00 | 12 | 5 | 4.00 | 0.00 |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
```
* The above is correct - the `from_financial_account_id` of the fee trxn matches the `to_financial_account_id` of the main trxn.
* Create a second contribution with payment method of credit card, but do *not* enter the fee.
* Save the contribution, then immediately edit it to add the fee.
* When you run the SQL above, it will look like this:
```sql
mysql> SELECT entity_id, amount, from_financial_account_id, to_financial_account_id, total_amount, fee_amount FROM civicrm_entity_financial_trxn ceft JOIN civicrm_financial_trxn cft ON ceft.financial_trxn_id = cft.id WHERE entity_table = 'civicrm_contribution' AND entity_id = 95;
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| entity_id | amount | from_financial_account_id | to_financial_account_id | total_amount | fee_amount |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
| 95 | 11.00 | NULL | 12 | 11.00 | 0.00 |
| 95 | 3.00 | 6 | 5 | 3.00 | 0.00 |
+-----------+--------+---------------------------+-------------------------+--------------+------------+
```
Note that the fee's `from_financial_account_id` no longer matches the account of the main transaction - it matches the financial account ID of the **default** payment method, not the payment method of this contribution.
**tl;dr:** The financial transaction for a fee amount is calculated incorrectly if you edit the fee after the contribution is saved.
I haven't written a patch/test yet, but I intend to in the next day or two.5.34.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2239Make submitting of A/B mailing atomic2024-03-24T05:03:29ZromainMake submitting of A/B mailing atomicThe [API function that submits A/B mailings](https://github.com/civicrm/civicrm-core/blob/master/api/v3/MailingAB.php#L100) performs the following actions:
1. submits mailing A (= set scheduled date to now)
2. submits mailing B
3. di...The [API function that submits A/B mailings](https://github.com/civicrm/civicrm-core/blob/master/api/v3/MailingAB.php#L100) performs the following actions:
1. submits mailing A (= set scheduled date to now)
2. submits mailing B
3. distribute recipients between A and B
4. set status of the A/B mailing from Draft to Testing, regardless of what happened in previous steps
I can see 3 problems in this code:
- Recipients distribution happens after submitting mailing. So if we are unlucky (i.e. if a mailing job picks up the mailings right at that moment) the mailing sender can start sending the mailings before the distribution has happened
- None of the steps checks whether the earlier steps reported any error
- The change is not atomic: if an error happens, there is no attempt to undo the earlier steps
These problems can have various consequences, from my experience:
- The submitting works but setting the status fails: the A/B mailing is being sent but this has status Draft. Opening it will display a report but it will not be possible to pick the Final
- The submitting fails but setting the status works: the A/B mailing is not sent but has status Testing. Opening it will display the composer but it will not be possible to submit the mailing.
- In any of the previous cases, if the distribution worked fine any attempt to send again the mailing without precaution will cause the distribution to happen again, which means that recipients of mailing A will be reset to whole target group and mailing B and C will receive due percentage of that group, **without removing the recipients they already got in previous submit**, hence duplicate sendings. That one can be even worse when the error is a deadlock, and the query is retried.
I *think* that making all 4 steps happen in a single DB transaction would solve all the problems I mention here.
Would that be a good approach? If so, does it make sense to put the whole function in a transaction regardless of the target status, or shall the function be re-organised a bit to have the status setting done in the case statement and make only the `Testing` use case atomic?
With those answers, I'm happy to work on a PR.https://lab.civicrm.org/dev/core/-/issues/2238Improvement: custom search and a custom action list2021-12-01T10:00:13ZjaapjansmaImprovement: custom search and a custom action listAs a developer I sometimes write a custom search and sometimes I also need to ability to have a customized list of actions after the search and not the default list of actions possible with a contact.
So my proposal is that the custom ...As a developer I sometimes write a custom search and sometimes I also need to ability to have a customized list of actions after the search and not the default list of actions possible with a contact.
So my proposal is that the custom search class could set the `$objectType` for the `hook_civicrm_searchTasks`.
PR: https://github.com/civicrm/civicrm-core/pull/19143https://lab.civicrm.org/dev/core/-/issues/2236Running a Scheduled Job should imply runInNonProductionEnvironment=TRUE2020-12-07T21:19:44ZJonGoldRunning a Scheduled Job should imply runInNonProductionEnvironment=TRUErunInNonProductionEnvironment should really refer to whether a job should run *automatically* on a non-production environment. If someone is manually running a job, that's already a manual deviation from the normal procedure, so this ad...runInNonProductionEnvironment should really refer to whether a job should run *automatically* on a non-production environment. If someone is manually running a job, that's already a manual deviation from the normal procedure, so this additional step shouldn't be necessary.JonGoldJonGold