Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-10-21T07:38:27Zhttps://lab.civicrm.org/dev/backdrop/-/issues/54drush ci load_generated_data always true if flag present2022-10-21T07:38:27Zbgmdrush ci load_generated_data always true if flag present*Created by: tabroughton*
When reading the description for the civicrm-install drush command the flag load_generated_data is stated to default to FALSE - this suggests that setting the flag to TRUE will generate the data (and it does).
...*Created by: tabroughton*
When reading the description for the civicrm-install drush command the flag load_generated_data is stated to default to FALSE - this suggests that setting the flag to TRUE will generate the data (and it does).
However, setting any value against load_generated_data will also load the data, in fact just having the flag present when running the command will generate the data. This isn't terrible but it doesn't match the other flag settings which all accept a value. Also the description suggests setting the value to FALSE would not load the data but it does.
I suggest being able to set true or false explicitly (where false is default if not present) would be the better solution here.https://lab.civicrm.org/dev/drupal/-/issues/193drush: use \Civi\Setup instead of custom installer2024-02-14T09:52:26Zbgmdrush: use \Civi\Setup instead of custom installerInitial discussion: https://github.com/civicrm/civicrm-core/pull/29242#issuecomment-1926066031
The old installer would rely on having the l10n files installed with both the 'mysql' files and the 'mo' files. The newer `\Civi\Setup`, whic...Initial discussion: https://github.com/civicrm/civicrm-core/pull/29242#issuecomment-1926066031
The old installer would rely on having the l10n files installed with both the 'mysql' files and the 'mo' files. The newer `\Civi\Setup`, which is used by the Drupal 7/10 UI and by WordPress and Joomla, runs the mysql files through `ts` at run-time, so it's not necessary to generate those files anymore.
The last bastion is in the drush 8 functions, which presumably no-one uses anymore except Aegir users.
(I have pending PRs and will link them here)https://lab.civicrm.org/dev/core/-/issues/2966Duplicate contacts when custom field value is 'email', 'phone', etc.2023-03-18T04:08:01Zrita_compucorpDuplicate contacts when custom field value is 'email', 'phone', etc.**Issue**:
when existing contacts are donating (without being logged in) with the same details (email, first name, last name) that are registered in the system, most of the times there is a new contact created instead of merging it to t...**Issue**:
when existing contacts are donating (without being logged in) with the same details (email, first name, last name) that are registered in the system, most of the times there is a new contact created instead of merging it to the existing contact automatically.
**Investigation**:
When a custom field with a checkbox had its title and value set to ‘email’ or 'phone' and the unsupervised dedupe rule was prepared to check for email or phone as well causing the problem. So the problem occurs when:
- the unsupervised dedupe rule has email in it AND
- the custom field’s value is set to ‘email’
However not only the email option can cause duplications, but if you prepare an:
- unsupervised dedupe rule with phone ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24](/uploads/758592a6d5330c1133dcd1206e714daa/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24.png) AND
- the custom field’s value is set to ‘phone’ ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12](/uploads/df40ee69692fda55f51e946b2c841b9d/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12.png)
And even though the clients enter the same email/phone numbers on the donation form, the dedupe rule will be skipped and a new contact with the same information will be created. Probably this can be reproduced with many fields in the system, but only tried these two.
I checked on a few **different civi versions:**
- 4.7.26 - couldn’t reproduce
- 5.35.2 - issue reproducible
- 5.45.alpha1 (core demo civi) - issue reproducible
**Reproduction steps:**
1. create an unsupervised individual rule with the following details: ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24](/uploads/758592a6d5330c1133dcd1206e714daa/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_34_24.png)
2. create a custom field set for Contacts with checkboxes like this: ![screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12](/uploads/df40ee69692fda55f51e946b2c841b9d/screenshot-dmaster.demo.civicrm.org-2021.11.22-08_35_12.png)
3. add the custom field set that you created in previous step to a profile that can be added to a contribution page
4. create a new (or use an old) contribution page and add the profile that you created in previous step to it in the Profiles tab
5. create a new contact, and make sure it has a First name, Last name and Phone number
6. open the contribution page as anonymous and donate to it, using the exact same First name, Last name and Phone number that you entered in previous step AND select the ‘phone’ option at the custom field you created → _after you submit the donation, a new contact will be created instead of merging it to the existing one, which is wrong behaviour_
7. donate again on the same form, with the same details as before, but instead of selecting ‘phone’ select either the ‘email’ or ‘post’ options → _the contribution will be merged to the original contact, which is the correct behaviour. It is because email and post are not added to the unsupervised dedupe rule in this case._
I think most of the time civi admins create custom fields with values set as numbers, but in some cases they might configure it to be the same as the label name and in that case duplications might occur. I think it might be happening when the value of the custom field is the same as the name of the field in the database (just a thought, can't say for sure).https://lab.civicrm.org/dev/core/-/issues/1129Duplicate records on CRM_Report_Form_Member_Detail2022-09-26T00:11:17ZandyburnsDuplicate records on CRM_Report_Form_Member_DetailOn CRM_Report_Form_Member_Detail, the rows get duplicated. They are not actual duplicates, it is the same contact ID and they do not have duplicate memberships.
![5b7f716e](/uploads/6ae639a21fd22a9b5fc47c1d1edf66be/5b7f716e.png)
On 5.13.4On CRM_Report_Form_Member_Detail, the rows get duplicated. They are not actual duplicates, it is the same contact ID and they do not have duplicate memberships.
![5b7f716e](/uploads/6ae639a21fd22a9b5fc47c1d1edf66be/5b7f716e.png)
On 5.13.4https://lab.civicrm.org/dev/core/-/issues/4433E2E_Core_PathUrlTest::testGetUrl_WpAdmin() fails because CiviCRM routing is c...2023-07-24T20:52:34ZtottenE2E_Core_PathUrlTest::testGetUrl_WpAdmin() fails because CiviCRM routing is confusingThe gist of the test: it calls `cv url civicrm/contribute?reset=1` and asserts that the URL will open in the WordPress backend UI (aka `/wp-admin/`).
([Full source](https://github.com/civicrm/civicrm-core/blob/8e0dabd20bebe55d5dd725f301...The gist of the test: it calls `cv url civicrm/contribute?reset=1` and asserts that the URL will open in the WordPress backend UI (aka `/wp-admin/`).
([Full source](https://github.com/civicrm/civicrm-core/blob/8e0dabd20bebe55d5dd725f3015c41019cb8dbed/tests/phpunit/E2E/Core/PathUrlTest.php#L94-L117))
The test is failing. There are currently two patches:
* [25476](https://github.com/civicrm/civicrm-core/pull/25476): Automatically choose frontend/backend based on the route metadata
* [26772](https://github.com/civicrm/civicrm-core/pull/26772): Change the test to specifically request backend
Both have issues. So here's a deep-dive into the context.
Background
----------
* CiviCRM runs on Drupal/Backdrop and WordPress/Joomla.
* On WordPress/Joomla, the "frontend" and "backend" are different sub-applications (e.g. `/` vs `/wp-admin/`). The applications have very different URL structures. To make a hyperlink, you first decide which sub-application to target -- and then pick a page within it.
* On Drupal/Backdrop, it's one application, and all URLs have similar structure. To make a hyperlink, you simply identify the page.
* (*Drupal/Backdrop UX can sometimes distinguish frontend/backend -- but it's a visual choice based on local configuration. It's not a structural part of the URL.*)
* CiviCRM's routing system integrates into every UF/CMS, but (internally) it is closer to Drupal's. There is one `civicrm_menu` with all frontend+backend pages.
* On Drupal/Backdrop, CiviCRM's routes pass directly to CMS routes.
* On WordPress/Joomla, CiviCRM's routing integrates with both subapplications (ie "frontend" and "backend").
* CiviCRM stores a flag `bool is_public` for each route.
* CiviCRM includes routes which can be classified as:
* Purely backend (ex: `civicrm/dashboard`)
* Purely frontend (ex: `civicrm/event/register`)
* Purely web-service (ex: `civicrm/payment/ipn`)
* Multi-homed
* Ex: `civicrm/profile/view` has use-cases for frontend and backend
* Ex: `civicrm/ajax/api4/%` has use-cases for frontend, backend, and web-service
* CiviCRM has a function `CRM_Utils_System::url()`
* At first glance, it resembles Drupal's `\url()`. You typically just give the page (e.g. `url('civicrm/foo/bar')`).
* Over time, several additional parameters were added -- notably, the 6th parameter `bool $frontend` and the 7th parameter `bool $forceBackend`.
Problems
--------
* The status-quo invites bugs between CMS's.
* A developer working on Drupal will have trouble recognizing the importance of the 6th and 7th parameters. (*Those params do nothing on Drupal - and they're buried at the end of method.*)
* The status-quo invites bugs between interactive and automatic processes.
* A developer defines a custom token and tests it interactively; then at runtime, the token is sent by an automatic process. But the interactive/automatic split is orthogonal to frontend/backend split. Sometimes, interactive/automatic agree with each other (*both frontend or both backend*), and sometimes they disagree (*one frontend, one backend*).
* Overall, what tends to happen is:
* Developer writes a call like `CRM_Utils_System::url('civicrm/foo/bar')`, and it looks pretty.
* They test, and it works beautifully on their system.
* They publish, and it fails on other systems.
* Someone writes a patch to add 5 more parameters (`url('civicrm/foo/bar', '', FALSE, NULL, TRUE, TRUE)`). And then it's OK.
* The DX is awkward and invites bugs (in core and contrib) -- but it becomes more annoying for `cv` UX.
* If you need a 5th/6th param in PHP code, then you'll eventually figure it out and commit the update to your codebase. Then you forget about it.
* `cv` has some commands to facilitate manual testing and E2E testing (ie `cv url`, `cv http`, `cv open`). These are things that you improvise. Mismatched URLs can be annoying anytime you use these subcommands.
What to do
----------
There are two PRs to fix the test, and honestly - I don't really like either.
* [26772](https://github.com/civicrm/civicrm-core/pull/26772) makes the red mark go away, but it leaves the underlying issue (poor DX for PHP and poor UX for cv).
* [25476](https://github.com/civicrm/civicrm-core/pull/25476) aims to fix the underlying issue, but it's probably too facile. The current metadata can distinguish "purely frontend" pages from "purely backend" pages, but it cannot recognize "purely web-service" or "multi-homed". It probably messes-up some scenarios for those.
* Fixing this probably requires some more aggressive transition in the contract.
* Ex: Improve the routing metadata so that we can distinguish web-service routes and multi-home routes.
* Ex: Define a different class or function for generating URLs (*with a more usable signature*).
* Another option is to leave `civicrm-core` as-is -- and only update `cv`.
* Ex: Give `cv` the mechanism to resolve a frontend/backend based on metadata.
* Ex: Change `cv` to complain if you don't a specify frontend/backend flag.
* Either way, it feels like a bit of a wasted opportunity to only patch `cv` when we know that other users of `CRM_Utils_System::url()` get confused about the frontend/backend flags.https://lab.civicrm.org/dev/core/-/issues/3881Edit fields for invoicing information2022-10-25T11:52:40Zthoni56Edit fields for invoicing informationOverview
----------------------------------------
The form fields for invoicing information (in CiviEvent) seems to be hardcoded. E.g. it lacks company name and email. It does not seem possible to change or amend these fields.
Example u...Overview
----------------------------------------
The form fields for invoicing information (in CiviEvent) seems to be hardcoded. E.g. it lacks company name and email. It does not seem possible to change or amend these fields.
Example use-case
----------------------------------------
1. Create an event and enable web registrations
1. Make invoicing mandatory
2. Make a registration and notice what the only available fields are
Current behaviour
----------------------------------------
Hard coded fields
Proposed behaviour
----------------------------------------
Possiblity to use a profile, or custom form.
Comments
----------------------------------------
There is a StackExchange question around this: https://civicrm.stackexchange.com/questions/42202/how-can-i-add-company-to-billing-pay-later-fields but the proposed "solution" is hard and really not a solution.https://lab.civicrm.org/dev/core/-/issues/4698Editing a contribution does not consider all related line items.2023-10-20T07:50:26ZjitendraEditing a contribution does not consider all related line items.Original issue raised on webform_civicrm project - https://www.drupal.org/project/webform_civicrm/issues/3390363
Contribution created with multiple line items overwrites the total amount with participant, if tax amount is included for a...Original issue raised on webform_civicrm project - https://www.drupal.org/project/webform_civicrm/issues/3390363
Contribution created with multiple line items overwrites the total amount with participant, if tax amount is included for all the line items.
**Steps to reproduce**
- Create a webform including event registration with participant fee and contribution with at least one additional line item.
- Ensure all the fees have tax included.
- Make a submission to generate a contribution with multiple line items.
- In civicrm access the contribution's edit form and save.
- On submit, the total amount and tax amount is recalculated and will only include the participant fee, additional line items are ignored.
The issue is possibly at this point - https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution.php#L1668
Not sure why its required to update the total amount on edit action, when we have a freezed display of it on screen?https://lab.civicrm.org/dev/financial/-/issues/204Editing a line item on a membership extends the term of the membership2022-10-11T12:27:28ZkcristianoEditing a line item on a membership extends the term of the membershipCiviCRM 5.50+
Tested on WP Master
Required Line item editor extension and membership created from a price set.
wpcvmaster - 5.53
Steps to reproduce:
- Add a recurring membership
![image](/uploads/6bcad85c842288f49b37d665d4cf02a3...CiviCRM 5.50+
Tested on WP Master
Required Line item editor extension and membership created from a price set.
wpcvmaster - 5.53
Steps to reproduce:
- Add a recurring membership
![image](/uploads/6bcad85c842288f49b37d665d4cf02a3/image.png)
![image](/uploads/79381fa3d7cc4976f3df819fdb79c54e/image.png)
* Need to update rate for the next recurring membership payment
- click more on the recurring transaction that is in progress
![image](/uploads/3b1e39119d0eeb3ccd63ff6da8a72e67/image.png)
* view template
* then edit at bottom of screen
![image](/uploads/0c67dab579f9fd714b9fe3c7517e9750/image.png)
* edit line item
![image](/uploads/9eb56bec0334d8f389db8f5b68f0c33b/image.png)
* change amount
![image](/uploads/512f88dde2200e18efb8771bb3b73b7c/image.png)
- recurring is now updated:
![image](/uploads/4ffaae2bf8207c6b14f3f02d11e8f9aa/image.png)
Unintended consequence: Membership extended:
![image](/uploads/da6e71e2d4d2fbc7f9de4c2709691931/image.png)
cc @seamuslee @JoeMurray This _may_ be related to the 2.5 releaseMonish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/4619Eliminate `contributeMode`2023-09-26T12:23:10ZeileenEliminate `contributeMode``contributeMode` is the old concept when we thought we could categorise payment processors into 3-4 basic types that did the same stuff. We have mostly eliminated but it perseveres in a few places we want to kill
| Form | Used for |Alte...`contributeMode` is the old concept when we thought we could categorise payment processors into 3-4 basic types that did the same stuff. We have mostly eliminated but it perseveres in a few places we want to kill
| Form | Used for |Alternative|
| ------ | ------ |------------|
| Contribution_Confirm | Should the form `postProcess` hook be called before `doPayment` |? `$processor->supports('formAssumesNoReturn')` (I kinda feel it should be on the processor to call the hook but...|
| Contribution_Confirm | Should the button be called 'Continue' or 'Make Contribution' |Ditch? always 'Make Contribution'? Or do we need a `getText('continue_contribution_button)`|
|Event_Registration|Should emails be sent from the form (otherwise sent on completetransaction)|? `$processor->supports('formAssumesNoReturn')`|
|Event_Registration_Confirm|Should paypal express code be called|probably just a different hack|
|Event_Registration_Confirm::554|several places tricky stuff around doPayment| will need unravelling|
|Contribution Confirm.tpl|What text should we use for continue_instructions-section|?`paymentObject->getText('continue_contribution_instruction')` ?|
|Registration Thankyou.tpl|What text should be used arount 'Your registration has been processed successfully'|?`paymentObject->getText('event_success_instruction')` ?|
All other places are either doing nothing or are removablehttps://lab.civicrm.org/dev/core/-/issues/3858Email displays twice on Contribution Confirmation/Thank-you pages2023-11-23T07:47:00ZJonGoldEmail displays twice on Contribution Confirmation/Thank-you pagesOverview
----------------------------------------
If you have a profile on your contribution page that includes an email field, the email appears twice on the Confirmation and Thank-You pages.
Reproduction steps
------------------------...Overview
----------------------------------------
If you have a profile on your contribution page that includes an email field, the email appears twice on the Confirmation and Thank-You pages.
Reproduction steps
----------------------------------------
1. Create a contribution page.
1. Add a profile to the page that contains an email.
1. Submit a contribution.
Current behaviour
----------------------------------------
![Selection_1638](/uploads/e0bfd95675953dadba161aa20e658a99/Selection_1638.png)
Expected behaviour
----------------------------------------
![Selection_1637](/uploads/9c06ec7dc2f1537c860e904ba02f76d4/Selection_1637.png)
Comments
----------------------------------------
When an email field is present in a profile, we correctly hide the email field from the main contribution page. This extends that behavior to the confirmation and thank-you.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4876Email greeting config crashes on some smarty `if` statements if quotes are in...2024-01-15T11:27:07ZDaveDEmail greeting config crashes on some smarty `if` statements if quotes are involvedI don't think this is recent, but in message templates I remember there was some handling so that you could do e.g. `{if '{token.something}' == ''}aaa{else}bbb{/if}`, and if `{token.something}`'s value contained apostrophes it would stil...I don't think this is recent, but in message templates I remember there was some handling so that you could do e.g. `{if '{token.something}' == ''}aaa{else}bbb{/if}`, and if `{token.something}`'s value contained apostrophes it would still work. I haven't checked if that's still working but if you do the same in an email greeting it will crash. Example:
1. Create a new contact with first name `D'Andre`.
2. Down in communication prefs choose customized for the email greeting and put `Dear {if '{contact.first_name}' == ''}Friend{else}{contact.first_name}{/if}`.
3. When you save it crashes because the apostrophe confuses it.
4. It's not related to choosing "customized". It happens if this is your normal config at admin - communications - email greetings.
5. It also happens if you try double-quotes and then the name contains a double-quote.
I can work around it with `Dear {if {contact.first_name|boolean}}{contact.first_name}{else}Friend{/if}`, but if I wanted to compare to an actual value that wouldn't help.https://lab.civicrm.org/dev/core/-/issues/4540Email issues can cause new membership contributions to fail with pending/inco...2023-11-23T06:38:55ZTOCM_MMatthewsEmail issues can cause new membership contributions to fail with pending/incomplete.Overview
----------------------------------------
On a self hosted WordPress (currently 6.3) / CiviCRM (currently 5.64.0) site, when we had an SMTP server outage (not sending email from our virtual server directly, as that causes other s...Overview
----------------------------------------
On a self hosted WordPress (currently 6.3) / CiviCRM (currently 5.64.0) site, when we had an SMTP server outage (not sending email from our virtual server directly, as that causes other spam-related problems), any attempt to sign up as a member to our site would end in a failure state (contribution pending/incomplete), after processing payment but failing to send the receipt email. Could be related to the request timing out from php-fpm, but whatever that email timeout was, it was longer than 120s when I gave up trying to adjust php-fpm's timeout value. Settings within CiviCRM (outbound mail) have always just used mail(). But we use the WP Mail SMTP plugin for all WordPress related email to go through the trusted mailers directly. And when that was pointing to mail servers that timed out our connections, we'd see the pending/incomplete failures. Flipping that to default/none so it would use the host mailer as well, things started to work again (with the caveat of some emails not getting through because our server's IP will never be fully trusted by all the major mailers, given that it's within a virtual IP range that apparently triggered some alarms before).
https://civicrm.stackexchange.com/questions/45428/email-timeouts-breaking-contributions?noredirect=1#comment53603_45428
Reproduction steps
----------------------------------------
Set your WordPress mailer up to a host that times out the SMTP connection with WP Mail SMTP (we use the free version, non-profit, can't justify Pro upgrade). Key point probably being SMTP connection timeout being longer than php-fpm timeout, as the process terminates ungracefully.
Set up membership contribution page that sends credit card processing receipt. Maybe it was the password reset link from WordPress, but, can't see how?
Current behaviour
----------------------------------------
Users would not get any receipt or password reset email, transaction -- while processed via our provider (Stripe) would show as pending/incomplete transaction.
Expected behaviour
----------------------------------------
The transaction should continue. Maybe emails will get delayed/queued/lost depending on the mailer situation, but this should not break recording of a successful payment, so we'd just have to resend emails instead of go in and mark the transaction as complete after verifying payment has been received and then resend emails.
Environment information
----------------------------------------
* __Browser:__ Every. Testing confirmed with Safari 16.5.2 / Chrome 116.0.x on macOS Ventura 13.4.1(c).
* __CiviCRM:__ 5.64.0 at the time of SMTP failure
* __PHP:__ 8.0.30
* __CMS:__ WordPress 6.3
* __Database:__ MySQL 8.0.32
* __Web Server:__ Apache 2.4.57
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/user-interface/-/issues/39Email Signature: changing the "from" email does not update the signature2021-08-17T03:40:42ZbgmEmail Signature: changing the "from" email does not update the signatureFrom #38:
> The signature doesn't change when you change the FROM address on the email form.
To reproduce:
* Add a second email to your contact record
* Add different signatures to both emails
* Click to send an email (it can be to se...From #38:
> The signature doesn't change when you change the FROM address on the email form.
To reproduce:
* Add a second email to your contact record
* Add different signatures to both emails
* Click to send an email (it can be to self, does not matter)
* Primary email signature is loaded
* Change the "from" email to the secondary email (of our logged-in user)
* Notice that the signature did not change.
Tangential:
* Loading a message template removes the email signature. Kind of annoying.
* Switching from/signatures could assume that we are reloading the content, but should probably warn that the content is about to be lost.
cc @DaveD @justinfreemanhttps://lab.civicrm.org/dev/core/-/issues/2646Enable/Disable Extension Receives API Error2022-09-16T00:12:46ZpbarmakEnable/Disable Extension Receives API ErrorOverview
----------------------------------------
Anytime we enable or disable an extension, we get an API error with the error message of: API error: Value already exists in the database on ReportTemplate.create. This is true with eithe...Overview
----------------------------------------
Anytime we enable or disable an extension, we get an API error with the error message of: API error: Value already exists in the database on ReportTemplate.create. This is true with either the Admin extension UI screen or using cv.
Reproduction steps
----------------------------------------
1. Run cv ext:disable uk.co.vedaconsulting.mosaico
2. Get the error message
3. The extension still gets disabled (or enabled, depending on what we run)
Current behaviour
----------------------------------------
Here is the full error message from cv:
```
Disabling extension "uk.co.vedaconsulting.mosaico"
Error: API Call Failed: Array
(
[entity] => Extension
[action] => disable
[params] => Array
(
[keys] => Array
(
[0] => uk.co.vedaconsulting.mosaico
)
[debug] => 1
[version] => 3
)
[result] => Array
(
[trace] => #0 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(241): CRM_Core_ManagedEntities->onApiError('ReportTemplate', 'create', Array, Array)
#1 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(184): CRM_Core_ManagedEntities->insertNewEntity(Array)
#2 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(146): CRM_Core_ManagedEntities->reconcileEnabledModule(Object(CRM_Core_Module), Array)
#3 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(127): CRM_Core_ManagedEntities->reconcileEnabledModules()
#4 /var/www/civicrm/sites/all/modules/civicrm/CRM/Core/Invoke.php(400): CRM_Core_ManagedEntities->reconcile()
#5 /var/www/civicrm/sites/all/modules/civicrm/CRM/Extension/Manager.php(420): CRM_Core_Invoke::rebuildMenuAndCaches(true)
#6 /var/www/civicrm/sites/all/modules/civicrm/api/v3/Extension.php(150): CRM_Extension_Manager->disable(Array)
#7 /var/www/civicrm/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_extension_disable(Array)
#8 /var/www/civicrm/sites/all/modules/civicrm/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
#9 /var/www/civicrm/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array)
#10 /var/www/civicrm/sites/all/modules/civicrm/api/api.php(22): Civi\API\Kernel->runSafe('Extension', 'disable', Array)
#11 phar:///usr/local/bin/cv/src/Command/BaseCommand.php(49): civicrm_api('Extension', 'disable', Array)
#12 phar:///usr/local/bin/cv/src/Command/ExtensionDisableCommand.php(56): Civi\Cv\Command\BaseCommand->callApiSuccess(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), 'Extension', 'disable', Array)
#13 phar:///usr/local/bin/cv/vendor/symfony/console/Command/Command.php(257): Civi\Cv\Command\ExtensionDisableCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 phar:///usr/local/bin/cv/vendor/symfony/console/Application.php(850): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 phar:///usr/local/bin/cv/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRunCommand(Object(Civi\Cv\Command\ExtensionDisableCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 phar:///usr/local/bin/cv/src/Application.php(46): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 phar:///usr/local/bin/cv/vendor/symfony/console/Application.php(124): Civi\Cv\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 phar:///usr/local/bin/cv/src/Application.php(15): Symfony\Component\Console\Application->run()
#19 phar:///usr/local/bin/cv/bin/cv(27): Civi\Cv\Application::main('phar:///usr/loc...')
#20 /usr/local/bin/cv(14): require('phar:///usr/loc...')
#21 {main}
[is_error] => 1
[error_message] => API error: Value already exists in the database on ReportTemplate.create
)
)
```
Expected behaviour
----------------------------------------
No error message
Environment information
----------------------------------------
* __CiviCRM:5.38.0
* __PHP:7.3.28
* __CMS:Drupal 7
* __Web Server: Apache 2.4https://lab.civicrm.org/dev/core/-/issues/4527End Date field in Relationship cannot filter on date in join clause APIv42023-08-24T21:58:32ZseamusleeEnd Date field in Relationship cannot filter on date in join clause APIv4In APIv4 when joining onto relationships for example from contact.get you cannot use a date value e.g. 2023-08-23 you get unknown field error. However if you put the string into quotes it works
https://dmaster.demo.civicrm.org/civicrm/a...In APIv4 when joining onto relationships for example from contact.get you cannot use a date value e.g. 2023-08-23 you get unknown field error. However if you put the string into quotes it works
https://dmaster.demo.civicrm.org/civicrm/api4#/explorer/Contact/get?join=%5B%5B%22Relationship%20AS%20relationship%22,%22LEFT%22,null,%5B%22id%22,%22%3D%22,%22relationship.contact_id_a%22%5D,%5B%22relationship.end_date%22,%22%3E%22,%222023-08-23%22%5D%5D%5Dhttps://lab.civicrm.org/dev/user-interface/-/issues/4Enhancement - Quick search contact lookup2019-10-07T13:26:00ZrebeccatregennaEnhancement - Quick search contact lookupAllow quick search to be used with full names rather than by leading last name; e.g. allow users to search for Oliver Gibson.Allow quick search to be used with full names rather than by leading last name; e.g. allow users to search for Oliver Gibson.https://lab.civicrm.org/dev/financial/-/issues/133Enhancements to Payment PropertyBag2021-04-12T10:46:20Zmattwiremjw@mjwconsult.co.ukEnhancements to Payment PropertyBagPayment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artful...Payment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artfulrobot and others to edit/update this description once we are in agreement.
1. The following parameters should be added:
* trxn_id -> Maps to `transactionID`.
* installments
* recur start/end dates?
2. To support a phased conversion to propertyBag we should allow exporting as an array: https://github.com/civicrm/civicrm-core/pull/17507 or similar. Alternatively we should document using reflection to access the propertyBag array eg.:
```
if ($propertyBag instanceof \Civi\Payment\PropertyBag) {
$reflectionClass = new ReflectionClass($propertyBag);
$reflectionProperty = $reflectionClass->getProperty('props');
$reflectionProperty->setAccessible(TRUE);
$params = $reflectionProperty->getValue($propertyBag)['default'];
}
else {
$params = $propertyBag;
}
```
3. Some parameters should be either be ignored or added to propertyBag in some form during `mergeLegacyInputParams` such as:
* qfKey
* entryURL
* qf_default..
Note that both `qfKey` and `entryURL` can be useful for guessing context though it would be nice if there was a better way to identify the context in which a payment processor was being used.
Eg. see https://lab.civicrm.org/extensions/stripe/-/blob/6.4.1/CRM/Core/Payment/Stripe.php#L1063 for an example of `qfKey` usage which shows that we don't really need `qfKey` but do need a more formal way of obtaining an errorURL or removing the need for it at all.https://lab.civicrm.org/dev/backdrop/-/issues/32Ensure drush works with Backdrop version of drush2022-10-25T11:45:12ZherbdoolEnsure drush works with Backdrop version of drushhttps://lab.civicrm.org/dev/core/-/issues/4457Entity Reference Custom Field not working as filter in "regular" search2023-10-03T21:46:14ZjensschuppeEntity Reference Custom Field not working as filter in "regular" searchFollow-up to #3721. @fabian_SYSTOPIA found out that filtering doesn't work correctly.
Not sure this is to be fixed, as it's related to the "old-style" searches ...
## Steps to reproduce
* Create an Entity Reference Custom Field on the...Follow-up to #3721. @fabian_SYSTOPIA found out that filtering doesn't work correctly.
Not sure this is to be fixed, as it's related to the "old-style" searches ...
## Steps to reproduce
* Create an Entity Reference Custom Field on the *Participant* entity for referencing an *Event* entity
* Edit a participant and fill out the field by selecting an event
* Use the *Find Participants* search and try to limit the search result to participants with the event previously selected in that field
* Notice that all participants are being found, not only that one with the entity reference field being filledhttps://lab.civicrm.org/dev/core/-/issues/4528Entity Reference custom fields: Configurable delete behavior2024-01-17T22:28:23ZjensschuppeEntity Reference custom fields: Configurable delete behavior## Overview
Currently, when entities referenced in a custom field of the type _Entity Reference_ are deleted, the entity reference field gets cleared (set to `NULL`). This is easy and prevents us from database inconsistencies. But this ...## Overview
Currently, when entities referenced in a custom field of the type _Entity Reference_ are deleted, the entity reference field gets cleared (set to `NULL`). This is easy and prevents us from database inconsistencies. But this can lead to problems:
* inconsistencies when the entity reference field is set to be required
* stale/orphaned entities the entity reference field is attached to
* `civicrm_value_*` records with all-empty columns (or are they being taken care of already)
## Example use-case
Imagine a custom entity named _Qualification_ with (among others) an entity reference custom field referencing a _Contact_ entity, which is set to be required; read: A _Contact_ has multiple _Qualifications_.
## Current behaviour
When deleting the contact, the _Qualification_ entity will not be deleted until done so manually. The reference is just being set to `NULL` instead. Those entities will be meaningless without a referenced contact, the required entity reference custom field will be empty, which breaks the semantic contract.
Question: Is the `SET NULL` behavior a FK constraint on the DB table or part of some logic in Core code?
## Proposed behaviour
When deleting the contact, the _Qualification_ entity should be deleted. This is what we'd have configured the entity reference field to behave, as in other scenarios, the current behavior will be totally fine.
So, we'll need a configuration option for _Entity Reference_ custom fields for selecting what should happen upon deletion of the referenced entity. Available options could be (basically MySQL foreign key constraints):
* Remove Reference (`SET NULL`) - current behavior, maybe also the default option
* Cascade Delete (`CASCADE`) - removes the _`civicrm_value_*`_ record and the entity the custom group is attached to
* Restrict Delete (`RESTRICT`) - just as you can't e. g. delete contacts with financial transactions
* Set Default (`SET DEFAULT`) - to be configured on the custom field
* ~~Keep Reference (`NO ACTION`)~~ - might not be a good idea
## Comments
@colemanw and @michaelmcandrew might be interested.
Currently, this can be partly achieved by implementing a `preDelete` event for retrieving and deleting referencing entities.