Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-08-08T22:21:55Zhttps://lab.civicrm.org/dev/core/-/issues/4439PriceSet select options cause javascript errors2023-08-08T22:21:55ZbgmPriceSet select options cause javascript errorsTo reproduce:
- https://dmaster.demo.civicrm.org/civicrm/admin/price?reset=1
- Create a new Price Set, for Memberships
- Add a single field 'membership' of type Select, with the 3 membership options
Then go to a contact record:
- http...To reproduce:
- https://dmaster.demo.civicrm.org/civicrm/admin/price?reset=1
- Create a new Price Set, for Memberships
- Add a single field 'membership' of type Select, with the 3 membership options
Then go to a contact record:
- https://dmaster.demo.civicrm.org/civicrm/contact/view?reset=1&cid=204&selectedChild=member
- Add Membership
- Select the "Membership" Price Set
- Select a membership option from the select
The total will be $0.00 and the Javascript console will display an error:
> Uncaught TypeError: selectedText[option] is undefined
We noticed the error after upgrading to 5.63.1, previously 5.60.
It also happens with Contribution PriceSets.5.63.2https://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/4435Undefined index: payment_type2023-07-24T02:33:18ZJoeMurrayUndefined index: payment_typeOn dmaster I changed default contribution page to purchase memberships so it allowed pay later, went to live page and did a pay later payment for a $100 membership and got (on https://dmaster.demo.civicrm.org/civicrm/contribute/transact?...On dmaster I changed default contribution page to purchase memberships so it allowed pay later, went to live page and did a pay later payment for a $100 membership and got (on https://dmaster.demo.civicrm.org/civicrm/contribute/transact?_qf_Confirm_display=true&qfKey=CRMContributeControllerContribution4dhfkffigym8c4c8k0kos0ko00440gkg8008wss00gowwc8ckw_9868):
Notice: Undefined index: payment_type in CRM_Core_Payment->validatePaymentInstrument() (line 511 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Payment.php).
Dummy Payment processor is only defined payment processor and it is enabled.
Changing Fall Fundraising default event to allow Pay Later, then using Live page to do so, also results in an error on the confirm but not Thank You page (https://dmaster.demo.civicrm.org/civicrm/event/register?_qf_Confirm_display=true&qfKey=CRMEventControllerRegistrationxabxsqxsysgg88scss808ksog0o4okko84cw4ok0s0ss8cgsk_1767):
Notice: Undefined index: payment_type in CRM_Core_Payment->validatePaymentInstrument() (line 511 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Payment.php).5.65.0https://lab.civicrm.org/dev/core/-/issues/4430New validation of email not good very bad on the search screen2023-08-08T22:21:52ZeileenNew validation of email not good very bad on the search screen![image](/uploads/c0c27aa7091ebf30a316174f9b1dac23/image.png)
![image](/uploads/d8fb04672fe5e1c6a16857f2c5958769/image.png)![image](/uploads/c0c27aa7091ebf30a316174f9b1dac23/image.png)
![image](/uploads/d8fb04672fe5e1c6a16857f2c5958769/image.png)5.64.0https://lab.civicrm.org/dev/core/-/issues/4429Once you create a Membership price set, with membership options (ie Select) y...2023-08-08T22:21:53ZpetednzOnce you create a Membership price set, with membership options (ie Select) you cannot then add a new Option as the Membership fields are not displayingreplicated on WPMaster
- add price set for memberships
- add a SELECT field so you can set option 1 = Memb X and option 2 = Memb Y
- save
- try to add a new option to the above field, Memb Type and Number of Terms fields are not visiblereplicated on WPMaster
- add price set for memberships
- add a SELECT field so you can set option 1 = Memb X and option 2 = Memb Y
- save
- try to add a new option to the above field, Memb Type and Number of Terms fields are not visible5.64.0https://lab.civicrm.org/dev/core/-/issues/4427Deleted activities filter no longer working on manage case2023-08-08T22:21:52ZDaveDDeleted activities filter no longer working on manage case1. Delete a case activity.
2. On manage case expand the activity search filters and click the deleted checkbox.
3. Shows the same thing as when unchecked.
The ajax url in both cases has activity_deleted=0
Hmm, deja vu, but in reverse: ...1. Delete a case activity.
2. On manage case expand the activity search filters and click the deleted checkbox.
3. Shows the same thing as when unchecked.
The ajax url in both cases has activity_deleted=0
Hmm, deja vu, but in reverse: https://lab.civicrm.org/dev/core/-/issues/1022. This time the case_id is missing for this field.5.64.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/core/-/issues/4424Breakage with 5.63 moving code to extensions2023-07-27T21:22:32ZeileenBreakage with 5.63 moving code to extensionsWe are hitting a fatal error `Error: Class 'Civi\Api4\FinancialAccount' not found in include()` when we upgrade from 5.61 to 5.64.
The error is happening when it tries to reconcile managed entities because our mgd.php file inc...We are hitting a fatal error `Error: Class 'Civi\Api4\FinancialAccount' not found in include()` when we upgrade from 5.61 to 5.64.
The error is happening when it tries to reconcile managed entities because our mgd.php file includes a call to this api.
The Managed.reconcile is called before `addExtensionTask` resulting in it failing on the former because the latter has not yet run. It then fails to do the latter because it crashed out, although the domain version is correctly udpdated5.64.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/4419Membership tab on contribution page config broken2023-08-08T22:21:51ZDaveDMembership tab on contribution page config brokenI'm not sure of the details yet but `TypeError: Cannot access offset of type string on string in include() (line 95 of .../templates_c/en_US/%%B4/B40/B407902D%%MembershipBlock.tpl.php)`I'm not sure of the details yet but `TypeError: Cannot access offset of type string on string in include() (line 95 of .../templates_c/en_US/%%B4/B40/B407902D%%MembershipBlock.tpl.php)`5.63.1https://lab.civicrm.org/dev/core/-/issues/4418Accepted credit cards not saved when creating or editing a payment processor2023-08-08T22:21:51ZlarsssandergreenAccepted credit cards not saved when creating or editing a payment processor[This change](https://github.com/civicrm/civicrm-core/pull/25873/commits/df3b3799337a18ef22e059681ca36784d66f0f1b) in 5.61 makes it so that if you create or save a payment processor, accepted_credit_cards is not saved correctly. The prob...[This change](https://github.com/civicrm/civicrm-core/pull/25873/commits/df3b3799337a18ef22e059681ca36784d66f0f1b) in 5.61 makes it so that if you create or save a payment processor, accepted_credit_cards is not saved correctly. The problem is that the save was changed to API 4, which doesn't [properly handle JSON](https://lab.civicrm.org/dev/core/-/issues/4417) and accepted_credit_cards is one of the few JSON fields we have.
I think for now, we should just go back to API 3 and then we can switch back to API 4 when the JSON issue is resolved.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/4416🌶️ CiviCRM 5.63.0 - Regression, Mailing click tracking now returns: Error 500...2023-07-06T22:46:14Zjustinfreeman (Agileware)🌶️ CiviCRM 5.63.0 - Regression, Mailing click tracking now returns: Error 500 malformed header from script 'url.php': Bad header for all tracked URLsRegression, Mailing click tracking now returns: Error 500 malformed header from script 'url.php': Bad header for all tracked URLs
As a result, Mailing click tracking no longer works. This bug warrants a new CiviCRM release IMHO.
eg, ht...Regression, Mailing click tracking now returns: Error 500 malformed header from script 'url.php': Bad header for all tracked URLs
As a result, Mailing click tracking no longer works. This bug warrants a new CiviCRM release IMHO.
eg, https://flippythongs.org.au/wp-content/plugins/civicrm/civicrm/extern/url.php?u=4238&qid=201344 returns **Error 500**
Patch submitted, https://github.com/civicrm/civicrm-core/pull/26747/
Version: CiviCRM 5.63.05.63.1https://lab.civicrm.org/dev/core/-/issues/4414CiviCRM 5.62.1 - CiviCRM core extension: Greenwich, Bootstrap CSS tries to lo...2023-08-08T22:21:55Zjustinfreeman (Agileware)CiviCRM 5.62.1 - CiviCRM core extension: Greenwich, Bootstrap CSS tries to load glyphicons fonts from the incorrect paths returns 404 and icons do not displayCiviCRM core extension: Greenwich, Bootstrap CSS tries to load glyphicons fonts from the incorrect paths returns 404 and icons do not display.
- civicrm/ext/greenwich/fonts/glyphicons-halflings-regular.woff2
- civicrm/ext/greenwich/font...CiviCRM core extension: Greenwich, Bootstrap CSS tries to load glyphicons fonts from the incorrect paths returns 404 and icons do not display.
- civicrm/ext/greenwich/fonts/glyphicons-halflings-regular.woff2
- civicrm/ext/greenwich/fonts/glyphicons-halflings-regular.woff
- civicrm/ext/greenwich/fonts/glyphicons-halflings-regular.ttf
Correct path is:
civicrm/ext/greenwich/extern/bootstrap3/assets/fonts/bootstrap/glyphicons-halflings-regular.ttf
This error is shown in the Web Console when loading the Mosaico Template Editor to create or edit a Mailing.
civicrm/ext/greenwich/dist/bootstrap3.css
```
@font-face {
font-family: "Glyphicons Halflings";
src: url("../fonts/glyphicons-halflings-regular.eot");
src: url("../fonts/glyphicons-halflings-regular.eot?#iefix") format("embedded-opentype"), url("../fonts/glyphicons-halflings-regular.woff2") format("woff2"), url("../fonts/glyphicons-halflings-regular.woff") format("woff"), url("../fonts/glyphicons-halflings-regular.ttf") format("truetype"), url("../fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular") format("svg");
}
```
Version: CiviCRM 5.62.1
Agileware Ref: CIVICRM-2149https://lab.civicrm.org/dev/core/-/issues/4413Disabling and re-enabling a core extension removes it from the navigation men...2023-08-08T22:21:49ZlarsssandergreenDisabling and re-enabling a core extension removes it from the navigation menu and from SKIf you disabled and re-enable a core extension, you lose the relevant navigation menu item and you lose some of the relevant entities in SK. For example, if you disable and re-enable civi_mail, you lose the Mailing menu item and the Mail...If you disabled and re-enable a core extension, you lose the relevant navigation menu item and you lose some of the relevant entities in SK. For example, if you disable and re-enable civi_mail, you lose the Mailing menu item and the Mailings and Outbound Mailings entities disappear from SearchKit (but Mailing Bounces, etc are still present). Similar with civi_member. Cache clearing or menu rebuilding doesn't help. On dmaster.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)