Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-07-26T23:18:26Zhttps://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/4447When importing/updating persons, taking over the address of another contact d...2023-12-06T23:39:37ZhstrugallaWhen importing/updating persons, taking over the address of another contact does not work.## Overview
When importing/updating persons, taking over the address of another contact (organisation) via CiviCRM Field "Master address belongs to" does not work.
The import job runs without errors, but the address was not assigned.
...## Overview
When importing/updating persons, taking over the address of another contact (organisation) via CiviCRM Field "Master address belongs to" does not work.
The import job runs without errors, but the address was not assigned.
## Reproduction steps
1. Find out the "Address ID" of the organisation (via phpMyAdmin or "Export contacts" -\> field "Address ID")
![get address ID.png](/uploads/8e608df7b4aa82f965e7beb8d605e29e/get_address_ID.png){width="405" height="177"}
2. Create the CSV import/update file.
[Import.csv](/uploads/5a47efab4cdf034eb7fbb522417d089e/Import.csv)
3. Click on **Contacts -\> Import Contacts**.
4. Fill out forms (see pictures)
![import 1.png](/uploads/39360a48a638b65b4d444f31ca6efedd/import_1.png){width="661" height="289"}
![import 2.png](/uploads/3ba8d1f31f0af56ff68bab39f2f96dde/import_2.png){width="664" height="189"}
5. Run import/update
## Current behaviour
No error during import, but the address was not taking over.
## Expected behaviour
The company address should be assigned to the person.
## Environment information
* **Browser:** _Firefox 115.0.2 (64-Bit)_
* **CiviCRM:** _5\.55.2_
* **PHP:** \_7.4.3-4ubuntu2.18\_
* **CMS:** _WordPress 6.1.1_
* **Database:** _Ver 8.0.33-0ubuntu0.20.04.2_
* **Web Server:** _Apache/2.4.41 (Ubuntu)_
## Comments
It seems, the code to handle "Master address belongs to" during the import/update of contacts not exists in CiviCRM core in version 5.55.2.5.69.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/core/-/issues/4444Multilingual problem with required title fields2023-09-02T01:47:32ZeileenMultilingual problem with required title fieldsWe recently made `contribution_page.title` and some similar fields required. However, I just discovered that `testGitLabIssue1108` fails locally and the reason feels like it has implications
The test fails because when multilingual is d...We recently made `contribution_page.title` and some similar fields required. However, I just discovered that `testGitLabIssue1108` fails locally and the reason feels like it has implications
The test fails because when multilingual is disabled it does an INSERT for en_US but the value for fr_FR is not set - which fails due to the change making title_fr_FR required.
I don't know why this didn't surface before but I suspect we need to make required fields of type text have different sql attributes - ie probably a default of ''5.66.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/core/-/issues/4443Error "Participant record without event ID. You have invalid data in your dat...2023-07-24T03:39:55ZDaveDError "Participant record without event ID. You have invalid data in your database" appearing in logPutting regression since this feels like something recent.
1. From a contact summary from the actions dropdown, register for event.
2. Pick an event.
3. Check the box to send an email.
4. Click Save.
5. In the civi log it says "Particip...Putting regression since this feels like something recent.
1. From a contact summary from the actions dropdown, register for event.
2. Pick an event.
3. Check the box to send an email.
4. Click Save.
5. In the civi log it says "Participant record without event ID. You have invalid data in your database!". Everything seems ok though.
Note this only happens when registered from the contact summary. If you do it from Event - Register Event Participant it doesn't happen.https://lab.civicrm.org/dev/core/-/issues/4441Error "There might be a data problem, contribution id could not be loaded fro...2023-08-31T03:17:17ZDaveDError "There might be a data problem, contribution id could not be loaded from the line item"I've been seeing this the last two days or so on event registrations. Not sure yet what it's from but it's something new. Easy to reproduce:
1. Events - Register Event Participant.
2. Pick a contact.
3. Pick an event.
4. Click save.
Se...I've been seeing this the last two days or so on event registrations. Not sure yet what it's from but it's something new. Easy to reproduce:
1. Events - Register Event Participant.
2. Pick a contact.
3. Pick an event.
4. Click save.
Seems to be in 5.64 but not 5.63.5.64.0https://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 &#039;Civi\Api4\FinancialAccount&#039; 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\"}"]`.~~