Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-04-15T22:11:29Zhttps://lab.civicrm.org/dev/core/-/issues/1845civicrm_saved_search FK in civicrm_group should be ON DELETE CACSCADE2021-04-15T22:11:29ZMichael McAndrewcivicrm_saved_search FK in civicrm_group should be ON DELETE CACSCADEThe foreign key in civicrm_group
```
CONSTRAINT `FK_civicrm_group_saved_search_id` FOREIGN KEY (`saved_search_id`) REFERENCES `civicrm_saved_search` (`id`) ON DELETE SET NULL
```
is `ON DELETE SET NULL` which assumes that there is a us...The foreign key in civicrm_group
```
CONSTRAINT `FK_civicrm_group_saved_search_id` FOREIGN KEY (`saved_search_id`) REFERENCES `civicrm_saved_search` (`id`) ON DELETE SET NULL
```
is `ON DELETE SET NULL` which assumes that there is a use for a saved search that was linked to a group even when that group is deleted. I don't think this is the case. I think it should be `ON DELETE CACSCADE`.
Does this seem reasonable to people? If people agree, I can add a couple of lines to the upgrade script.
I came across this while investigating the following warning: [![enter image description here][1]][1]
[1]: https://i.stack.imgur.com/JKouq.png5.37.0https://lab.civicrm.org/dev/core/-/issues/1844Noncompliant query leads to (semi-)random sorting and failing unit test CRM_C...2023-04-24T05:03:24ZDaveDNoncompliant query leads to (semi-)random sorting and failing unit test CRM_Case_BAO_CaseTest::testSortByCaseContactThis doesn't seem to come up on any commonly used screens but something has changed recently, either in mysql on the test sites or somewhere else, that is exposing a problem that has always been there in the query described at https://gi...This doesn't seem to come up on any commonly used screens but something has changed recently, either in mysql on the test sites or somewhere else, that is exposing a problem that has always been there in the query described at https://github.com/civicrm/civicrm-core/pull/17702#issuecomment-650777728 with regards to full-groupby. See also https://github.com/civicrm/civicrm-core/pull/17705.
At the moment it just seems to be causing CRM_Case_BAO_CaseTest::testSortByCaseContact to fail on every PR. I did some r-runs on one of the recent test sites for case dashboard/dashlet/find cases etc, and didn't see any (new) problems.https://lab.civicrm.org/dev/core/-/issues/1843Url-tracking in mass sms2020-08-03T00:07:11ZdmunioUrl-tracking in mass smsOverview
----------------------------------------
If a mass sms is sent with a url in the message, when sending the sms a url-tracking is added. This affects the length of the sms and also, there are no sms tracking reports.
Reproductio...Overview
----------------------------------------
If a mass sms is sent with a url in the message, when sending the sms a url-tracking is added. This affects the length of the sms and also, there are no sms tracking reports.
Reproduction steps
----------------------------------------
1. New mass sms
2. Add url in the sms message.
3. Preview sms with url-tracking
![image](/uploads/8124f67212f608522c7b260185fa306b/image.png)5.29.0https://lab.civicrm.org/dev/core/-/issues/1842Brief Description of Work Done during First Month of GSoC Project- Probots an...2022-06-24T03:30:58Zkartik1000Brief Description of Work Done during First Month of GSoC Project- Probots and GitLab to GitHub IntegrationHey All, I am Kartik and I had been selected for the GSoC Project Probots and Gitlab to GitHub Integration and so far I have completed 1 month of this project out of 3 months and I would like to share with the CiviCRM Community of the wo...Hey All, I am Kartik and I had been selected for the GSoC Project Probots and Gitlab to GitHub Integration and so far I have completed 1 month of this project out of 3 months and I would like to share with the CiviCRM Community of the work-done during this project. For more info. regarding project details, you can refer here https://civicrm.org/blog/kartik1000/gsoc-project-probots-and-gitlab-github-integration.
So, to begin with, one of the issues I faced, in the beginning, was how to test the working of the civi-bot that already exists in civi-core by adding more code to it related to issues I aimed to solve. So, with much discussion with @eileen and Saurabh, we decided to create a dev-bot from the forked repo of [probot-civicrm](https://github.com/civicrm/probot-civicrm) and use it for our purposes of testing. The code-repo for the same bot is present [here](https://github.com/kartik1000/civicrmdev-bot) with different issues I solved existing as different merged branches. Another issue I faced in setting up the dev-bot was hosting the bot. For the bot to be active always, we need to host it as a node-js application, the most suitable option for which are Heroku and glitch. For the simplicity of the glitch, I decided to use it for my purpose. The other issue that I faced was to keep the bot always active for that either one can use the ping method every 5 minutes or use the service of [uptime robot](https://uptimerobot.com/).
- The first issue I decided to complete was to make sure that we issue newcomer's message and information only to the new contributor and not keep posting the same message to every contributor. For this, I added simple logic of checking how many PRs have been made by the contributor, if the count is 1 then issue newcomer's message. It just required to fetch this information using the existing GitHub APIs. For the same reasons, I had to modify our existing template as well. The reviewing standards will be posted on every PR irrespective of it being a new contributor or not.
![Screenshot_2020-06-26_at_5.22.20_PM](/uploads/4f509c7f5511a91509d58084ba5fbb16/Screenshot_2020-06-26_at_5.22.20_PM.png)
This is an example of how a PR created by a new contributor looks like after making the required changes.
- The second issue I worked on is to merge the existing [stale-bot](https://probot.github.io/apps/stale/) with the existing civi-bot. Stale-bot closes PRs and issues which have been inactive for some time. It first labels PR as stale/wontfix and then after some-time, if the PR is still in-active then it closes the PR. This task was not too difficult as well since the entire open-source repo for the stale-bot already exists but since it is old many of its functions were depreciated and needed to be updated from the GitHub APIs and few other modifications were required. So, this task was also accomplished and tested as well.
![Screenshot_2020-06-26_at_5.36.20_PM](/uploads/05ecaa068e50f2e0ed89e43ddb68e81b/Screenshot_2020-06-26_at_5.36.20_PM.png)![Screenshot_2020-06-26_at_5.36.38_PM](/uploads/33aa7124ae2fd7757fa49cc723564f20/Screenshot_2020-06-26_at_5.36.38_PM.png)
Till now I have learnt a lot of new things from this project especially how powerful the GitHub APIs are which allow the user to receive almost any information regarding their repository. In the upcoming months, I hope to learn even more new things.
The entire code for the civicrmdev-bot is present in this [repository](https://github.com/kartik1000/civicrmdev-bot).
We plan to merge these features in the existing civi-bot in some time so that they can be used in CiviCRM-core.
I request to all the community members if you have any ideas or thoughts on what other things I can do to automate our workflow during the remaining project, please comment them on this issue and thanks to all!https://lab.civicrm.org/dev/core/-/issues/1841[regression] Attempting to access Multi-Record Custom Field import results in...2020-07-01T02:11:20ZJonGold[regression] Attempting to access Multi-Record Custom Field import results in crash## To replicate
* You must start with a site where you've never visited this screen before (a demo site works well).
* Go to **Contacts » Import Contacts**.
* Click the **help** icon in the instructions (see screenshot item 1)
* Click th...## To replicate
* You must start with a site where you've never visited this screen before (a demo site works well).
* Go to **Contacts » Import Contacts**.
* Click the **help** icon in the instructions (see screenshot item 1)
* Click the **more** link in the help to access the Import Multi-Record Custom Value screen (see screenshot item 2).
![Selection_947](/uploads/95b8fb2da66f267362c4600bf6fa900d/Selection_947.png)
## Observed Result
An exception: `'Import Multi value custom data' is not a valid option for field mapping_type_id`.
## Expected result
The page loads.
## Notes
I believe this is a variant of the regression fixed in #1816. When translating a pseudoconstant to an ID when passing an API param, we now check the string against the `name` and not the `label`. This makes good sense, but `CRM_Core_BAO_Mapping::getCreateMappingValues()` creates the "Import Multi value custom data" Mapping record with a label that doesn't match the name - so a function that previously looked up the label is crashing with the exception above.
I solve this by explicitly setting the `name` field. Much as I'd like to have solved this by changing the search criteria, it's constructed programmatically in a way that would require a change to all the `name`s of existing Mapping Type option values, since they have spaces in them (boo!). This is the much safer fix.
Also, testing this only required one line of code! :)
## Backtrace
```
#0 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/BAO/Mapping.php(105): civicrm_api3("Mapping", "get", (Array:4))
#1 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/BAO/Mapping.php(157): CRM_Core_BAO_Mapping::getMappings("Import Multi value custom data")
#2 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Import/Form/DataSource.php(66): CRM_Core_BAO_Mapping::getCreateMappingValues("Import Multi value custom data")
#3 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Custom/Import/Form/DataSource.php(54): CRM_Import_Form_DataSource->buildQuickForm()
#4 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Form.php(609): CRM_Custom_Import_Form_DataSource->buildQuickForm()
#5 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Display.php(76): CRM_Core_Form->buildForm()
#6 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Custom_Import_Form_DataSource), "display")
#7 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Custom_Import_Form_DataSource), "display")
#8 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Controller.php(347): HTML_QuickForm_Page->handle("display")
#9 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(312): CRM_Core_Controller->run((Array:3), NULL)
#10 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:14))
#11 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#12 /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/drupal/civicrm.module(456): CRM_Core_Invoke::invoke((Array:3))
#13 /home/jon/local/civicrm-buildkit/build/dmaster/web/includes/menu.inc(527): civicrm_invoke("import", "custom")
#14 /home/jon/local/civicrm-buildkit/build/dmaster/web/index.php(21): menu_execute_active_handler()
#15 {main}
```5.27.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3350Event registration form has inconsistent labelling2022-04-22T16:21:16ZJonGoldEvent registration form has inconsistent labellingFollowing on from core#1613 - [PR 16651](https://github.com/civicrm/civicrm-core/pull/16651) updated the button text but nor corresponding instructions.
Hat tip to Bryan for discovering this and [posting on Stack Exchange](https://civic...Following on from core#1613 - [PR 16651](https://github.com/civicrm/civicrm-core/pull/16651) updated the button text but nor corresponding instructions.
Hat tip to Bryan for discovering this and [posting on Stack Exchange](https://civicrm.stackexchange.com/questions/35964/misleading-instructions-in-civievent-registration-template-for-multiple-particip).
https://github.com/civicrm/civicrm-core/pull/176955.29.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/139Define the logic that sets (or not) contribution receive_date in relation to ...2020-09-03T19:54:46ZRichDefine the logic that sets (or not) contribution receive_date in relation to paymentsWe discovered that Payment.create that completed a contribution was having a side-effect of updating the contribution's `receive_date` to today's date.
The PR at https://github.com/civicrm/civicrm-core/pull/17688 corrected that by ensur...We discovered that Payment.create that completed a contribution was having a side-effect of updating the contribution's `receive_date` to today's date.
The PR at https://github.com/civicrm/civicrm-core/pull/17688 corrected that by ensuring the payment's date is properly passed through into the underlying BAO code that does the updates and now tests that the `receive_date` is set to the `trxn_date` of the new payment.
However it raised questions: why *should* a payment update the contribution's `receive_date`?
Rather than hold up a PR which was around fixing a definitely-not-what-we-want behaviour, we started this issue to have the discussion. It is referenced in the docblock of the new test in tests/phpunit/api/v3/PaymentTest.php called `testPaymentCreateTrxnIdAndDates`
Before we jump in about one field, let's consider the whole picture (which I may or may not describe properly here)
1. A contribution is created in Pending state, which generates:
- a contribution record, which has a `receive_date`, but also `revenue_recognition_date` (and less importantly: cancel, receipt and thankyou dates)
- a "financial item" for each line item. This has a `transaction_date` field, as well as a `create_date` field.
- depending on config (and [possible bugs](https://lab.civicrm.org/dev/financial/-/issues/138)), a financial transaction record transferring the total amount from the line items' financial types' configured income accounts to Accounts Receivable account, and this table (`civicrm_financial_trxn`) has a `trxn_date` field.
2. A contribution may receive various "payments" (in API speak, but it's really about financial transactions). Typically this represents the full payment for the whole contribution, and in which case it "completes" the contribution. But it also seems to cover various changes, cancellations, refunds, partial payments... For the 90% case where it completes the contribution, this generate:
- a(nother) `civicrm_financial_trxn` row which has a `trxn_date`, and transferrs the funds into (Dr) the payment instrument's configured account from (Cr) the Accounts Receivable account.
- Currently, it will update the `receive_date` for the contribution, too.
So, dates-wise we have:
|Reference | date | observed current behaviour |
|----|-------| -------|
|➊ | contribution `receive_date` | Shown in lists. Create date, then updated. |
|➋| contribution `revenue_recognition_date` | NULL - don't know when/if this gets set |
|➌| financial item 1's `create_date` | Date contribution was created |
|➍| financial item 1's `transaction_date` | Date completing (or latest?) payment made |
|➎| financial trxn 1's `trxn_date` | Could not observe; is not created (think this is a bug see link above) |
|➏| financial trxn 2's `trxn_date` | Date of the completing payment |
I can see that there are situations where it makes sense to update the receive date: for most payments that are made in a single lump, it's probably the most important date: when did we get the money (not just the promise/hope/intent of money)? But as soon as you get into partial payments, refunds etc. then that's only going to be an approximation.
CiviContribute sets up pending contributions willy-nilly which can also represent abandoned baskets, but there's the case when this is set up before midnight and the payment comes a minute later but after midnight. Direct Debit processors may set them up for future payments, or initial payments, but the receive dates may differ due to local banking rules (e.g. bank/public holidays, lack of funds...).
So, what should we do? Leave `receive_date` alone instead of updating it to the completion date? Do the other dates have enough exposure to do this (ie. is it clear to users what the dates mean)? Set it as the date the first funds were received? The latest funds (completing or not) received? Do we update it for cancelled/refunded/partially refunded?
Enjoy the discussion! (not sure if I need to @ people about this, but in case I do, here's an incomplete list: @eileen @JoeMurray @mattwire @KarinG )https://lab.civicrm.org/dev/core/-/issues/1840Can't change SMS recipient on non-bulk SMS2020-06-25T12:36:53ZJonGoldCan't change SMS recipient on non-bulk SMSTo replicate:
* Set up any SMS provider.
* Have/create at least two contacts with a mobile number.
* Go to that contact, select "Outbound SMS" from the action menu.
If you send the SMS at this point, everything is good. However:
* Try ...To replicate:
* Set up any SMS provider.
* Have/create at least two contacts with a mobile number.
* Go to that contact, select "Outbound SMS" from the action menu.
If you send the SMS at this point, everything is good. However:
* Try adding a second contact. Or removing and re-adding the first contact.
Now, if you try sending, you get an exception:
```
CRM_Core_Exception: One of parameters (value: "Lastname) is not of the type Positive
```
Why:
The AJAX that powers the contact selection widget here, `CRM_Contact_Page_AJAX::getContactPhone()` returns the data in one of two formats, depending on whether you pass in an `id = TRUE` parameter. The JS here doesn't, but it should - otherwise the contact name/phone comes back in the wrong format.5.28.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1839Notice error Contribution Aggregate by Relationship report2023-03-29T05:03:21ZJoeMurrayNotice error Contribution Aggregate by Relationship reportOn dmaster just now (5.28.alpha1):
Notice: Undefined variable: entryFound in CRM_Report_Form_Contribute_History->alterDisplay() (line 842 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Report/Form/Contribute/History.php).On dmaster just now (5.28.alpha1):
Notice: Undefined variable: entryFound in CRM_Report_Form_Contribute_History->alterDisplay() (line 842 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Report/Form/Contribute/History.php).https://lab.civicrm.org/dev/core/-/issues/1838Error when viewing contact merged to permanently deleted contact2021-03-31T04:04:03ZandrewcormickdockeryError when viewing contact merged to permanently deleted contactAn error appears if you try to view a contact which has been merged to another contact which subsequently got permanently deleted.
To reproduce:
1. Create first contact
2. Create second contact
3. Merge 2nd contact into 1st contact
4. ...An error appears if you try to view a contact which has been merged to another contact which subsequently got permanently deleted.
To reproduce:
1. Create first contact
2. Create second contact
3. Merge 2nd contact into 1st contact
4. Permanently delete 1st contact
5. View 2nd contact
Result: Error is printed: "Expected one ActivityContact but found 0". User cannot view contact.
Expect: Be able to view the 2nd contact, which is in the trash, but not permanently deleted.https://lab.civicrm.org/dev/core/-/issues/1837Civicrm settings still require group for mandatory overrides???2023-03-29T05:03:21ZeileenCivicrm settings still require group for mandatory overrides???Our docs say group & groupname are fully deprecated here
https://docs.civicrm.org/dev/en/latest/framework/setting/
but they are still documented as being required for overrides in civicrm.settings.php & I *think* they are still needed ...Our docs say group & groupname are fully deprecated here
https://docs.civicrm.org/dev/en/latest/framework/setting/
but they are still documented as being required for overrides in civicrm.settings.php & I *think* they are still needed if doing an override here
https://docs.civicrm.org/sysadmin/en/latest/customize/settings/
@totten you can probably confirm....
Perhaps it's just
```
$civicrm_setting['antyhing works here ']['customFileUploadDir'] = '/var/www/testing/sites/default/files/civicrm/upload';
```
@ejegghttps://lab.civicrm.org/dev/core/-/issues/1836Scheduled Reminders "Additional Recipients" feature sends at wrong time, is i...2023-06-19T04:43:34ZJonGoldScheduled Reminders "Additional Recipients" feature sends at wrong time, is incompatible with tokens## Steps to replicate
* Create a new event.
* Create a scheduled reminder for the event. Include event tokens in the message.
* Trigger the scheduled reminder.
## Expected result
The email is received at the correct time with the even...## Steps to replicate
* Create a new event.
* Create a scheduled reminder for the event. Include event tokens in the message.
* Trigger the scheduled reminder.
## Expected result
The email is received at the correct time with the event tokens filled in.
## Actual result
Email sends the first time "Send Scheduled Reminders" is triggered; event tokens are missing.
## Overview
When a Scheduled Reminder triggers an email, it writes the contact ID, entity ID and entity table to `civicrm_action_log`. When the recipient is an "additional recipient", instead of writing the entity ID and table, it writes the contact ID (again) and `civicrm_contact` for the table.
On one level, this makes sense - e.g. an additional recipient for an event doesn't have a participant record we can draw on. However, it means that the recipient's email isn't tied to the event, so it a) sends at the wrong time since it doesn't have access to the `start_date`, b) tokens don't work, because there's no indication which event the email is in relationship to.
## Technical Notes
`CRM_Core_BAO_ActionSchedule::prepareMailingQuery()` thinks that `civicrm_action_log.entity_id` refers to the participant ID. However, `Civi\ActionSchedule\RecipientBuilder::buildAddlFirstPass()` calls `$this->selectActionLogFields()`, which ALWAYS writes the entity_table/entity_id as `civicrm_contact` and the contact ID when building an additional pass.
As a result, the tokens are resolved for the wrong participant ID.
I'm going to take an initial pass at this but I'm not sure how far I'll get. My strategy:
* Modify the add'l recipient SQL that inserts a record in civicrm_action_log to use the correct entity, not the contact entity.
* As a special case, events should store the event entity, not the participant entity.
* Target the Symfony event that modifies the SQL statement for events to handle event additional participants as a special case.5.50.0JonGoldJonGoldhttps://lab.civicrm.org/dev/financial/-/issues/138Broken bookkeeping records: no financial trxn from Accounts Receivable to rev...2020-06-29T04:05:27ZRichBroken bookkeeping records: no financial trxn from Accounts Receivable to revenue account.According to the [docs](https://docs.civicrm.org/dev/en/latest/financial/financialentities/), when a Pending Order is created it's supposed to create a financial trxn transferring the total sum to accounts receivable. I'm not seeing this...According to the [docs](https://docs.civicrm.org/dev/en/latest/financial/financialentities/), when a Pending Order is created it's supposed to create a financial trxn transferring the total sum to accounts receivable. I'm not seeing this happening.
@JoeMurray [pointed out](https://chat.civicrm.org/civicrm/pl/zs556c7xqjdtjciry8qnipw7rc) that *There's a setting in CiviContribute Compnent Settings now which iirc disables this by default.*
And @eileen suggested that the default should be the other way around.
But even with this turned ON, the trxn is not created.
```bash
# Set this to a contact that exists:
CID=202
cv api Order.create financial_type_id=Donation contact_id=$CID contribution_status_id=Pending \
total_amount=30 receive_date=2020-05-29\ 15:30:00
```
At this point we would expect (according to my understanding) to see:
- ✔ 1 contribution record.
- ✔ 1 line item: directly linked to the contribution.
- ✔ 1 financial item, linked to the line item, which specifies the CREDIT financial account (*Donation*) and status 3 (pending).
- ✖ 1 financial trxn:
- `from_account` (the CREDIT): The revenue (income) account for the *Donation* financial type.
- `to_account` (the DEBIT): Accounts Receiveable
- ✖ related entity financial trxn records
Without this we end up with bookkeeping problems:
- all financial trxns come *from* Accounts Recievable, but there's nothing going *to* Accounts Receivable.
- there are no bookkeeping transactions for the revenue accounts.
- So you get info like "some money went into your bank" but not "a donation went into your bank".JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/wordpress/-/issues/61undefined offset bug in BAO/FinancialAccount.php2020-07-05T22:25:14Zrgrosundefined offset bug in BAO/FinancialAccount.phpwhile dealing with a white screen, I found a suspicious message in php_errorlog. In debugging that, I think I hit a bug.
- civicrm 5.26.2
- wordpress
In the logging, I see this line:
`[22-Jun-2020 16:58:39 Europe/Amsterdam] PHP Notic...while dealing with a white screen, I found a suspicious message in php_errorlog. In debugging that, I think I hit a bug.
- civicrm 5.26.2
- wordpress
In the logging, I see this line:
`[22-Jun-2020 16:58:39 Europe/Amsterdam] PHP Notice: Undefined offset: 0 in /home/user/public_html/civicrm-nw/wp-content/plugins/civicrm/civicrm/CRM/Financial/BAO/FinancialAccount.php on line 255`
This notice is triggered by doing a payment after registering for a paid event.
The line that is mentioned in the notice is in function *getFinancialAccountForFinancialTypeByRelationship*; I put in some print statements and found out that it gets value 'Income Account is' in parameter *$relationshipType*. The line of the message uses the hard coded value instead:
`$incomeAccountRelationshipID = array_search('Income Account is', $accountRelationships);`
which is suspicious in itself. But the array $accountRelationships does not contain that value, which causes the message. The array appears to contain the dutch equivalents of the relationships:
```
LOC103 Array
(
[1] => Inkomsten rekening is
[2] => Credit/Contra Revenue Account is
....more
}
```
I am no php programmer, so I fixed it for my site by changing the hard code value to 'Inkomsten rekening is', making the message disappear. I think the code should be changed to somethink like
`$incomeAccountRelationshipID = array_search(translation_of ($relationshipType), $accountRelationships);`5.28.0https://lab.civicrm.org/dev/core/-/issues/1835Export preview not showing data that exists2023-03-28T05:03:44ZStoobExport preview not showing data that existsIn both of these attached cases, the data exists in CiviCRM, and the data is contained in the CSV downloaded upon export. But it is blank in the preview.
![preview](/uploads/82c5b38bb88effd5bb67b6842470111c/preview.png)
![export](/upl...In both of these attached cases, the data exists in CiviCRM, and the data is contained in the CSV downloaded upon export. But it is blank in the preview.
![preview](/uploads/82c5b38bb88effd5bb67b6842470111c/preview.png)
![export](/uploads/a2e1ee8affbeaff3d1377572b080b7f2/export.png)https://lab.civicrm.org/dev/core/-/issues/1834End date default set on Find Contributions to 12:00am eliminates contribution...2020-09-05T21:20:45ZStoobEnd date default set on Find Contributions to 12:00am eliminates contributions made todayUsing the Current Month-to-Date link from the Contribution page the default time is set to 12:00am. This eliminates any contributions "made today". The end time should probably be 11:59pm today, or the next day at 12:00am.
`https://dm...Using the Current Month-to-Date link from the Contribution page the default time is set to 12:00am. This eliminates any contributions "made today". The end time should probably be 11:59pm today, or the next day at 12:00am.
`https://dmaster.demo.civicrm.org/civicrm/contribute/search?reset=1&contribution_page_id=1&force=1&test=0&receive_date_low=20200601&receive_date_high=20200622`
![bunnbuad](/uploads/68779d57eaec0a43b8c8a4a7b77ac472/bunnbuad.png)
![curm](/uploads/0b073ab580660694f99808111fb18a7d/curm.png)`https://lab.civicrm.org/dev/wordpress/-/issues/60Conflict between theme and Stripe?2020-06-22T12:48:53ZaskeggConflict between theme and Stripe?We are running CiviCRM 5.26.2 with the latest extensions, including Stripe. While attempting to submit a credit card payment using the Stripe gateway nothing happens. The Safari console reports:
`Error: No reCAPTCHA clients exist.`
![S...We are running CiviCRM 5.26.2 with the latest extensions, including Stripe. While attempting to submit a credit card payment using the Stripe gateway nothing happens. The Safari console reports:
`Error: No reCAPTCHA clients exist.`
![Screen_Shot_2020-06-22_at_8.05.06_pm](/uploads/004ca370138250a71333217859b8f1fd/Screen_Shot_2020-06-22_at_8.05.06_pm.png)
I have tried disabling the reCAPTCHA in both the theme and CiviCRM, and every other combination, but nothing makes this error disappear.
Any ideas?https://lab.civicrm.org/dev/core/-/issues/1833Event participant_listing_id field defaults to 0 instead of Null2020-06-29T04:27:09ZananelsonEvent participant_listing_id field defaults to 0 instead of NullOverview
----------------------------------------
When creating a new Event via the API, without specifying participant_listing_id, it defaults to a value of 0. However, 0 is not a valid value. The correct default should be Null. The 0 v...Overview
----------------------------------------
When creating a new Event via the API, without specifying participant_listing_id, it defaults to a value of 0. However, 0 is not a valid value. The correct default should be Null. The 0 value results in an error when subsequently accessing the record.
Workaround: call the Event.create API explicitly passing participant_listing_id => null
Current behaviour
----------------------------------------
Database ends up with a value of 0 when new record is created.
Expected behaviour
----------------------------------------
Database ends up with a value of NULL when new record is created.
Environment information
----------------------------------------
* __CiviCRM:__ _5.26.1_5.28.0https://lab.civicrm.org/dev/financial/-/issues/137Billing Address params on propertyBag2020-09-14T16:45:36Zmattwiremjw@mjwconsult.co.ukBilling Address params on propertyBagWe currently have a set of `billingXxx` fields on propertyBag but they have no mappings to what actually gets passed in.
Because of `CRM_Core_Form::prepareParamsForPaymentProcessor` we can be pretty certain that fields will be available ...We currently have a set of `billingXxx` fields on propertyBag but they have no mappings to what actually gets passed in.
Because of `CRM_Core_Form::prepareParamsForPaymentProcessor` we can be pretty certain that fields will be available in the format without the `billing_` prefix.
But the mapping is still not completely clear:
```
'billingStreetAddress' => TRUE,
'street_address' => 'billingStreetAddress',
'billingSupplementalAddress1' => TRUE,
'billingSupplementalAddress2' => TRUE,
'billingSupplementalAddress3' => TRUE,
'billingCity' => TRUE,
'city' => 'billingCity',
'billingPostalCode' => TRUE,
'postal_code' => 'billingPostalCode',
'billingCounty' => TRUE,
'state_province' => 'billingCounty',
'billingCountry' => TRUE,
'country' => 'billingCountry',
```
In particular:
1) "County" has various meanings and we should probably standardise on `stateProvince` with `County` being the next level down.
2) Should the params be prefixed with `billingXxx` at all in propertyBag? Or `addressXxx` or just `xxx`.
3) Do we need the supplementalAddress params at all - I don't think anything (payments) uses them?
Ping @eileen @artfulrobot @KarinGhttps://lab.civicrm.org/dev/core/-/issues/1832Activity receive_date is incorrectly updated to now when importing historical...2024-01-08T04:07:40ZananelsonActivity receive_date is incorrectly updated to now when importing historical transactionsContribution receive_date is incorrectly updated to now when importing historical transactions, see #1831 for more context.
Adding this line to addActivity() in `CRM/Activity/BAO/Activity.php` seems to fix:
```$date = CRM_Utils_Date::i...Contribution receive_date is incorrectly updated to now when importing historical transactions, see #1831 for more context.
Adding this line to addActivity() in `CRM/Activity/BAO/Activity.php` seems to fix:
```$date = CRM_Utils_Date::isoToMysql($activity->register_date);```
https://github.com/civicrm/civicrm-core/blob/master/CRM/Activity/BAO/Activity.php#L1708