Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-11-01T18:20:41Zhttps://lab.civicrm.org/dev/core/-/issues/4484Feature request: New contact buttons on the API 4 autocomplete widget2023-11-01T18:20:41ZbrienneFeature request: New contact buttons on the API 4 autocomplete widgetOverview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such a...Overview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such as for selecting a Contributor on a backend contribution.
![Selection_015](/uploads/30fc0ecdd3268ebc5906ce0aa06dae9a/Selection_015.png)
Example use-case
----------------------------------------
1. Add the *Existing Contact* field to a FormBuilder form
1. A user can look up a contact to select, but if there are no results/a new one is needed, they can click a **New Individual** button to add one without being redirected from the original form
Current behaviour
----------------------------------------
The APIv4 autocomplete widget does not allow for creating new contacts.
![Selection_014](/uploads/d97659f7dddfd4858bd316acb0dda2b6/Selection_014.png)
Proposed behaviour
----------------------------------------
The APIv4 autocomplete widget should have feature parity when it comes to creating new contacts on the spot as the Select2 optionhttps://lab.civicrm.org/dev/core/-/issues/4466Roles - Define default taxonomy (for standalone deployments)2023-12-04T21:13:40ZtottenRoles - Define default taxonomy (for standalone deployments)Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* ...Now that we have a mechanism for [defining users and roles in standalone](https://lab.civicrm.org/dev/core/-/issues/4053), there's another question: What roles should we define by default? How do we maintain those roles? A few ideas:
* __Light-touch with open taxonomy.__ This is what D7 does -- you just get 2-3 roles (anonymous, authenticated, admin). Then the site-builder can fill-in more roles to taste. When you upgrade, you may need to re-tune the roles.
* __Strong defaults with hackable taxonomy__ This is what WP does -- you get several roles out-of-the-box. Site-builders are not particularly encouraged to refine them, but it is possible (esp using APIs/add-ons). When you upgrade, it can (*I assume*) add or update roles.
* __Library of example roles__: This idea comes from looking at Google Cloud -- they have an extensive library of roles. Some of the roles are similar/overlapping (e.g. there are older and newer flavors of "File Admin"/"Storage Admin"). The upshot is that you get a presumption of continuity while still allowing the taxonomy to evolve. The downside is that the list is a bit overwhelming. But treating these as templates might mitigate that (*library of possible roles is long -- but the local site only enables a handful*).
There are some related questions - if you have strong defaults or a library of examples, then how do you deal with extensions (*i.e. the list of available perms may fluctuate depending on the extensions*).https://lab.civicrm.org/dev/core/-/issues/4465Afform - Default value for boolean filters not displayed correctly in all fie...2023-11-06T00:00:55Zxavi-xalocAfform - Default value for boolean filters not displayed correctly in all field types## Overview
A PR (https://github.com/civicrm/civicrm-core/pull/25605) has been merged to solve issues ( https://lab.civicrm.org/dev/core/-/issues/4113, for instance) with default values for booleans filters in Search Kit. Although that ...## Overview
A PR (https://github.com/civicrm/civicrm-core/pull/25605) has been merged to solve issues ( https://lab.civicrm.org/dev/core/-/issues/4113, for instance) with default values for booleans filters in Search Kit. Although that PR solves many of the issues identified, some problems still remain.
## Current behaviour
Although filter works fine when the field is of type "radio button", that's not the case when the type is "select" or "checkboxes":
- Select: Works fine when "yes" is the default value, but doesn't show default value when it is set to "no"
- Checkboxes: Doesn't get checked when default value is set to "yes".
## Environment information
* **CiviCRM:** _5\.61.2_Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/4459Uncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLoca...2023-08-04T12:51:55ZyurgUncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLocationTypeLabel() must be of the type string, null returnedOverview
----------------------------------------
WordPress contacts import from CSV, CiviCRM 5.61.2. (not reproduceable on dmaster).
https://civicrm.stackexchange.com/questions/45332/contacts-import-issue-at-crm-contact-import-form-map...Overview
----------------------------------------
WordPress contacts import from CSV, CiviCRM 5.61.2. (not reproduceable on dmaster).
https://civicrm.stackexchange.com/questions/45332/contacts-import-issue-at-crm-contact-import-form-mapfieldgetlocationtypelabel
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Import Contacts**.
2. Add a CSV file, leave all settings intact and click **Continue**.
3. Got a Wordpress WSOD and php error log message "**Uncaught TypeError: Return value of CRM_Contact_Import_Form_MapField::getLocationTypeLabel() must be of the type string, null returned in /data/sites/web/pedesdev/www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.php:480**".
Expected behaviour
----------------------------------------
Process to the next import step
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.61.2
* PHP: 7.4.3
Comments
----------------------------------------
Fixed by changing from
- protected function getLocationTypeLabel($type): string {
to
- protected function getLocationTypeLabel($type): ?string {
in www/wp-content/plugins/civicrm/civicrm/CRM/Contact/Import/Form/MapField.php:480
however not sure if this is the right way.https://lab.civicrm.org/dev/core/-/issues/4456Saving event with custom file field gives fatal error2024-02-07T19:47:09ZwouterhSaving event with custom file field gives fatal error1. Create a file field for event(s).
1. Go to an existing event containing this custom file field – Press save.
1. Red alert box "network error" and the custom fields don't display.
`TypeError: Cannot access offset of type string on st...1. Create a file field for event(s).
1. Go to an existing event containing this custom file field – Press save.
1. Red alert box "network error" and the custom fields don't display.
`TypeError: Cannot access offset of type string on string in include() (regel 59 van /var/www/html/web/sites/default/files/civicrm/templates_c/nl_NL/%%1D/1DB/1DB03A28%%CustomField.tpl.php).`
Using CiviCRM 5.62.0 & PHP 8. Doesn't happen in PHP 7.5.71.0https://lab.civicrm.org/dev/core/-/issues/4451parent_id constraint on civicrm_activity can lead to data loss2023-08-08T22:21:55ZDaveDparent_id constraint on civicrm_activity can lead to data lossIt has probably always been like this but it seems dangerous.
1. Create an activity.
1. Let's give it subject "a1" so we can tell it apart.
1. Fill out the schedule followup section at the bottom. Give it subject "a2".
1. Save.
1. Delet...It has probably always been like this but it seems dangerous.
1. Create an activity.
1. Let's give it subject "a1" so we can tell it apart.
1. Fill out the schedule followup section at the bottom. Give it subject "a2".
1. Save.
1. Delete activity "a1".
Expected result: Just a1 is deleted.
Actual result: a1 and a2 are both deleted.
The constraint should be ON DELETE SET NULL.
As with the fix for original_id, in a large db an upgrade script might timeout or take a long time, so would need to direct the user to do it manually.5.64.0https://lab.civicrm.org/dev/core/-/issues/4450Standalone: set the page title2023-11-28T19:33:31ZbgmStandalone: set the page titleCurrently the `<title>` attribute (in head) is empty.Currently the `<title>` attribute (in head) is empty.RichRichhttps://lab.civicrm.org/dev/core/-/issues/4449Status check about accessible dirs can be slow2023-07-26T23:18:26ZDaveDStatus check about accessible dirs can be slowThis is a followup to https://github.com/civicrm/civicrm-core/pull/26771#issuecomment-1629756698 and https://github.com/civicrm/civicrm-core/pull/26889.
Putting more info than needed in here cuz I already typed it.
I think the speedup ...This is a followup to https://github.com/civicrm/civicrm-core/pull/26771#issuecomment-1629756698 and https://github.com/civicrm/civicrm-core/pull/26889.
Putting more info than needed in here cuz I already typed it.
I think the speedup in 26889 wasn't quite a "fix", and there was maybe more than one issue there. In general as noted in 26771 servers that only handle one request at a time, synchronously, will have trouble with these checks because of deadlock, i.e.
```
> (caller) call for status check
=> (server) hello, processing
> call for file
=> hello, hold please
... second caller hangs up eventually ...
> first request can now finish
=> server switches phone line to caller on hold => oh you're not there anymore, ok.
```
And a gotcha during testing is it's not sufficient to just simulate the second GET using tool X (browser, curl-cli, cv, etc), it needs to be the combo of doing the GET from within code that is triggered by the first GET.
For the php built-in webserver, while the `isBrowsable` check could be legit, the status check about `isDirAccessible` might give a false positive even if it _was_ working, since .htaccess files don't do anything for the built-in webserver, and there's no nginx-like config you could do to secure it. So maybe it is best to just skip this check for built-in, in which case I would skip it for all php versions not just `<8`.
But in general, to make this work with one-request-at-a-time servers seems like it would require an architecture redesign. Using guzzle/curl to specify a timeout makes the time shorter, so is an improvement, but it doesn't seem possible to ever get a correct result for `isDirAccessible` on these servers at the moment, and at least for the built-in one, we already know it's not possible to prevent GET'ing files under sites/default/files/civicrm.
I don't know a way to detect if a (potentially remote) server is one-request-at-a-time, without just waiting for a timeout. Ideally the check would be skipped for _any_ such server.
So let's do as much as we can: Use guzzle/curl to set the shorter timeout, and skip for the known built-in server.5.65.0https://lab.civicrm.org/dev/core/-/issues/4445Upgrade to 5.65 shows incorrect message about Petition - Signature Added mess...2023-07-27T01:33:29ZlarsssandergreenUpgrade to 5.65 shows incorrect message about Petition - Signature Added message template upgradeWhen upgrading to 5.65 on a recently rebuild install with no customization of any message templates, the following message appears:
The default copies of the message templates listed below will be updated to handle new features or corre...When upgrading to 5.65 on a recently rebuild install with no customization of any message templates, the following message appears:
The default copies of the message templates listed below will be updated to handle new features or correct a problem. Your installation has customized versions of these message templates, and you will need to apply the updates manually after running this upgrade. View detailed instructions.
Petition - signature added - Update to use tokens
---
@eileen, looks like this is from [#26546](https://github.com/civicrm/civicrm-core/pull/26546).5.65.0https://lab.civicrm.org/dev/financial/-/issues/216Financial Batches: remove the creation of activities for New/Edit2023-08-09T18:28:27ZbgmFinancial Batches: remove the creation of activities for New/EditI fell down a rabbit hole while testing the New Financial Batch form, and noticed that it creates an activity whenever a batch is created or edited. It also creates an activity when the batch is exported, but not when closed or deleted.
...I fell down a rabbit hole while testing the New Financial Batch form, and noticed that it creates an activity whenever a batch is created or edited. It also creates an activity when the batch is exported, but not when closed or deleted.
The "Create Batch" and "Edit Batch" activities do not seem useful to me. I would leave the "Export Accounting Batch" activity for now.
Any objections to removing?
(I'm creating this issue for visibility, but will send a PR that might be more clear)
cc @JoeMurray5.66.0https://lab.civicrm.org/dev/user-interface/-/issues/51Remove top buttons on backend forms2023-07-20T20:48:51ZbgmRemove top buttons on backend formsBackend CiviCRM forms can be overwhelming. It's not always obvious why. Few people will say "oh my, those buttons are overwhelming", because it's obvious what they do, but every bit of redundant information becomes a bit more clutter tha...Backend CiviCRM forms can be overwhelming. It's not always obvious why. Few people will say "oh my, those buttons are overwhelming", because it's obvious what they do, but every bit of redundant information becomes a bit more clutter that the brain has the process.
For example, New Price Set form:
![image](/uploads/ce63e54d411ea9a289ad8aecb7284db5/image.png)
Removing the top buttons means that the eye can go directly to filling in the form (although, that help message eh.. but that's another topic):
![image](/uploads/a288a65ddbc2f788bf2d47d4f8949ae8/image.png)
I know we want interfaces to be consistent, and I would apply that kind of fix to most forms, unless there is a really good reason not to (ex: frontend contribution review form).
Some people might miss those buttons, but I think most new and regular users will be happy to see them go away. Personally I often hide them in CSS, but I'm trying to push for more core improvements, less hacks.
cc @larssg @artfulrobot @nicol @yashodha @mattwire (you have expressed interest on this topic in the past)5.65.0https://lab.civicrm.org/dev/core/-/issues/4426Standalone: currentPath returns null2023-08-20T19:28:14ZbgmStandalone: currentPath returns nullThis is mostly visible when using the language-switcher extension. `CRM_Utils_System::currentPath()` returns NULL, so the extension cannot generate proper URLs. It's presumably going to cause problems elsewhere.
The function does this:...This is mostly visible when using the language-switcher extension. `CRM_Utils_System::currentPath()` returns NULL, so the extension cannot generate proper URLs. It's presumably going to cause problems elsewhere.
The function does this:
```
public static function currentPath() {
$config = CRM_Core_Config::singleton();
return isset($_GET[$config->userFrameworkURLVar]) ? trim($_GET[$config->userFrameworkURLVar], '/') : NULL;
}
```
and when using Standalone, `$config->userFrameworkURLVar` is set to `q` (default value), and `$_GET['q']` is not set.
For Drupal9, we still apply this patch: https://github.com/civicrm/civicrm-core/pull/15267/files (I didn't revive the PR, because apparently we're the only ones having the issue, so maybe it's related to our hosting).5.66.0https://lab.civicrm.org/dev/core/-/issues/4425Standalone: language change does not stick2023-12-02T12:21:46ZbgmStandalone: language change does not stickTo reproduce:
- Administer > System Settings > Extensions: Enable the [update language](https://civicrm.org/extensions/update-language-files) extension, saves time, if you haven't already downloaded the translation files
- Administer > ...To reproduce:
- Administer > System Settings > Extensions: Enable the [update language](https://civicrm.org/extensions/update-language-files) extension, saves time, if you haven't already downloaded the translation files
- Administer > Localization > Languages: Enable two languages (no need for multilingual, just enable a second language)
You should then be able to display pages in different languages, using the `lcMessages=xx_YY` parameter. Ex:
- https://crm.example.org/civicrm?lcMessages=en_US
- https://crm.example.org/civicrm?lcMessages=fr_CA (adapt to the locale you enabled)
This works for a single page. However, CiviCRM should normally save the language in the `$session` object. See `CRM_Core_BAO_ConfigSetting::applyLocale`. It does not seem to be happening.
(I'll try to circle back, just wanted to log my findings so far)5.69.0https://lab.civicrm.org/dev/civicrm-asset-plugin/-/issues/23Scheduled jobs stopped working after an update last week - error in MailingEv...2023-07-10T09:24:27ZTobias KrauseScheduled jobs stopped working after an update last week - error in MailingEventUnsubscribe.phpI realized this morning that the CiviCRM cron job for the scheduled jobs stopped working after we updated last week from CiviCRM 5.61.2 to 5.61.4. Today I updated to the most current version 5.63.1 but the error still exists.
The proble...I realized this morning that the CiviCRM cron job for the scheduled jobs stopped working after we updated last week from CiviCRM 5.61.2 to 5.61.4. Today I updated to the most current version 5.63.1 but the error still exists.
The problem became obvious as the message "Cron job not running" appeared when I logged in this morning (I did not so for the whole last week). When I checked the list of scheduled jobs I found out that the "Bounces fetcher" job run successfully but all the other jobs did not. So I run our cron job task
`/var/www/civi_live/vendor/civicrm/cv/bin/cv api job.execute --user=admin --cwd=/var/www/civi_live/httpdocs`
manually in CLI and got the following error:
```
In MailingEventUnsubscribe.php line 47:
count(): Argument #1 ($value) must be of type Countable|array, null given
```
The following file is the one: vendor/civicrm/civicrm-core/api/v3/MailingEventUnsubscribe.php
Here it is the following code part in the function civicrm_api3_mailing_event_unsubscribe_create:
```
$groups = CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing($job, $queue, $hash);
if (count($groups)) {
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::send_unsub_response($queue, $groups, FALSE, $job);
return civicrm_api3_create_success($params);
}
```
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing can return an array or NULL. I am not sure why this error appeared after the last update as neither CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing nor civicrm_api3_mailing_event_unsubscribe_create() has changed but it may be related to some other changes somewhere.
When I change this code part to the following the scheduled jobs are finished:
```
$groups = CRM_Mailing_Event_BAO_MailingEventUnsubscribe::unsub_from_mailing($job, $queue, $hash);
if ($groups && count($groups)) {
CRM_Mailing_Event_BAO_MailingEventUnsubscribe::send_unsub_response($queue, $groups, FALSE, $job);
return civicrm_api3_create_success($params);
}
```https://lab.civicrm.org/dev/core/-/issues/4417API 4 Explorer output is inconsistent for serialized fields in JSON view2023-07-07T15:10:50ZlarsssandergreenAPI 4 Explorer output is inconsistent for serialized fields in JSON viewEdit: See discussion below.
~~If we use API 4 to save JSON values for a JSON field, the JSON gets mucked up because the API expects an array. I suppose this works in a sense, but in another sense it is weird that you can't, for example,...Edit: See discussion below.
~~If we use API 4 to save JSON values for a JSON field, the JSON gets mucked up because the API expects an array. I suppose this works in a sense, but in another sense it is weird that you can't, for example, copy an entity by getting it from API 4 and then creating with the same values (because the API gives you JSON, but won't accept it).~~
~~If this is the expected behaviour, at least I can document it.~~
----
~~If we pass in `{"something": "thing"}`, what gets saved in the database is `[{"something": "thing"}]`.~~
~~If we use a save action and pass in a `records` array with a JSON value, what gets saved in the database is `["{\"something\": \"thing\"}"]`.~~https://lab.civicrm.org/dev/core/-/issues/4411Standalone language support2024-02-04T00:04:15ZRichStandalone language supportStandalone allows users to set their language, but does nothing with that information; languageNegotiationURL() does nothing.Standalone allows users to set their language, but does nothing with that information; languageNegotiationURL() does nothing.https://lab.civicrm.org/dev/core/-/issues/4410Standalone timezone support2024-02-07T10:31:42ZRichStandalone timezone supportIn standalone we have defined a timezone field on the user table, with the design that it should store data like `Europe/London`.
It seems that there's a `civicrm_timezones` table that, if populated, would provide suitable pseudoconstan...In standalone we have defined a timezone field on the user table, with the design that it should store data like `Europe/London`.
It seems that there's a `civicrm_timezones` table that, if populated, would provide suitable pseudoconstants.
For now the afform offers a free text field, which is going to be very fragile.
We need to understand what the process is for populating/updating the `civicrm_timezones` table, and then point to the `name` values in there for our `User.timezone` values.https://lab.civicrm.org/dev/core/-/issues/4409Translation for site default language not loaded2023-08-08T22:21:51ZeileenTranslation for site default language not loadedWhen configuring message templates the translation system allows for draft and approved statuses. However, these apply to the the translations, not the message templates.
In order to use the approval flow it is necessary to create a tra...When configuring message templates the translation system allows for draft and approved statuses. However, these apply to the the translations, not the message templates.
In order to use the approval flow it is necessary to create a translation for the site default language - at which point you would expect it to be used.
However, this line https://github.com/civicrm/civicrm-core/pull/26232/files#diff-466bc3af8c09d1d88e212c1465c6586e2d7187d27397e75f02e67436b1d4be13L181 currently causes the message template, not the tranlation to be called when the site default language is whistled up.
It's pretty clear that if you configure an English (United States) template you want it to be used but it gets more confusing for the expected behaviour for other languages - which should they fall back to. From a code / UI point of view this is not obvious but from a site usage point of view it is - ie
1) the whole reason for creating the translation for the site default language is to have the approval work flow - you don't want it to by bypassed for other languages that fall back to it and ...
2) you don't really want to have to be maintaining 2 templates for no added value.
The underlying issue is the lack of the statuses on the message templates and for any larger effort on this it would make sense to add it there & make the template obsolete.
It would perhaps also be possible to add a hook so that the message template is updated whenever the site default template with status=approved is updated. I worry a bit this could get confusing because there is an idea it could be turned back into a draft & then it would fall back on the message template again - but that would already have been updated.
It would also be possible to add more documentation / perhaps more UI notifications - although with little evidence other sites are using this and even if they have, have added translations for the default language I'm inclined to go with 'if someone translates the default language they did it so that it would be the one used' and make that work5.64.0https://lab.civicrm.org/dev/core/-/issues/4408Case Detail Report Template Missing City Field2023-07-05T03:43:28ZLKuttnerCase Detail Report Template Missing City FieldThe Case Detail report template is missing {contact.city} while all the other address fields are available. I do not know how long this has been like this, since we just began using this report. One thought I had was that this might be ...The Case Detail report template is missing {contact.city} while all the other address fields are available. I do not know how long this has been like this, since we just began using this report. One thought I had was that this might be caused by our using the Word replacement feature for City > Town, but disabling it did not help. This is with 59.5.4.
![Missing-City-Field](/uploads/d206a1e64547bdf40a778cd71f19a8c4/Missing-City-Field.PNG)https://lab.civicrm.org/dev/core/-/issues/4407SearchKit: Option to apply style to whole row2023-07-04T23:49:12Zaydunsaidan.saunders@squiffle.ukSearchKit: Option to apply style to whole rowThe most common use of `Style` conditionals for me is setting the `Style` to `Disabled` based on the `Enabled` field.
Currently this requires adding the same conditional to every field in the display.
Suggestion: allow a style to be ap...The most common use of `Style` conditionals for me is setting the `Style` to `Disabled` based on the `Enabled` field.
Currently this requires adding the same conditional to every field in the display.
Suggestion: allow a style to be applied to the whole row.colemanwcolemanw