CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2020-08-06T23:07:08Zhttps://lab.civicrm.org/dev/core/-/issues/1895Advanced Search (search by complete or partial name) returns all contacts2020-08-06T23:07:08ZspalmstromAdvanced Search (search by complete or partial name) returns all contactsOverview
----------------------------------------
_Please describe your problem or bug in detail._
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversatio...Overview
----------------------------------------
_Please describe your problem or bug in detail._
_If you have already posted on https://civicrm.stackexchange.com or https://chat.civicrm.org, please include the link to that conversation._
Reproduction steps
----------------------------------------
1. Click on **Advanced Search**.
1. Click on **(search by complete or partial name)**.
1. Two boxes appear.
![image](/uploads/926f85f696d68ceea30dda0da05b4747/image.png)
1. Enter something in one of the boxes and click **Search**
![image](/uploads/ba3cd0bf8fc66fac7ba4882d22106b8c/image.png)
Current behaviour
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
All contacts appear. Note *Accounts* are actually in trash in my test data set.
![image](/uploads/44f942bee2816908afb8be7ecec0a94d/image.png)
Expected behaviour
----------------------------------------
_What should happen._
Only contacts meeting the criteria should appear.
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 necessary. -->
* __Browser:__ _Edge, but probably irrelevant_
* __CiviCRM:__ _5.29 alpha1, but also seen in 5.27.2_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4, but probably irrelevant.__
* __CMS:__ _Joomla 3.9.5 but probably irrelevant_
* __Database:__ _MySQL 5.7.30 but probably irrelevant._
* __Web Server:__ _IIS, but also seen under Apache. Probably irrelevant.._
Comments
----------------------------------------
_Anything else you would like the reviewer to note._
1. If **Search in Trash** is ticked, all Trash entries are returned.
1. When you click on **Edit Search Criteria** and repeat the above process, the boxes are blank.5.29.0https://lab.civicrm.org/dev/core/-/issues/1894CRM_Activity_Form_SearchTest::testQill can fail semi-randomly2020-07-21T13:32:55ZDaveDCRM_Activity_Form_SearchTest::testQill can fail semi-randomlyI think it's because it uses a dataprovider that calculates time-sensitive things. Dataproviders run at a different unknown time from when the test itself runs. Could use a callback to work around it, or just not use a dataprovider.
Exa...I think it's because it uses a dataprovider that calculates time-sensitive things. Dataproviders run at a different unknown time from when the test itself runs. Could use a callback to work around it, or just not use a dataprovider.
Example fail:
```
CRM_Activity_Form_SearchTest::testQill with data set #0 (array(array('activity_date_time_relative', '=', 'ending_60.day', 0, 0)), array(array('Activity Date is Last 60 days...59 PM)')))
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
0 => Array (
- 0 => 'Activity Date is Last 60 days including today (between May 22nd, 2020 12:00 AM and July 20th, 2020 11:59 PM)'
+ 0 => 'Activity Date is Last 60 days including today (between May 23rd, 2020 12:00 AM and July 21st, 2020 11:59 PM)'
)
)
/home/jenkins/bknix-dfl/build/core-17901-5ckvo/web/sites/all/modules/civicrm/tests/phpunit/CRM/Activity/Form/SearchTest.php:77
/home/jenkins/bknix-dfl/build/core-17901-5ckvo/web/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:209
/home/jenkins/bknix-dfl/extern/phpunit7/phpunit7.phar:615
```5.29.0https://lab.civicrm.org/dev/core/-/issues/1891"applyLocale()" does not apply desired locale when "inheritLocale" is set2023-09-05T13:38:59Zhaystack"applyLocale()" does not apply desired locale when "inheritLocale" is setFollowing up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM...Following up on #1890 it seems that the locale string in the `language` column in the `civicrm_uf_match` table is also redundant.
It is set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L173) when there is a locale requested in a URL that uses the `lcMessages` query param or when there's an existing locale set in the session.
The session locale is set from the `$ufm->language` locale [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Core/BAO/ConfigSetting.php#L187) when there's a logged-in user and the locale hasn't been determined by the `lcMessages` query param or there's no locale set in the session.
I cannot find anywhere else in the CiviCRM Core code where `$ufm->language` is read or set, so this appears to be circular logic that seems redundant to me.
Can we remove it since it's never actually used for anything practical?
**Correction:** both the `$ufm->language` and `lcMessages` session variable are set [here](https://github.com/civicrm/civicrm-core/blob/fbb161e3a60900dd92f8dbf78b468b58233ee0be/CRM/Admin/Form/Setting/Localization.php#L336-L338), but this only sets the locale for the Contact/User that saves that particular form. It doesn't alter the circularity of the logic in `applyLocale()`.5.29.0haystackhaystackhttps://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/1888Advanced search gives fatal error if select a group and missing group on cont...2020-07-20T04:07:07ZDaveDAdvanced search gives fatal error if select a group and missing group on contact editAlso happening on dmaster.demo.
Seems related to https://lab.civicrm.org/dev/core/-/issues/1885 and the same commit https://github.com/civicrm/civicrm-core/pull/13958/files
If I revert it then it works. But the revert is not clean and ...Also happening on dmaster.demo.
Seems related to https://lab.civicrm.org/dev/core/-/issues/1885 and the same commit https://github.com/civicrm/civicrm-core/pull/13958/files
If I revert it then it works. But the revert is not clean and needed to be done manually, so I'm not sure if that's just my lack of git-fu or if there's something that came later that reverting might now break.
Also copying over info from 1885:
When saving a new contact that does not have a group:
`Warning: Invalid argument supplied for foreach() in CRM_Contact_BAO_Contact::create() (line 309 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contact/BAO/Contact.php).`
When editing a contact that does have a group:
`Warning: htmlspecialchars() expects parameter 1 to be string, array given in HTML_Common->_getAttrString() (line 144 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/Common.php).`
And then it doesn't show the group on the form and then when saving that contact:
`Warning: array_key_exists() expects parameter 2 to be array, string given in CRM_Contact_Form_Contact->postProcess() (line 952 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contact/Form/Contact.php).`5.29.0https://lab.civicrm.org/dev/core/-/issues/1885E_WARNINGS on contact edit form related to groups2020-07-20T02:57:06ZDaveDE_WARNINGS on contact edit form related to groupsThis came up the other day while reviewing a PR but I couldn't reproduce it, but now today I'm seeing it on dmaster.demo (and elsewhere) so I assume it's from a recent change somewhere.
When saving a new contact that does not have a gro...This came up the other day while reviewing a PR but I couldn't reproduce it, but now today I'm seeing it on dmaster.demo (and elsewhere) so I assume it's from a recent change somewhere.
When saving a new contact that does not have a group:
`Warning: Invalid argument supplied for foreach() in CRM_Contact_BAO_Contact::create() (line 309 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contact/BAO/Contact.php).`
When editing a contact that does have a group:
`Warning: htmlspecialchars() expects parameter 1 to be string, array given in HTML_Common->_getAttrString() (line 144 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/packages/HTML/Common.php).`
And then it doesn't show the group on the form and then when saving that contact:
`Warning: array_key_exists() expects parameter 2 to be array, string given in CRM_Contact_Form_Contact->postProcess() (line 952 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contact/Form/Contact.php).`5.29.0https://lab.civicrm.org/dev/core/-/issues/1880custom data insert/update error if using reserved words2021-01-03T21:18:35Zlcdwebcustom data insert/update error if using reserved wordsRan into a situation where a client had created a custom field titled "use", which resulted in a column in the corresponding value table with that name. Because it is a reserved word, it triggered errors during insert/update. This is eas...Ran into a situation where a client had created a custom field titled "use", which resulted in a column in the corresponding value table with that name. Because it is a reserved word, it triggered errors during insert/update. This is easily remedied with the use of backticks (which we're starting to use more consistently anyway).
One could argue we should address this upstream and prevent the creation of fields with reserved names. But that won't address previously created fields, and adding backticks to our SQL is a good policy anyway.
PR forthcoming.5.29.0lcdweblcdwebhttps://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/1871Can't find recaptcha in Drupal 82020-07-14T01:30:01ZAlanDixonCan't find recaptcha in Drupal 8This might seem like a Drupal 8 issue, but it's actually a lurking core issue.
On line 81 of CRM/Utils/ReCAPTCHA.php, there's a require_once 'packages/recaptcha/recaptchalib.php'
The 'packages/' part of the path is unnecessary and brea...This might seem like a Drupal 8 issue, but it's actually a lurking core issue.
On line 81 of CRM/Utils/ReCAPTCHA.php, there's a require_once 'packages/recaptcha/recaptchalib.php'
The 'packages/' part of the path is unnecessary and breaks Drupal 8 sites because of the different path layout.
Probably worth doing a file scan to see if there are similar require_once issues.5.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/1868Slew of E_NOTICES on Profiles admin page and description field is always blank2020-07-11T11:30:17ZDaveDSlew of E_NOTICES on Profiles admin page and description field is always blankSeems to be from this https://github.com/civicrm/civicrm-core/commit/fdc2e63a7fb961c26bab02e9347ce44d2bdfde66#diff-9b81968d46b30094194b02c5dbf39b88L1668-L1671
PR: https://github.com/civicrm/civicrm-core/pull/17786Seems to be from this https://github.com/civicrm/civicrm-core/commit/fdc2e63a7fb961c26bab02e9347ce44d2bdfde66#diff-9b81968d46b30094194b02c5dbf39b88L1668-L1671
PR: https://github.com/civicrm/civicrm-core/pull/177865.29.0https://lab.civicrm.org/dev/core/-/issues/1866API4 Custom fields: problem if same field name used in two custom groups2020-07-12T11:30:35Zaydunsaidan.saunders@squiffle.ukAPI4 Custom fields: problem if same field name used in two custom groupsOverview
----------------------------------------
In API4 custom fields are referred to as eg 'Custom_Group1.Custom_Field1'.
If the same custom field name is used in two custom field groups, API4 gets confused and updates to the field i...Overview
----------------------------------------
In API4 custom fields are referred to as eg 'Custom_Group1.Custom_Field1'.
If the same custom field name is used in two custom field groups, API4 gets confused and updates to the field in the second group are either wrongly applied to the field in the first group, or have no effect.
Reproduction steps
----------------------------------------
1. Create a custom field group 'CustomGroup1' used for Individuals and custom field 'myfield' (alpha text)
1. Create a custom field group 'CustomGroup2' used for Individuals and custom field 'myfield' (alpha text)
1. Use [API4](https://dmaster.demo.civicrm.org/civicrm/api4#/explorer/Contact/update?where=%5B%5B%22id%22,%22%3D%22,%22203%22%5D%5D&values=%5B%5B%22CustomGroup1.MyField%22,%22hello%22%5D%5D) to set 'CustomGroup1.myfield' to 'hello' - works as expected
1. Use [API4](https://dmaster.demo.civicrm.org/civicrm/api4#/explorer/Contact/update?where=%5B%5B%22id%22,%22%3D%22,%22203%22%5D%5D&values=%5B%5B%22CustomGroup2.MyField%22,%22world%22%5D%5D) to set 'CustomGroup2.myfield' to 'world' - Observe that the wrong field is updated: 'CustomGroup**1**.myfield' is changed to 'world', no change to CustomGroup2.myfield
Note that if the CustomGroups are used for different purposes and only the second group is applicable, attempts to update its field have no effect.
Environment information
----------------------------------------
* __CiviCRM:__ _master_ Verified on dmaster.demo.civicrm.org5.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/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/1812Do not allow enabling database logging when using multilingual2020-07-14T14:56:52ZspalmstromDo not allow enabling database logging when using multilingualOverview
----------------------------------------
If a non-US English system is set to logging (at least under Joomla), you get Network errors.
Reproduction steps
----------------------------------------
1. Set the system to logging.
2...Overview
----------------------------------------
If a non-US English system is set to logging (at least under Joomla), you get Network errors.
Reproduction steps
----------------------------------------
1. Set the system to logging.
2. Change a group membership.
3. View the change log - you get Network Error.
I'm flagging it up here as someone may have a quick fix for it or may know where view creation takes place.
Current behaviour
----------------------------------------
```
SELECT title FROM `joomla`.log_civicrm_group_en_GB WHERE log_date <= 20200612110114 AND id = 59 ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'joomla.log_civicrm_group_en_gb' doesn't exist]"]
```
Expected behaviour
----------------------------------------
You see the change log.
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. -->
* __Browser:__ Irrelevant_
* __CiviCRM:__ _5.26.1_ but may not be relevant
* __PHP:__ _7.4, but irrelevant__
* __CMS:__ _Joomla 3.9.6 but may be irrelevant_
* __Database:__ _MySQL 5.7.30-log but probably irrelevant_
* __Web Server:__ _irrelevant..._
Comments
----------------------------------------
The issue is resolved by creating this view in MySQL. It would probably make sense for the *all* the necessary log views to be created when the log tables are created.
```
CREATE
ALGORITHM = UNDEFINED
DEFINER = `<database user in question`
SQL SECURITY DEFINER
VIEW `log_civicrm_group_en_GB` AS
SELECT
`log_civicrm_group`.`id` AS `id`,
`log_civicrm_group`.`name` AS `name`,
`log_civicrm_group`.`description` AS `description`,
`log_civicrm_group`.`source` AS `source`,
`log_civicrm_group`.`saved_search_id` AS `saved_search_id`,
`log_civicrm_group`.`is_active` AS `is_active`,
`log_civicrm_group`.`visibility` AS `visibility`,
`log_civicrm_group`.`where_clause` AS `where_clause`,
`log_civicrm_group`.`select_tables` AS `select_tables`,
`log_civicrm_group`.`where_tables` AS `where_tables`,
`log_civicrm_group`.`group_type` AS `group_type`,
`log_civicrm_group`.`cache_date` AS `cache_date`,
`log_civicrm_group`.`refresh_date` AS `refresh_date`,
`log_civicrm_group`.`parents` AS `parents`,
`log_civicrm_group`.`children` AS `children`,
`log_civicrm_group`.`is_hidden` AS `is_hidden`,
`log_civicrm_group`.`is_reserved` AS `is_reserved`,
`log_civicrm_group`.`created_id` AS `created_id`,
`log_civicrm_group`.`modified_id` AS `modified_id`,
`log_civicrm_group`.`title_en_GB` AS `title`,
`log_civicrm_group`.`log_date` AS `log_date`,
`log_civicrm_group`.`log_conn_id` AS `log_conn_id`,
`log_civicrm_group`.`log_user_id` AS `log_user_id`,
`log_civicrm_group`.`log_action` AS `log_action`
FROM
`log_civicrm_group`
```5.29.0https://lab.civicrm.org/dev/core/-/issues/1803Update guzzle to d8 latest2020-09-02T07:13:33ZeileenUpdate guzzle to d8 latestI discovered that there was an incompatibility between the guzzle version in Omni vs Civi. It is an error handling issue so it was showing up in the fileExists function in one of our status checks & is fairly low impact.
On digging it s...I discovered that there was an incompatibility between the guzzle version in Omni vs Civi. It is an error handling issue so it was showing up in the fileExists function in one of our status checks & is fairly low impact.
On digging it seems the issue was due to Omnipay having guzzle 6.5.x & CiviCRM having 6.3.x & the Omnipay one getting picked up for a core civi call but then picking up one class from the core civi one.
Obviously composer & extensions continues to be a challenge but here I think the immediate fix is to update CiviCRM Guzzle to the one that ships with latest Drupal 8 - currently version": "6.5.4",`
https://git.drupalcode.org/project/drupal/-/blob/8.9.x/composer.lock#L1062
For now I'm downgrading Omnipay guzzle to match current CiviCRM
@seamuslee5.29.0https://lab.civicrm.org/dev/core/-/issues/1795Using Parent tag in search form doesn't pull contacts marked with child tag i...2021-04-01T11:40:23ZMonish DebUsing Parent tag in search form doesn't pull contacts marked with child tag in search form resultReproduction steps
----------------------------------------
Steps to replicate:
1. Create a parent tag A and child tag A1
2. Create/update contact and tag with A1
3. Go to 'Find Contacts' or 'Find Contributions' and search by Tag - A
...Reproduction steps
----------------------------------------
Steps to replicate:
1. Create a parent tag A and child tag A1
2. Create/update contact and tag with A1
3. Go to 'Find Contacts' or 'Find Contributions' and search by Tag - A
Current behaviour
----------------------------------------
```
1. In 'Find Contact' result, it doesn't show contact which is tagged with child tag A1
2. In 'Find Contributions' result, it doesn't pull contribution(s) of contact tagged with child tag A1
```
Expected behaviour
----------------------------------------
Searching using a parent tag should automatically include the contacts which are in parent tag A and in its n child tag(s) - An. In this use-case it should show contact tagged with child A1 tag.
Comments
----------------------------------------
ping @JoeMurray @eileen @seamuslee @lcdweb5.29.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1767CRM_Dedupe_Finder parses phone key incorrectly2020-07-19T21:43:43Zwil_SRQCRM_Dedupe_Finder parses phone key incorrectlyOverview
----------------------------------------
A profile input form that matches on Phone-Main-Mobile (and I suspect on any phone) sends CRM_Dedupe_Finder::formatParams an input like '["phone-3-1"] => "3214567890"' which after the rel...Overview
----------------------------------------
A profile input form that matches on Phone-Main-Mobile (and I suspect on any phone) sends CRM_Dedupe_Finder::formatParams an input like '["phone-3-1"] => "3214567890"' which after the relevant code around line 255 yields ["phone-3"]. This doesn't match the "phone" in CRM_Dedupe_BAO_RuleGroup::supportedFields so the duplicate check fails.
I patched this by replacing the regular expression in line 255
https://github.com/civicrm/civicrm-core/blob/master/CRM/Dedupe/Finder.php#L255
- **From:** `'/(.*)-(Primary-[\d+])$|(.*)-(\d+|Primary)$/'`
- **To:** `'/(.*)-(Primary-[\d+])$|(.*)-(\d+-\d+)$|(.*)-(\d+|Primary)$/'`
https://civicrm.stackexchange.com/q/35672/5446
Reproduction steps
----------------------------------------
1. Create individual unsupervised rule that matches on phone
2. Create input profile that creates contact with phone-main-mobile and set to "Update the matching contact" on duplicate match
3. Create multiple contacts with same phone
Current behaviour
----------------------------------------
Creates duplicate contacts
Expected behaviour
----------------------------------------
Update pre-existing contact
Environment information
----------------------------------------
* __CiviCRM:__ 5.25.0
Comments
----------------------------------------
I expect you'd prefer I do what's called a "pull request." Apologies, I'm an old retired guy who hasn't programmed for a living in over 35 years so all this new fangled stuff intimidates me. This was an act of desperation on behalf of the nonprofit I volunteer for.
@jaapjansma has created the PR: https://github.com/civicrm/civicrm-core/pull/173615.29.0