Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-27T05:03:25Zhttps://lab.civicrm.org/dev/core/-/issues/495CQ: Migrate simple Preferences & Settings forms to using a Generic class.2023-06-27T05:03:25ZeileenCQ: Migrate simple Preferences & Settings forms to using a Generic class.Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the cl...Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the class 'CRM_Admin_Form_Preferences_Event' and all classes that don't need special sauce would be removed & the xml would be altered to
```
<item>
<path>civicrm/admin/setting/preferences/event</path>
<title>CiviEvent Component Settings</title>
<page_callback>CRM_Admin_Form_Generic</page_callback>
</item>
```
This page would load settings based on filtering setting metadata - so any fields with a key in their metadata like this
```
settings_pages => [
'event' => ['weight' => 10]
]
```
would show up at the url above (note the last value on the url is the filter).
Extensions could use the existing alterSettingMetadata hook to add & remove fields from any pages that use the Generic form to choose their settings and extensions could add settings pages by just adding an xml entry & their metadata
We would convert simple forms & for more complex forms we would attempt to break the inheritance on the 2 existing forms (CRM_Admin_Form_Preferences & CRM_Admin_Form_Setting) in favour of using just the CRM_Admin_Form_SettingTrait in an attempt to grandfather them out.https://lab.civicrm.org/dev/core/-/issues/2393Settings metadata help_text parameter doesn't work and causes errors if you s...2023-06-27T05:03:25ZDaveDSettings metadata help_text parameter doesn't work and causes errors if you specify it but there's no .hlp fileNot sure if I'm going to follow this thru but am recording some findings. There's at least 3 things to deal with:
1. There's no facility to specify the title of the help box. This is the easiest since it can compute it from the setting ...Not sure if I'm going to follow this thru but am recording some findings. There's at least 3 things to deal with:
1. There's no facility to specify the title of the help box. This is the easiest since it can compute it from the setting label.
2. CRM.help _does_ support passing a single string as the help content, but you get into quote-hell pretty quickly.
3. The `{help}` plugin which is what generates the `<a>` link that calls CRM.help doesn't have a way to accept a string as the help content, and `{help}` is what SettingForm.tpl uses. \
3.b Related note: the `{help}` plugin behaves differently whether you pass it a title parameter or not. If there's no parameter it expects to find it inside an associated .hlp file.
Earlier related issue: https://lab.civicrm.org/dev/core/-/issues/1920https://lab.civicrm.org/dev/core/-/issues/4387PHP 8 Compatibility Issue - strlen of array2023-06-26T22:33:34Zluke.stewartPHP 8 Compatibility Issue - strlen of arrayApparently it's possible for the "$this->_text" of a Checkbox to be an array - at least an empty array.
This causes a fatal error from str here.
https://github.com/civicrm/civicrm-packages/blob/61ff39518dfd54449158bfd44670063d84615015/H...Apparently it's possible for the "$this->_text" of a Checkbox to be an array - at least an empty array.
This causes a fatal error from str here.
https://github.com/civicrm/civicrm-packages/blob/61ff39518dfd54449158bfd44670063d84615015/HTML/QuickForm/checkbox.php#L138
To replicate:
Install the GDPR extension - this adds an additional "Terms & Conditions" tab to a contribution page. Configure the GDPR settings -> /civicrm/gdpr/settings select the option to enable for every contribution page.
It has a radio button that gives the option to "Enable terms and Conditions Acceptance" however as well as yes and no there is the option to not have this selected. Unselecting results in the above code being called with an empty array. This emits a warning in PHP7.4 but a fatal error in PHP 8.1
I'm unclear whether this is the GDPR extension behaving badly and should be left as is - or should we catch this?
This was found on a site upgrading to Drupal 10 - and therefore PHP 8.1 and manifested in a fatal error on contribution pages.
_FZ Ref: 28529_https://lab.civicrm.org/dev/core/-/issues/4393Mailing and Outbound Mailings no longer available in SearchKit2023-06-26T21:41:48ZlarsssandergreenMailing and Outbound Mailings no longer available in SearchKitOn 5.62, you can select Mailings and Outbound Mailings in SearchKit. On dmaster, you no longer can.On 5.62, you can select Mailings and Outbound Mailings in SearchKit. On dmaster, you no longer can.https://lab.civicrm.org/dev/core/-/issues/3570When creating a CiviMail it is possible to select this mailing as a "previous...2023-06-26T19:32:24ZlolcodeWhen creating a CiviMail it is possible to select this mailing as a "previous mailing" in the recipients listWhen creating a CiviMail it is possible to select this mailing as a "previous mailing" in the recipients list. I have not tested what it does but it makes no sense from a user point of view.
To reproduce just name the mailing and then o...When creating a CiviMail it is possible to select this mailing as a "previous mailing" in the recipients list. I have not tested what it does but it makes no sense from a user point of view.
To reproduce just name the mailing and then open the recipients list. In fact before the mailing is named it still shows in the list but with the name "null".
![bug-first-mailing](/uploads/ea99f69608bb75993b467f1e77795480/bug-first-mailing.jpg)
![null-mailing](/uploads/61df71ab974462ffded69b02aba4046f/null-mailing.jpg)https://lab.civicrm.org/dev/core/-/issues/4365AdminUI - don't show or allow deleting reserved custom fields/groups2023-06-26T17:32:11ZDaveDAdminUI - don't show or allow deleting reserved custom fields/groupsPartly a followup to https://lab.civicrm.org/dev/core/-/issues/4338
1. It shows you the reserved groups in the listing - regular core doesn't do this, 'cuz reasons.
2. It lets you delete fields in those groups - not good.
3. It lets you...Partly a followup to https://lab.civicrm.org/dev/core/-/issues/4338
1. It shows you the reserved groups in the listing - regular core doesn't do this, 'cuz reasons.
2. It lets you delete fields in those groups - not good.
3. It lets you delete the group after you've deleted those fields - not good.
Reserved custom groups are always created by extensions, and often depend on them being unchangeable by users.5.64.0https://lab.civicrm.org/dev/core/-/issues/4376Search build using Related Contacts (RelationshipCache) doesn't provide optio...2023-06-26T13:44:25ZjitendraSearch build using Related Contacts (RelationshipCache) doesn't provide options under Action dropdown.To replicate:
- Create `New search` from searchkit UI.
- Search for Related Contacts. ![image](/uploads/8619b8b7fce4ab2414ae05c4026c198a/image.png)
- Hit Search.
- Click on `Action` button to check the list of available actions for this...To replicate:
- Create `New search` from searchkit UI.
- Search for Related Contacts. ![image](/uploads/8619b8b7fce4ab2414ae05c4026c198a/image.png)
- Hit Search.
- Click on `Action` button to check the list of available actions for this entity.
- Action dropdown does not lists actions for update, enable/disable, delete relationships ![image](/uploads/99d110a73111bdf5575a935729fe6e4f/image.png)
The problems seems to be in identifying the entity. When the Action button is selected, the search is made to retrieve actions for `RelationshipCache` entity instead of `Relationship`.https://lab.civicrm.org/dev/core/-/issues/4335Create User Record systematically create an account with just the e-mail address2023-06-26T13:28:47ZolivierCreate User Record systematically create an account with just the e-mail addressOverview
----------------------------------------
Create User Record (civicrm/contact/view/useradd?reset=1&action=add&cid=xxxx)
![image](/uploads/4ce580a31d1c0f9f3d30548e245e8a12/image.png)
don't find existing contact, and create a new ...Overview
----------------------------------------
Create User Record (civicrm/contact/view/useradd?reset=1&action=add&cid=xxxx)
![image](/uploads/4ce580a31d1c0f9f3d30548e245e8a12/image.png)
don't find existing contact, and create a new one with only email adress of the existing contact
Reproduction steps
----------------------------------------
1. On view contact, click **Actions** and **Create User Record**
2. Complete form with username and password, then validate
3. Search contact with the same email address than the existing contact
- You will find the existing contact, and a new one
- UFid is set on the new account
Expected behaviour
----------------------------------------
UFid should be set to existing account, and no new one should be created
Environment information
----------------------------------------
* __CiviCRM:__ 5.61.4 and the problem must have existed for quite a few previous versions
* __PHP:__ 8.1.15
* __CMS:__ Drupal 9.5.9
* __Database:__ MariaDB 10.5.16
* __Web Server:__ Apache/2.4.53
Comments
----------------------------------------
It seems to me that the problem lies in UFMatch.php, in the synchronizeUFMatch() function, which doesn't retrieve the contact_id if it exists.
As a workaround, I propose replacing lines 252 and 253
```
$contactID = civicrm_api3('Contact', 'create', $contactParameters)['id'];
$ufmatch->contact_id = $contactID;
```
with
```
// If contactID exist, user exist and use it
if (isset($dedupeParameters['contact_id'])) {
$ufmatch->contact_id = $dedupeParameters['contact_id'];
}
else {
// Conatct does not exist, so create a new one
$contactID = civicrm_api3('Contact', 'create', $contactParameters)['id'];
$ufmatch->contact_id = $contactID;
}
```5.63.0https://lab.civicrm.org/dev/core/-/issues/2379Geocoding saves values that web UI doesn't accept2023-06-26T12:56:40ZJonGoldGeocoding saves values that web UI doesn't acceptOverview
----------------------------------------
Geocoders can pass back a valid latitude/longitude that looks something like this: `-12.456789012345`. That's 16 characters. However, `CRM_Core_DAO::makeAttribute()` only allows saving `...Overview
----------------------------------------
Geocoders can pass back a valid latitude/longitude that looks something like this: `-12.456789012345`. That's 16 characters. However, `CRM_Core_DAO::makeAttribute()` only allows saving `float` values with a max of 14 characters. So attempting to edit an address with a long lat/lon results in a validation error.
Reproduction steps
----------------------------------------
* Manually enter into the database a `geo_code_1` value of `-12.456789012345` on an address.
* Attempt to edit the address.
Current behaviour
----------------------------------------
![Screen_Shot_2021-02-09_at_9.47.59_AM](/uploads/7627d641a1580c9461916299a97f50d7/Screen_Shot_2021-02-09_at_9.47.59_AM.png)
```
TIP: The best way to convey an error message is to copy it in here and use
three backtick ` symbols. You may edit the message to remove private
information (like passwords). The backticks will help to preserve any
special characters or spaces.
```
Expected behaviour
----------------------------------------
Geocode shouldn't trigger validation errors.5.36.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2376Related Contributions for recurring contributions not sorted on date2023-06-26T05:03:16ZyashodhaRelated Contributions for recurring contributions not sorted on dateSteps to replicate :
- Go to Recurring Contributions tab for a contact with recurring contributions in place.
- Click _View_ for Recurring Contribution
- Go to _Related Contributions_ section and click the _Received_ column header.
- I...Steps to replicate :
- Go to Recurring Contributions tab for a contact with recurring contributions in place.
- Click _View_ for Recurring Contribution
- Go to _Related Contributions_ section and click the _Received_ column header.
- It is sorted on alphabetic order not date
![related_recurring](/uploads/6e6e03467a8aa3417f9d3c372d6adf63/related_recurring.png)https://lab.civicrm.org/dev/core/-/issues/2208Enforce default country setting globally2023-06-26T05:03:15ZandyburnsEnforce default country setting globallyIf you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used...If you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used in listings mode.
Noting @JonGold made an extension that solves this: https://civicrm.stackexchange.com/questions/20986/show-default-country-and-state-for-public-proximity-searchhttps://lab.civicrm.org/dev/core/-/issues/4056Replace hard-coded call to legacyCustomSearch framework with a hook2023-06-25T18:31:24ZeileenReplace hard-coded call to legacyCustomSearch framework with a hookWe should get the legacy custom search frame work out of our `GroupContactCache` BAO and eventually out of core code (and unhide the extension, with a view to not shipping enabled).
In order to do this I think we need a hook to get the ...We should get the legacy custom search frame work out of our `GroupContactCache` BAO and eventually out of core code (and unhide the extension, with a view to not shipping enabled).
In order to do this I think we need a hook to get the sql when loading a contact group
![image](/uploads/9ca4de13d7127a957e988ccea1a5c43b/image.png)
It might potentially wind up like this
![image](/uploads/6eebfb49b84cb35210c17de5a7eaf5e2/image.png)
I see there is handling for the sql being empty - which seems weird - but we could probably assume that if anything ever needs no sql it is not a custom search
Note that `CRM_Contact_BAO_SearchCustom` could be moved to the extension with the hook once as part of this as nothing else calls it
The other place where the legacy custom search framework returns sql is
![image](/uploads/e99dfdf4ba2fb66ac6e78c9f1cffc3b6/image.png)
Internally the first query calls the same `contactIDs`
![image](/uploads/88c6ff1481188c0f666b6309cb01b25b/image.png)
@colemanw @seamuslee @DaveDhttps://lab.civicrm.org/dev/core/-/issues/4016Import improvements2023-06-25T18:15:01ZeileenImport improvementsTracking issue for improvements I'd still like to look at
- import templates https://lab.civicrm.org/dev/core/-/issues/4015
Some quick notes that I haven't spun off into issues
- the links from the search go to the import landing pa...Tracking issue for improvements I'd still like to look at
- import templates https://lab.civicrm.org/dev/core/-/issues/4015
Some quick notes that I haven't spun off into issues
- the links from the search go to the import landing page - I think the search kit summary + detailed view (2 links) might be better as an and or an or to that
- ~~when looking at the detailed view the 'import' action only works on rows that are 'validated' - this makes sense in the main import as it doesn't try to import invalid rows but needs some tweaking in that workflow~~ - fixed
- ~~The label for `entity_id` is not the relevant entity in the search display - tracking progress here https://github.com/civicrm/civicrm-core/pull/25097~~ fixed
- I tried embedding a SearchDisplay into the summary/progress screen - https://github.com/civicrm/civicrm-core/pull/25087 - I got it working but the flickering was an issue. Closing the PR & tracking here to think about furtherhttps://lab.civicrm.org/dev/core/-/issues/2185Exceptions - lets do what we said we would do2023-06-25T05:03:22ZeileenExceptions - lets do what we said we would doAnd I quote https://github.com/civicrm/civicrm-core/blob/fdf73b0db343733c70bf217ffd121d4cb3f03480/CRM/Core/TemporaryErrorScope.php
This is an evil, evil work-around for CRM-11043. It is used to
* temporarily change the error-handling b...And I quote https://github.com/civicrm/civicrm-core/blob/fdf73b0db343733c70bf217ffd121d4cb3f03480/CRM/Core/TemporaryErrorScope.php
This is an evil, evil work-around for CRM-11043. It is used to
* temporarily change the error-handling behavior and then automatically
* restore it -- that protocol is an improvement over the current protocol
* (in which random bits of code will change the global error handler
* setting and then forget to change it back). This class and all
* references to it should be removed in 4.3/4.4 (when we adopt
* exception-based error handling).https://lab.civicrm.org/dev/core/-/issues/2378Status of relationships is not under the control of administrators2023-06-24T05:03:19ZUpperholmeStatus of relationships is not under the control of administratorsOverview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control...Overview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control of administrators, and nor is it explicit under what circumstances the nature of a given relationship might change.
https://civicrm.stackexchange.com/questions/28465/how-do-relationships-become-disabled
I raised the question nearly two years ago, and since that time there have been a number of responses on the SE site, some of which I find quite surprising. What is evident is that there are circumstances where a given relationship becomes disabled without the explicit knowledge or consent of administrators. As far as I'm aware there are no settings to control these behaviours.
In my own case I look after a site where memberships are a key driver. The members are organisations, and the memberships are configured such than individuals with an employee/employer relationship have the benefit of membership. This includes inclusion on mailing lists which are driven by smart groups, access to member-only content, event discounts, etc.
What I'm seeing is that employee/employer relationships are often disabled, despite the fact that the team that manages the CRM very rarely uses start or end dates for relationships (we rarely have this information). So, when a relationship is created it should stay enabled until such time as it is manually disabled. We'll manually disable a relationship relatively rarely, when we get information that a person has changed jobs or retired, but this is really very infrequent.
What does happen a lot with our system is that records get merged. People register on the site for events, or sign up for a mailing list, etc., and provide inaccurate information which often leads to duplicate records getting created. So there is a regular day to day activity of spotting and merging duplicates. It is therefore my guess - and it is purely guesswork - that it is this act of merging which is leading to relationship records getting disabled.
What should happen:
-------------------------
If there are rules that are working in the background that are leading to relationships getting disabled, and the information in the Stack Exchange post suggests that there are, then these should be:
1. Made explicit in the documentation, and
1. Controls should be provided either in the UI (preferably), or via the civicrm.settings.php file, whereby site administrators can enable or disable these rules of behaviour.
1. Where a suitably privileged user carries out an action that results in a relationship being disabled an on-screen alert should be displayed, with a link to enable the user to override that disablement.
If there are no rules or background systems that are driving these silent disablements, then there's a nasty bug.https://lab.civicrm.org/dev/core/-/issues/298API Explorer shows incorrect syntax for arrays via drush/cv2023-06-24T05:03:19ZJonGoldAPI Explorer shows incorrect syntax for arrays via drush/cvThe problem I'm seeing is displayed in the attached screenshot. When you create an API call with API Explorer that requires the use of an array, API Explorer adds the array, JSON-encoded, to the argument list. However, neither drush no...The problem I'm seeing is displayed in the attached screenshot. When you create an API call with API Explorer that requires the use of an array, API Explorer adds the array, JSON-encoded, to the argument list. However, neither drush nor cv (and I assume wp-cli) will parse the argument as an array. This has tripped up multiple folks on Stack Exchange ([1](https://civicrm.stackexchange.com/questions/10887/can-i-chain-api-calls-through-drush), [2](https://civicrm.stackexchange.com/questions/16423/passing-json-objects-to-drush-cvapi)).
As answers to those SE questions point out, it IS possible to use drush/cv and encode arrays. Instead of:
```
cv api Contact.create contact_type="Individual" first_name="Jon" options={"match":"first_name"}
```
We could do:
```
echo '{"contact_type":"Individual","first_name":"Jon","options":{"match":"first_name"}}' | cv api Contact.create --in=json
```
There are three solutions of increasing effort, depending on how important folks think this is. I'm willing to do the first one, and someone else can do 2 or 3 if they feel it's important.
1) Patch API Explorer so drush/cv/wp always show the (more complex) `echo foo | cv api bar.baz --in=json` syntax.
2) Patch API Explorer so drush/cv/wp show the more complex syntax when an array is present (I can do this if it's simple, I'd have to look).
3) Patch drush/wp/cv to match API Explorer.
![Selection_544](/uploads/1335415c85a5e6aaf9f185c023ce4c25/Selection_544.png)https://lab.civicrm.org/dev/core/-/issues/25Wrap split_jobs in a transaction2023-06-23T17:54:22ZseamusleeWrap split_jobs in a transactionThe split_jobs function should be wrapped in a MySQL transaction to ensure that no mailing can be delivered whilst we are still trying to populate the mailing_job table with all the necessary jobs.The split_jobs function should be wrapped in a MySQL transaction to ensure that no mailing can be delivered whilst we are still trying to populate the mailing_job table with all the necessary jobs.5.1.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/24Passing an array for contact_id/client_id to Case.Create API when updating an...2023-06-23T17:54:22Zmattwiremjw@mjwconsult.co.ukPassing an array for contact_id/client_id to Case.Create API when updating an existing case causes case to be "reassigned"The contact_id/client_id for the case supports multiple ids. It can be passed to the case.create API either as a single value or as an array. However, the code is inconsistent in it's handling of contact_id and expects it to be both an...The contact_id/client_id for the case supports multiple ids. It can be passed to the case.create API either as a single value or as an array. However, the code is inconsistent in it's handling of contact_id and expects it to be both an array and a single value. The result is that if an array is passed in it will fail to detect that an existing case contact_id already matches and it will "reassign" the case to the default contact id (1). This issue was identified because of inconsistent behaviour when submitting case/activity updates via webform_civicrm.
The proposed solution is to ensure that contact_id is always an array, and then check the first element against the original contact id.https://lab.civicrm.org/dev/core/-/issues/23Upgrade to version 4.7.31 seems to have broken DAO.PHP2023-06-23T17:54:22ZhetclubUpgrade to version 4.7.31 seems to have broken DAO.PHPVersion 4.7.31 was installed and now an hourly cron job is erroring like this:
"Parse error: syntax error, unexpected '[' in /.../administrator/components/com_civicrm/civicrm/CRM/Core/DAO.php on line 651.Version 4.7.31 was installed and now an hourly cron job is erroring like this:
"Parse error: syntax error, unexpected '[' in /.../administrator/components/com_civicrm/civicrm/CRM/Core/DAO.php on line 651.https://lab.civicrm.org/dev/core/-/issues/22Unable to delete Smart Group2023-06-23T17:54:22ZKarinGUnable to delete Smart Groupcivicrm mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_temp_group_contact_cache1416 (SELECT 565 as gr...", "1139 ** Got error 'empty (sub)expression' from regexp")
post upgrade from 4.6 -> 4.7 -> ...civicrm mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_temp_group_contact_cache1416 (SELECT 565 as gr...", "1139 ** Got error 'empty (sub)expression' from regexp")
post upgrade from 4.6 -> 4.7 -> Smart Groups with Children are broken (can't view Contacts; can't Delete; can't edit Search Criteria); relevant part of the critical Error in ConfigAndLog:
#6 /var/www/civicrm/4.7/packages/DB/mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_temp_group_contact_cache1416 (SELECT 565 as gr...", "1139 ** Got error 'empty (sub)expression' from regexp")
Have advised client to recreate these Smart Groups; raising here for awareness;