Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-04-29T05:03:20Zhttps://lab.civicrm.org/dev/core/-/issues/1854Bug When Restoring Overridden Status on Related Memberships2023-04-29T05:03:20ZCamilo RodríguezBug When Restoring Overridden Status on Related MembershipsOverview
----------------------------------------
Under certain special circumstances, once a main membership that has related memberships (eg. a membership held by an employer for a maximum number of employees), if the status is overrid...Overview
----------------------------------------
Under certain special circumstances, once a main membership that has related memberships (eg. a membership held by an employer for a maximum number of employees), if the status is overridden for a specific date, and the date has been met so that status for the main membership and its related memberships can now be calculated by the membership status calculation job, some of the related memberships may get deleted.
Reproduction steps
----------------------------------------
The specific conditions that need to be met are:
- Have an organization with a membership that has a maximum number of related memberships via a specific relationship (eg. 3 maximum related contacts with employee relationship).
- Have more contacts related to the organization that the maximum related memberships (eg 5)
- Distribute the memberships to the contacts so that the first created contact, and the last contacts have the related memberships.
- Give the main membership an overridden status for a date in the past.
Run membership status calculation job.
Current behaviour
----------------------------------------
Under this conditions, when the job is run, what will happen is the 3 memberships will be allocated to the first 3 contacts related to the organization. So if before the job was run, we had contacts with ID's 1001, 1002, 1003, 1004, 1005, and the three memberships were for contacts 1001, 1004 and 1005, when the job runs, the memberships will be given to contacts 1001, 1002 and 1003, and the memberships for 1004 and 1005 will be deleted. Furthermore, a fatal exception is thrown when the job is run.
![image](/uploads/ed7b1709c19662a72108c32591dd9ccb/image.png)
Expected behaviour
----------------------------------------
- Running the job should maintain the memberships to the contacts they've already been given to.
- The job should run and complete without failure.
Environment information
----------------------------------------
* __CiviCRM: 5.24.6
* __PHP: 7.2
* __CMS: Drupal 7.71
* __Database: MySQL 5.7
* __Web Server: Nginx
Comments
----------------------------------------
I have debugged the issue and found a fix. I will add the PR to the ticket once I have it up.https://lab.civicrm.org/dev/core/-/issues/1853Can't remove subtype if any required custom field is based on it2020-07-09T21:47:11ZsamuelsovCan't remove subtype if any required custom field is based on itTo reproduce :
- create a sub-type
- add custom group on the sub-type
- add custom field in this custom group that are required
- create a contact with the new sub-type and fill-in the required fields, submit
- try to remove the sub-type...To reproduce :
- create a sub-type
- add custom group on the sub-type
- add custom field in this custom group that are required
- create a contact with the new sub-type and fill-in the required fields, submit
- try to remove the sub-type and submit -> the form validation gives "required field" errors
![Peek_02-07-2020_11-27](/uploads/613b34e5a07102a8703c0ebc2fc8060a/Peek_02-07-2020_11-27.gif)https://lab.civicrm.org/dev/core/-/issues/1852The multi-lingual multi-domain problem2023-05-05T05:03:20ZcolemanwThe multi-lingual multi-domain problemBackground
-------
- In a multi-lingual install, the schema is changed to add columns for all translatable fields.
- One column is added per language.
- The list of languages is stored in `civicrm_domain.locales`
- For unknown historical...Background
-------
- In a multi-lingual install, the schema is changed to add columns for all translatable fields.
- One column is added per language.
- The list of languages is stored in `civicrm_domain.locales`
- For unknown historical reasons, `locales` was only populated for domain 1. It was thus treated as a "master domain" although there doesn't appear to be any documentation of this.
- So in a multi-domain setup, domain 2 would inherit its language settings from domain 1.
Problem
-------
- Having `civicrm_domain.locales` be populated for domain 1 but `null` for domain 2+ is confusing to devs and leads to crashes when relying on that value from the current domain.
- Bug reported in #1800
Proposed solution
-------
1. Ensure all domains have `locales` populated when enabling multilingual: https://github.com/civicrm/civicrm-core/pull/17733
2. An upgrade script to ensure `locales` is the same for all domains: https://github.com/civicrm/civicrm-core/pull/17738
Related issues/PRs
--------
- https://github.com/civicrm/civicrm-core/pull/17646
- https://github.com/civicrm/civicrm-core/pull/17733
- https://github.com/civicrm/civicrm-core/pull/17650
Tough questions
----------
Once the relatively easy stuff is solved by merging the fixes above, we might consider:
1. What happens if the admin desires one domain to be single-language and another to be multi?
2. When reverting from multi-lingual back to single, are all domains affected?
3. What if different multi-lingual domains want to support different languages?
4. Is all of the above completely unreasonable and multilingual settings should just always be the same across domains?https://lab.civicrm.org/dev/core/-/issues/1851State/Province Multi-select fails to save values2020-07-02T17:20:52ZhaystackState/Province Multi-select fails to save valuesOverview
----------------------------------------
A Custom Field of type State/Province Multi-select fails to save values when attached to an Event and "Is this Field Searchable?" is set to `false`. Reproduced on WPMaster and DMaster dem...Overview
----------------------------------------
A Custom Field of type State/Province Multi-select fails to save values when attached to an Event and "Is this Field Searchable?" is set to `false`. Reproduced on WPMaster and DMaster demo sites for a CiviEvent. I haven't checked if this is exclusive to Events, but can see the solution and will open a PR in due course.
Reproduction steps
----------------------------------------
1. Create a set of Custom Fields and attach to to "Event"
1. Add a field of data type "State/Province" and field type "Select State/Province"
1. Enable "Multi-Select" and disable "Is this Field Searchable?"
1. Visit a "Configure Event" page and select some "State/Province" values
1. Submit the form to save the event - State/Province" values are saved
1. Submit the form again to save the event - State/Province" values are lost
Current behaviour
----------------------------------------
Following the above procedure (line refs are for 5.26.2) throws the following warnings:
```
[02-Jul-2020 12:59:29 Europe/London] PHP Warning: explode() expects parameter 2 to be string, array given in /path/to/CRM/Core/BAO/CustomGroup.php on line 1383
[02-Jul-2020 12:59:29 Europe/London] PHP Warning: Invalid argument supplied for foreach() in /path/to/CRM/Core/BAO/CustomGroup.php on line 1384
```
The WPMaster and DMaster logs will show similar entries.
Expected behaviour
----------------------------------------
The incoming data should be parsed in the same way that [this commit](https://github.com/civicrm/civicrm-core/commit/fb56e9640b4380f2f76b72da2031d37e67165045#diff-d9f1be3fcfd7cea0a4864a21997c258aR1384-R1390) implements. Doing so fixes the problem.haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/1850Boot API/protocol for third-party modules should be upgrade-safe2023-04-14T05:03:25ZtottenBoot API/protocol for third-party modules should be upgrade-safeOverview
----------------------------------------
This is a generalized response to https://lab.civicrm.org/dev/core/-/issues/1846. 1846 is specific example (re:5.27 and woocommerce) of a class of a bug which has arisen with different v...Overview
----------------------------------------
This is a generalized response to https://lab.civicrm.org/dev/core/-/issues/1846. 1846 is specific example (re:5.27 and woocommerce) of a class of a bug which has arisen with different versions and different modules over the years.
Example use-case
----------------------------------------
1. Install CiviCRM version `$x`
2. Install a CMS plugin or module which uses CiviCRM (*In the above report, it was WooCommerce. In other reports, it's been Drupal Views. But it could be others.*)
3. Configure the plugin or module in a way that is pervasive on the system. (*Ex: It adds a block in the left-hand bar on every page, or it performs some logic whenever a user logs in, or it adds records to global menu/cache/data-structure.*)
4. Download the new code for CiviCRM version `$x+1`
5. Open the CMS/Civi web UI
6. Navigate to Civi's DB upgrade screen
The key issue for this use-case comes in at step 5. The plugin or module is active, and it is pervasive, and it needs to use Civi APIs. It probably calls `civicrm_initialize()` and then calls some service or data from Civi. But, we're in the middle of an upgrade process; the schema is out-of-date; even if you call `civicrm_initialize()`, one cannot guarantee that the system is actually working.
Current approach
----------------------------------------
The behavior depends on the details of the versions (`$x` vs `$x+1`) and of the customization. In many cases, things work fine - there's no pervasive customization, or the old+new DB schemas are "close enough".
But *sometimes* there are problems. This would be reported as an upgrade bug. ("I downloaded the latest version, and I can't run the upgrade, and things are crashy.") It cannot be reproduced in a clean environment - you have to install a customization and configure it suitably. Historically, the process has been like:
1. Attempt the upgrade on a real/complex site
2. Discover the problem
3. Either:
1. Identify and disable the customization; re-attempt the upgrade; re-enable the customization.
2. Report the issue; patch `civicrm-core` with a narrow work-around; and issue a point-release.
Either way, this is a reactive posture that leaves us systemically vulnerable to this class of issue and creates a poor impression. The key drivers (e.g. the list of third-party plugins; the list of upgrades; etc) are all open-ended. There is no simple, realistic, long-term verification protocol.
Analysis
----------------------------------------
For any module/plugin which needs to bootstrap Civi (e.g. `civicrm_initialize()`), there should be an explicit check/indication of whether Civi is in a working state.
As an example, suppose we have a Drupal module:
```php
// Show a block with a horosocope based on the logged-in user's date of birth
function horoscope_block_view($delta) {
if ($delta === 1) {
civicrm_intitialize();
$dob = civicrm_api3('Contact', 'getvalue', ['id' => '@user_contact_id', 'return' => 'birth_date']);
$msg = horoscope_lookup($dob);
return ['subject' => t('Horoscope'), 'content' => htmlentities($msg)];
}
}
```
I would submit that the problem here revolves around the contract for `civicrm_initialize()` - this caller has assumed that the post-condition of `civicrm_initialize()` is... to have an initialized Civi. But, if we're working toward a DB upgrade, then that condition cannot be met.
Proposed behavior
----------------------------------------
The correct thing is for this block to fail gracefully, e.g.
```php
// Show a block with a horosocope based on the logged-in user's date of birth
function horoscope_block_view($delta) {
if ($delta === 1) {
if (civicrm_intitialize() === 'partial') {
return ['subject' => t('Horoscope'), 'content' => t('We are having trouble communing with the astral spirits. Please upgrade Civi and come back later.')];
}
$dob = civicrm_api3('Contact', 'getvalue', ['id' => '@user_contact_id', 'return' => 'birth_date']);
$msg = horoscope_lookup($dob);
return ['subject' => t('Horoscope'), 'content' => htmlentities($msg)];
}
}
```
For this to work, Civi's side of the boot protocol has to provide information about how well it has booted. Here's a possible contract (*this is an incremental revision of the current; but it's possible something else is better*):
```php
/**
* @return bool|string
* FALSE: Indicates that Civi is not booted at all. For example, this may happen if it hasn't been installed.
* TRUE: Indicates that Civi is fully booted. You should expect most services to work.
* 'partial': Indicates that Civi may not be fully available. Most "application" should gracefully fail.
* However, some cases (eg `drush civicrm-upgrade-db`) might still continue with execution.
*/
function civicrm_initialize();
```
Comments
-----------
Addressing this would involve a few steps/phases:
1. Implement the updated boot protocol (e.g. patch `civicrm_initialize()`)
2. Update any bundled / widely-used / semi-official modules to be compliant
3. Update dev docs
4. Encourage other downstream authors to follow the protocolhttps://lab.civicrm.org/dev/core/-/issues/1849Smart Group search criteria cannot be saved if the pre-existing Smart Group s...2020-09-17T09:46:10Zjustinfreeman (Agileware)Smart Group search criteria cannot be saved if the pre-existing Smart Group search criteria returns no resultsSmart Group search criteria cannot be saved if the pre-existing Smart Group search criteria returns no results.
This is increasingly common since CiviCRM will now warn users about disabled/deleted custom fields and the related Smart Gro...Smart Group search criteria cannot be saved if the pre-existing Smart Group search criteria returns no results.
This is increasingly common since CiviCRM will now warn users about disabled/deleted custom fields and the related Smart Group that need to be updated. The user is then stuck and unable to action the warning notice displayed by CiviCRM.
![chrome_aphUhSKcqb](/uploads/8c9ec177e1eacbb9ca6183e1e15beb2f/chrome_aphUhSKcqb.png)
A workaround to the problem is to manually add a contact to the Smart Group and then the ability to update the Smart Group via Actions becomes available. Or to change the search criteria so that it does return results - even if those results do not match the purpose of the Smart Group. These workarounds are not obvious to end-users.
It would be preferable for the action to update the Smart Group criteria was available even if no search results were returned by the current search, allowing the user to save the search criteria. This gives the future ability for contacts that match the search criteria to populate the group.
![chrome_DIjHo5MOpZ](/uploads/fac7cbc7901cf1088ed9f3adb98ca860/chrome_DIjHo5MOpZ.png)
Relates to https://lab.civicrm.org/dev/core/-/issues/1471
Agileware Ref: CIVICRM-1509https://lab.civicrm.org/dev/core/-/issues/1848Importing subtype-specific data to existing contacts loses their other subtypes2023-03-30T11:33:47ZAndrew WestImporting subtype-specific data to existing contacts loses their other subtypesI just tried to import subtype-specific data for existing contacts, and their other subtypes went away. To recreate on demo:
1. Find a contact and set them to the 'Student' contact type
2. Note their contact ID
3. Find a custom field in...I just tried to import subtype-specific data for existing contacts, and their other subtypes went away. To recreate on demo:
1. Find a contact and set them to the 'Student' contact type
2. Note their contact ID
3. Find a custom field in a different subtype and pick a random value. Demo currently has 'Camera Skill Level' on the 'Volunteer', with possible values 1-5
4. Create a CSV with an ID column and a Camera Skill level column:
![Annotation_2020-07-01_185424](/uploads/974250d6b8ade278011a2602ebb18f00/Annotation_2020-07-01_185424.png)
5. Import this CSV, setting Subtype to 'Volunteer', and 'Update'
![Annotation_2020-07-01_184535](/uploads/37f1551623f0a2c5e1cd0aedc27e7027/Annotation_2020-07-01_184535.png)
6. Map the fields appropriately:
![Annotation_2020-07-01_184635](/uploads/8cebdc8c99a7db9a3f199369e59560e1/Annotation_2020-07-01_184635.png)
7. Check the original contact - they are now marked as 'Volunteer' and no longer Student.
This happens no matter whether the contact has the subtype originally - ie. if you are importing data with the purpose of inherently adding this subtype, or if it's already there.https://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/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)