Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-09-05T13:38:55Zhttps://lab.civicrm.org/dev/core/-/issues/1890Remove `ufUniqID` from Core2023-09-05T13:38:55ZhaystackRemove `ufUniqID` from CoreI'm auditing the `synchronize()` procedure with the aim of rationalising what happens during page loads in WordPress - due to reports of multiple Contacts being created (see [this Mattermost thread](https://chat.civicrm.org/civicrm/pl/iu...I'm auditing the `synchronize()` procedure with the aim of rationalising what happens during page loads in WordPress - due to reports of multiple Contacts being created (see [this Mattermost thread](https://chat.civicrm.org/civicrm/pl/iurq3k4pkj8mpbxmb7kttyg5xo) for example) and have found that the `ufUniqID` session variable is only ever *set* and never *read* in CiviCRM.
It is set in Core in:
* `CRM_Core_BAO_UFMatch::synchronize()` [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/UFMatch.php#L96) and [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/UFMatch.php#L128)
And in CiviCRM WordPress by the REST API (presumably for consistency with Core) in:
* `CiviCRM_WP_REST\Civi\Mailing_Hooks\Plugin::set_civi_user_session()` [here](https://github.com/civicrm/civicrm-wordpress/blob/7fc81f0289d63dd6577d7e7046303cc6dc850f8f/wp-rest/Plugin.php#L355)
Can we remove it since it's never actually used?5.29.0https://lab.civicrm.org/dev/core/-/issues/1883Preferred Language in a profile doesn't show/behave as required when so confi...2020-09-25T20:11:30ZAlanDixonPreferred Language in a profile doesn't show/behave as required when so configuredI've got a multilingual CiviCRM/Drupal (5.24.6/7.x) with a profile that includes the (core) field preferred_language.
Setting it as required in the profile web interface does not mark the field as required, and also does not apply the d...I've got a multilingual CiviCRM/Drupal (5.24.6/7.x) with a profile that includes the (core) field preferred_language.
Setting it as required in the profile web interface does not mark the field as required, and also does not apply the desired functionality.
I'd guess it's something missing in this file: https://lab.civicrm.org/dev/core/-/blob/master/CRM/Core/BAO/UFGroup.php
I did a quick test on a separate Drupal 8 install and observed the same issue.
Clues or suggestions welcome.5.31.0https://lab.civicrm.org/dev/core/-/issues/1879.ical files not populating correctly for sites with ACL's configured for events2020-10-30T22:36:11Zalicefrumin.ical files not populating correctly for sites with ACL's configured for eventsOverview
----------------------------------------
The iCal files for events are not populating correctly for sites that have ACLs for events set up.
Reproduction steps
----------------------------------------
1. Create 2 events A and B
...Overview
----------------------------------------
The iCal files for events are not populating correctly for sites that have ACLs for events set up.
Reproduction steps
----------------------------------------
1. Create 2 events A and B
1. Create an ACL for event B
1. Go to the Event info page for Event A
2. click the iCal button to download the .ics file.
Current behaviour
----------------------------------------
The file will look like:
```
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CiviCRM//NONSGML CiviEvent iCal//EN
X-WR-TIMEZONE:America/New_York
METHOD:PUBLISH
END:VCALENDAR
```
NOTE there are no dates or times
Expected behaviour
----------------------------------------
the .ics file should be populated to include the date/time of the event etc.
Environment information
----------------------------------------
I was able to replicate this on master
Comments
----------------------------------------
I think this has to do with this code: https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Permission.php#L3555.32.0https://lab.civicrm.org/dev/wordpress/-/issues/62Contact image is broken2021-01-08T12:58:23ZandyburnsContact image is brokenI have reproduced on WP at https://demo.tadpole.cc/ and my install versions 5.26.2. It works on Drupal.
![image](/uploads/d0467024562f844eed2c3f63e0c0c9b1/image.png)
Reproduce:
1. Go to a contact summary screen > edit > upload contact ...I have reproduced on WP at https://demo.tadpole.cc/ and my install versions 5.26.2. It works on Drupal.
![image](/uploads/d0467024562f844eed2c3f63e0c0c9b1/image.png)
Reproduce:
1. Go to a contact summary screen > edit > upload contact image.
1. You'll see the contact image is broken.
1. If you try and navigate to the link (open in new window) it gives the WP error screen.
Link looks like: https://example.org/civicrm/?page=CiviCRM&q=civicrm%2Ffile&reset=1&filename=andy_2018_150x150_20b7648df6da2e1b694b25e5398ee2c7.jpg&mime-type=image/jpeg
Clean URL's are enabled. Note it is using ?page=CiviCRM not ?page=civiwp. The image is being loaded in the /wp-content/uploads/civicrm/custom directory. Images still show on a public profile directory.
WP error log is:
```
Warning: file_get_contents(/wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/node_modules/mime-db/db.json): failed to open stream: No such file or directory in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/MimeDbRepository.php on line 36
Warning: array_values() expects parameter 1 to be array, null given in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/MimeDbRepository.php on line 49
Warning: array_map(): Argument #2 should be an array in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/MimeDbRepository.php on line 49
Warning: array_keys() expects parameter 1 to be array, null given in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/MimeDbRepository.php on line 52
Warning: array_combine() expects parameter 1 to be array, null given in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/MimeDbRepository.php on line 52
Fatal error: Uncaught TypeError: Argument 1 passed to MimeTyper\Repository\AbstractRepository::setFromMap() must be of the type array, null given, called in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/MimeDbRepository.php on line 52 and defined in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/AbstractRepository.php:18 Stack trace: #0 /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/MimeDbRepository.php(52): MimeTyper\Repository\AbstractRepository->setFromMap(NULL) #1 /wp-content/plugins/civicrm/civicrm/vendor/dflydev/apache-mime-types/src/Dflydev/ApacheMimeTypes/AbstractRepository.php(31): MimeTyper\Repository\MimeDbRepository->internalInit() #2 /wp-content/plugins/civicrm/civicrm/vendor/dflydev/apache-mime-types/src/Dflydev/ApacheMimeTypes/AbstractRepository.php(68): Dflydev\ApacheMimeTypes\AbstractRepository->init() #3 /wp-content/plug in /wp-content/plugins/civicrm/civicrm/vendor/adrienrn/php-mimetyper/src/Repository/AbstractRepository.php on line 18
```5.28.0https://lab.civicrm.org/dev/core/-/issues/1872References to packages path in security status checks are assumed to be under...2020-07-15T13:25:41ZDaveDReferences to packages path in security status checks are assumed to be under civicrm rootAs noted by @seamuslee at https://github.com/civicrm/civicrm-core/pull/17822#issuecomment-657889572 there are some more spots that assume packages is under the civi root.
https://github.com/civicrm/civicrm-core/blob/2a494ac2e29d79c6c046...As noted by @seamuslee at https://github.com/civicrm/civicrm-core/pull/17822#issuecomment-657889572 there are some more spots that assume packages is under the civi root.
https://github.com/civicrm/civicrm-core/blob/2a494ac2e29d79c6c046be805374b9ee7e201ee1/CRM/Utils/Check/Component/Security.php#L204
They're likely too old to affect someone upgrading a drupal 8 site, but might apply to other CMS's and should be updated.
PR pending5.29.0https://lab.civicrm.org/dev/core/-/issues/1869CiviReport sent as email via mail_report job with a CSV attachment doesn't sh...2020-07-17T22:07:08ZDaveDCiviReport sent as email via mail_report job with a CSV attachment doesn't show UTF8 characters properly in ExcelSimilar to https://lab.civicrm.org/dev/core/-/issues/1424, if you choose to download a civireport as csv it will now show utf8 characters properly when opened in excel. But that only works for downloads and if you use the mail_report job...Similar to https://lab.civicrm.org/dev/core/-/issues/1424, if you choose to download a civireport as csv it will now show utf8 characters properly when opened in excel. But that only works for downloads and if you use the mail_report job to send a civireport as an email with a csv attachment, the attachment does not have the BOM.
PR pending but it might be as simple as moving the prepending of the BOM to makeCsv() instead of in the download function, depending on how else makeCsv is used. I already sort of have a test since this came up while writing a test for something.5.29.0https://lab.civicrm.org/dev/core/-/issues/1861Cannot edit a profile field of "Email" to use the Location Type "Primary"2020-07-13T20:27:08ZalicefruminCannot edit a profile field of "Email" to use the Location Type "Primary"Overview
----------------------------------------
One cannot edit a Profile field of the type email to have the location type primary.
Reproduction steps
----------------------------------------
1. Go to a profile
1. Create an email fi...Overview
----------------------------------------
One cannot edit a Profile field of the type email to have the location type primary.
Reproduction steps
----------------------------------------
1. Go to a profile
1. Create an email field with the location type "Home" and save it
1. Edit that field and change the location type to "Primary" click save
1. Edit that field again
Current behaviour
----------------------------------------
The location type is "Home" even though you just saved it as "Primary" and no error was thrown.
Expected behaviour
----------------------------------------
It should save as primary
Environment information
----------------------------------------
I was able to replicate this on 5.275.29.0https://lab.civicrm.org/dev/core/-/issues/1858User account form action not passing along contact id correctly possibly lead...2022-08-17T13:52:08ZseamusleeUser account form action not passing along contact id correctly possibly leading to duplicate contactsOverview
----------------------------------------
When submitting the back office user account creation user contact action the contact id of the user you are creating the account for is not properly passed along and can depending on you...Overview
----------------------------------------
When submitting the back office user account creation user contact action the contact id of the user you are creating the account for is not properly passed along and can depending on your unsupervised dedupe rule create duplicate contact record
Reproduction steps
----------------------------------------
1. Click on Contacts -> Find and Merge Duplicate Contacts and edit the Unsupervised Individual rule to change it from just email to use first and last name as well
1. Navigate to an individual's record that doesn't have a CMS user account
1. Select Actions -> Create User Record
1. Possibly / likely receive a fatal error due to duplicate record in civicrm_uf_match, find that a duplicate contact has been created
Current behaviour
----------------------------------------
Duplicate contact is created when the CMS record is created
Expected behaviour
----------------------------------------
No Duplicate contact is created and the CMS account is properly connected to the contact you are creating the user account for
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ _5.26.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.1__
* __CMS:__ _Drupal 8_5.29.0https://lab.civicrm.org/dev/core/-/issues/1855Allow different output formats for CiviReport results, like native excel form...2020-09-03T15:17:35ZDaveDAllow different output formats for CiviReport results, like native excel format, and untangle codeThis [started as a question](https://github.com/civicrm/civicrm-core/pull/17145) like "without having to patch core or adding another `if outputformat == 'x'` into some already awkward code in core, how can an extension implement a new o...This [started as a question](https://github.com/civicrm/civicrm-core/pull/17145) like "without having to patch core or adding another `if outputformat == 'x'` into some already awkward code in core, how can an extension implement a new output format for civireport results?"
My own motivation for this is a couple things:
1. I've had to look at the related code blocks more than once and it takes at least 15 minutes just to wade through and get to a point where you can start looking into what you were originally trying to look into. Then you get lost again while circling back.
1. I like the idea of being able to prevent people sending me listings of contacts in *pdf* format. No I will not import or analyze this data you've sent me in pdf format. (You can prevent this currently, it would just be easier after.)
1. The email body when sent by the mail_report job is hardcoded. There's been one or two requests to have it be more configurable. You can sort of do it with hook_alterMailParams now but it's not the most robust. I'm not fully addressing that here with any UI changes, but the proposed changes set the stage for it being easier to get there. At the very least you would now be able to write an extension that simply extends the existing handler class (e.g. csv) and overrides the small function that returns the text.
1. I'm currently doing this a different way and don't know if I would switch, but it opens up the possibility for an output handler that provides templates into which the data is inserted which then automatically is available in the existing UI and mail_report job. For most people this would mean a pdf template, but for people like me this means something like an excel template with a prebuilt pivot table and the handler would update the source rows so the pivot would automatically update.
And then beyond my own motivation some other possibilities which are theoretical:
1. A variation of the last point above would be an outputhandler where when run by mail_report it connects to another network service and sends the data there server-to-server. You could set this up via cron exactly the same way you normally use the mail_report job. The equivalent download would then still also be automatically available to users to do manually the same as any other civireport.
## So...
After doing some investigating, can summarize how the current output code works as
* type `sendmail`, which gets the output as a string and sends an email, OR
* type `not sendmail`, which starts a download. Note that "download" technically is also a string, but sent to the browser instead of used in an email.
Then further
* Some of the convoluted nature of the existing code is partly because how to get either of those is different depending on the output format (e.g. csv/pdf/etc).
* Also note that "download" for type 'print' is actually the same as other downloads it's just that you don't need to change http headers first. So that's also adding to the awkwardness a bit in the current code because the way it's written it almost seems like a different code path.
**THEREFORE --->**: My thinking is to start on this by having a common interface to get the string. I mean interface in the general sense of the word, not necessarily OO Interface but maybe. But **then it reduces the number of if/else's to just one**:
* If sendmail,
* Get string (delegated to the output handler).
* Send email (for now extract this to its own function just for readability).
* Else
* Delegate to output handler to set headers and send string to browser (aka download).
There's a little more to it, and it can borrow a bit from the existing PRs, but that's what I'm thinking in terms of first steps to untangling. I will work on a PR.
Then the next steps after that would be to allow for other output handlers, whether it be by a new hook or existing hook or other.
#### Misc notes
* save/copy/delete are handled in beginPostProcess and do nothing in endPostProcess
* there's a difference between compileContent() and the output content. compileContent() is not used for csv, but is used for pdf and 'print'.
* endPostProcess has 4 different "categories":
1. "add contacts to group", which doesn't output anything
2. _sendmail, which uses the other output handlers but requests the results as a string.
* defaults to print, but also does csv or pdf and then exits
* There is also some hardcoding of the email body, partly because it includes a computed url, but it would be nice not to hardcode this.
* Note pdf is called with TRUE for 3rd param, so that it returns the pdf as a string.
3. Download, which uses the other output handlers but requests the results as a download.
* Note that print is a download technically, it just goes to the browser window. Csv or pdf starts an attachment download.
* Here pdf is the default, but at the point in the code where that happens it has to be either print or pdf and print would have been already handled.
* Note pdf is called with FALSE for 3rd param.
* csv is done by a wrapper around the same function that is used in _sendmail
4. Tests that extend CiviReportTestCase use _resultSet/getResultSet() and have _outputMode blank, so endPostProcess (which gets called from preProcess because force=1 here) does none of the above and just stores the results in an array.5.29.0https://lab.civicrm.org/dev/core/-/issues/1847Offset is not respected in Date Preferences2020-07-15T00:47:07ZyashodhaOffset is not respected in Date PreferencesSteps to replicate :
- Navigate to Administer > Customize Data and Screens > Date Preferences
- Changed searchDate Start offset from 20 to 50:
![pref](/uploads/96847ace7528adc16ad37a7ad42692ed/pref.png)
The change had no affect on the...Steps to replicate :
- Navigate to Administer > Customize Data and Screens > Date Preferences
- Changed searchDate Start offset from 20 to 50:
![pref](/uploads/96847ace7528adc16ad37a7ad42692ed/pref.png)
The change had no affect on the range of years offered in search forms (i.e. there is only a 20 year range available 2010 - 2030)
![search](/uploads/a0fccd9f6e91c643a4bf755289a6e7e3/search.png)5.27.2https://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/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/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/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/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/1829Custom Date field with format=yy displays calendar icon that doesn't work2020-06-25T20:57:38ZjitendraCustom Date field with format=yy displays calendar icon that doesn't workCreate a custom date field with type = yy. It displays an unwanted calendar icon on the field.
![image](/uploads/4dc93b3ca4ec52f234ed14f8b14cdf43/image.png)Create a custom date field with type = yy. It displays an unwanted calendar icon on the field.
![image](/uploads/4dc93b3ca4ec52f234ed14f8b14cdf43/image.png)5.28.0https://lab.civicrm.org/dev/core/-/issues/1825Merge/bundle flexmailer into core2020-10-23T13:46:59ZbgmMerge/bundle flexmailer into coreFollow-up to: https://github.com/civicrm/org.civicrm.flexmailer/issues/26 - publish a stable version.
Rationale:
* Flexmailer provides cleaner an alternative to a lot of core civimail code
* It adheres to Lexim, in that eventually it w...Follow-up to: https://github.com/civicrm/org.civicrm.flexmailer/issues/26 - publish a stable version.
Rationale:
* Flexmailer provides cleaner an alternative to a lot of core civimail code
* It adheres to Lexim, in that eventually it was meant to replace the core code (i.e. the core code should be flagged as deprecated and eventually removed).
What steps would be required to ship flexmailer in core?
I recall Tim mentioning two options:
* (1) Merge flexmailer in the same way that Api4 was merged, if both versions are highly inter-dependent.
* (2) Bundle flexmailer as a core-extension, similar to sequentialcreditnotes or eventually eventcart (i.e. clearly separate isolation between code bases, but core can assume that the extension is enabled).
I feel like we are more in the second situation, because flexmailer is stable and not tightly coupled with the version of CiviCRM core. However, it may be a bit more work, since we have to tweak the packaging/distribution of CiviCRM?
cc @totten @eileen5.28.0https://lab.civicrm.org/dev/core/-/issues/1824Fixes to dedupe getting dynamic references2020-06-19T02:35:54ZJonGoldFixes to dedupe getting dynamic referencesCivi 5.26 included [PR #17125](https://github.com/civicrm/civicrm-core/pull/17125), "Fix Dedupe entity_tag mangling bug". This introduced the new method `CRM_Core_DAO::getDynamicReferencesToTable()` and `CRM_Dedupe_MergeHandler::getTabl...Civi 5.26 included [PR #17125](https://github.com/civicrm/civicrm-core/pull/17125), "Fix Dedupe entity_tag mangling bug". This introduced the new method `CRM_Core_DAO::getDynamicReferencesToTable()` and `CRM_Dedupe_MergeHandler::getTablesRelatedToTheMergePair()`. However, there are two bugs in the implementation:
* It assumes that only one dynamic reference can exist between two tables. In addition to extensions that may introduce dynamic references, this is also untrue in core: `civicrm_pcp_block` has two dynamic references to `civicrm_contact`: Both `entity_id` and `target_entity_id`.
* It assumes that the column specifying the entity is always called `entity_table`, and this is hard-coded into the SQL in `getTablesRelatedToTheMergePair()`. However, this column isn't always `entity_table`. We should pull the correct column name from the metadata.
I don't think there's a Gitlab ticket for PR #17125, so I'm referencing the PR here instead.5.27.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1819Membership import does not accept "tab" as import field separator but interpr...2022-06-10T08:47:42ZblippMembership import does not accept "tab" as import field separator but interprets it as the character “t”Overview
----------------------------------------
In membership import, the help text mentions that users can enter `tab` (literally those three characters) as “Import Field Separator” to configure it for tab-separated CSV files (see Sc...Overview
----------------------------------------
In membership import, the help text mentions that users can enter `tab` (literally those three characters) as “Import Field Separator” to configure it for tab-separated CSV files (see Screenshot 3 below). However, the system instead ends up using the single character `t` as field separator, which leads to some funny column titles (see Screenshots 1 and 2). Copying an actual tab character into the “Import Field Separator” field works to let the system recognize tabs.
Interestingly, this bug is not present in contacts import, whose user interface looks exactly the same as the membership import.
Reproduction steps
----------------------------------------
1. Click on **Memberships -> Import Memberships**.
1. Use for example this **tab-separated file** [test_bug_tab.csv](/uploads/5c8958157830f5f41528759150dce0c3/test_bug_tab.csv) as an example.
1. Activate **First row contains column headers**
1. Enter `tab` into the field **Import Field Separator**
1. Click **Continue**
Current behaviour
----------------------------------------
As visible in Screenshot 1 and Screenshot 2 below, the cells (column titles and content) are split at every occurrence of the character `t`.
Expected behaviour
----------------------------------------
Cells (column titles and content) should be split at every occurrence of a tab. For example, the first column should be “id”, the second “Mitgliedsnummer”, and not “id Mi” and “gliedsnummer Ti”.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
Tested on https://demo.tadpole.cc and https://demo.symbiotic.coop with
* __Browser:__ _Firefox 77.0.1_
* __CiviCRM:__ _5.26.1_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __CMS:__ _Drupal, WordPress_
Screenshot 1: Tested on the Wordpress+CiviCRM 5 demo instance https://demo.tadpole.cc :
![Screenshot_from_2020-06-13_22-06-25](/uploads/f643ab52a95722c676332905d10359e8/Screenshot_from_2020-06-13_22-06-25.png)
Screenshot 2: Tested on the Drupal+CiviCRM 5 demo instance https://demo.symbiotic.coop :
![Screenshot_from_2020-06-13_22-06-34](/uploads/7e4fc06a905dea6b82de2f7af32495bb/Screenshot_from_2020-06-13_22-06-34.png)
Screenshot 3: This shows the help text mentioning `"tab" (without quotes)`:
![Screenshot_from_2020-06-13_22-07-50](/uploads/ef14fe97132a3a96705c1793b8fc4576/Screenshot_from_2020-06-13_22-07-50.png)
Comments
----------------------------------------
The https://demo.symbiotic.coop demo instance is not displaying its exact CiviCRM version number. Maybe they could add this?5.51.0https://lab.civicrm.org/dev/core/-/issues/1817Editing a custom field choice label changes the `name` if you do it from the ...2020-06-23T14:18:18ZDaveDEditing a custom field choice label changes the `name` if you do it from the custom field admin screensBut it correctly leaves the `name` field alone if you do it from Admin - System Settings - Option Groups.
It appears to have been this way for a really long time, i.e. https://github.com/civicrm/civicrm-core/blame/5.26.0/CRM/Custom/Form...But it correctly leaves the `name` field alone if you do it from Admin - System Settings - Option Groups.
It appears to have been this way for a really long time, i.e. https://github.com/civicrm/civicrm-core/blame/5.26.0/CRM/Custom/Form/Option.php#L390
1. Go to Administer - Customize - Custom Fields.
2. Find or create one that has a list of option choices, like a Select field.
3. Pick one of the option choices to edit and make a note of the value of `name` for it, e.g. with api explorer do `OptionValue - Get` and for `option group id` pick this choice list's option group. Or look in the database directly in civicrm_option_value.
4. Edit the choice and change the label.
5. Do the api explorer query again or look in the database - the `name` has changed.
This seems to be just for custom fields. I'm sure I would have noticed it at some point if it was for something built-in like activity type.5.28.0