Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-04-12T20:56:13Zhttps://lab.civicrm.org/dev/core/-/issues/600Word Replacements: entering a string with HTML will reset all replacements2023-04-12T20:56:13ZbgmWord Replacements: entering a string with HTML will reset all replacementsHow to reproduce:
* On a single language site, go to Administer > Customize data and screen > Word Replacements
* Enter a few replacements, it doesn't matter if they are valid.
* Save, so far so good.
Then add a new replacement with ht...How to reproduce:
* On a single language site, go to Administer > Customize data and screen > Word Replacements
* Enter a few replacements, it doesn't matter if they are valid.
* Save, so far so good.
Then add a new replacement with html: `<p>test</p>`, and click save.
Result: word replacements table will be completely empty.
I debugged a bit and this is because `CRM_Core_BAO_WordReplacement.php::getConfigArraysAsAPIParams()` uses `unserialize` on the strings that are stored in `civicrm_domain` (ugh). The unserialize fails because of the HTML, so it returns FALSE, and the function ends up returning an empty array, which is then used to re-populate the `civicrm_word_replacement` table.https://lab.civicrm.org/dev/core/-/issues/1799Daily (and other) scheduled jobs slip forward each day until they're eventual...2023-06-17T17:35:14ZJonGoldDaily (and other) scheduled jobs slip forward each day until they're eventually missedIf this subject line looks familiar, [there's a reason](https://issues.civicrm.org/jira/browse/CRM-16276).
This issue was originally raised and [fixed in April 2015](https://github.com/civicrm/civicrm-core/commit/d0be1535d809b206890bcd4...If this subject line looks familiar, [there's a reason](https://issues.civicrm.org/jira/browse/CRM-16276).
This issue was originally raised and [fixed in April 2015](https://github.com/civicrm/civicrm-core/commit/d0be1535d809b206890bcd4f72ebd4ba8fb1c86d). However, a code simplification in December 2015 [removed the fix](https://github.com/civicrm/civicrm-core/commit/bda41fcbeaf535ff04d7e5cfc7145e83f50c17b2).
Many of us are familiar with this issue. Cron runs at 10:00:00, scheduled jobs are executed in order, and one job might not fire until 10:00:03. If the job fires hourly, we would expect the job to fire at 11:00:00, but since an hour hasn't elapsed since 10:00:00, the job doesn't fire until the *next* cron, maybe at 11:15:00. This has repercussions for a number of scheduled job use cases.
After some thought, I realized the correct solution is to record the time the *cron job* fires, not the time the job actually is started. I believe that when the `last_run` field was created, there was no sense that these times might be different, hence the bug.
I wrote a patch (I'm leaving it in production for a few days before submitting a PR) that does two things:
* `last_run` now refers to the time the cron job started, not the scheduled job.
* To avoid race-y conditions on very slow shared hosts, I force the `last_run` time to always have "00" as its seconds. This is a belt-and-suspenders (or belt-and-braces in non-'Merican) approach that reflects that a) shared hosting could be slow enough that this would otherwise be a problem, b) cron doesn't allow scheduled at the seconds level, so this shouldn't impact anyone's scheduling.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/20Can't place a contribution widget on a Contribution Page2023-11-23T07:47:01ZJonGoldCan't place a contribution widget on a Contribution PageWhen you attempt to place a contribution widget on its own contribution page in the "Inroductory Message" section, you get the error:
`Illegal characters in input (potential scripting attack)`
I confirmed this is a regression by replica...When you attempt to place a contribution widget on its own contribution page in the "Inroductory Message" section, you get the error:
`Illegal characters in input (potential scripting attack)`
I confirmed this is a regression by replicating the problem on the Drupal demo site (4.7) and confirming it didn't exist ion the Joomla site (4.6). I'm pretty sure it didn't happen earlier in the 4.7 cycle either.https://lab.civicrm.org/dev/core/-/issues/4725Proposal: Don't include "I am contributing on behalf of an organization" on c...2023-11-23T07:51:08ZlarsssandergreenProposal: Don't include "I am contributing on behalf of an organization" on contribution pages when the current contact is an organizationIf an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used ...If an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used them in the past). If they then select "I am contributing on behalf of an organization", they will get a error: `Payment Processor Error message :Invalid Relationship .`
This is because we are attempting to create a new organization with an employer of relationship to the current contact, which fails when the current contact is an organization as this is not allowed.
I think the simplest and most logical way to fix this is simply to not include the on behalf of option on the contribution page if the current contact is an organization and instead show the organization profile by default. If the user wants to contribute on behalf of the current contact organization, then this is fine. If they are contributing on behalf of a different organization or as an individual, they should click the not you link.https://lab.civicrm.org/dev/core/-/issues/4364Afform: Adding forms to menu is not compatible with Customize Navigation Menu2023-10-19T23:44:23ZlarsssandergreenAfform: Adding forms to menu is not compatible with Customize Navigation MenuIf you add a menu item for a form directly in the form, it shows up sort of where you want it (though the interface to set the order is pretty unhelpful, because you basically are guessing what the weight of existing items in the menu mi...If you add a menu item for a form directly in the form, it shows up sort of where you want it (though the interface to set the order is pretty unhelpful, because you basically are guessing what the weight of existing items in the menu might be). However, if you later go to Customize Navigation Menu, you can move the menu item you created around and it looks like it works and it will work for a while, but then later, it will move back to the location and weight set in the form.
This is confusing for users and frustrating if you don't know what's going on. Seems like we need to have just one way to edit the menu. Maybe it makes sense to simply remove the add to menu option from forms and let users add the menu item manually? Or alternately, we need a way for the menu location and weight to only be used on inserting the menu item and to be uneditable in the form afterwards, maybe with a help text that tells you to edit this directly in the menu.https://lab.civicrm.org/dev/financial/-/issues/186Accounting entries incorrect in a number of cases... especially with pending ...2023-05-01T17:18:33ZJamie Novick - CompucoAccounting entries incorrect in a number of cases... especially with pending refunds and overpaymentsFirstly - sorry for the wall of text. This has ended up being a much longer piece of analysis than expected but I thought I should share it so that we can agree a way ahead.
This all started as we were looking at the best way to impleme...Firstly - sorry for the wall of text. This has ended up being a much longer piece of analysis than expected but I thought I should share it so that we can agree a way ahead.
This all started as we were looking at the best way to implement refunds for a payment processor. Some work was done here to discuss this: https://lab.civicrm.org/dev/financial/-/issues/87 but I can see this stalled somewhat - probably due to some of the issues I'm going to discuss here.
# Background: The problems with the contribution status field
Just for complete disclosure I hate the CiviCRM contribution status field. Hopefully everyone already knows that. I've probably started discussions on getting rid of it at every CiviCON and documented this on every financial gitlab ticket. It is the biggest blocker we have to reaching an accounting implementation that aligns to standard concepts of accounting.
Why is that?
We appear to have 2 use cases for it, both of which are undocumented.
1. For users to quickly change whether the amounts owed are
a) expected to be paid or
b) are paid.
2. To reflect the payment status of the contribution
i.e. whether the total sum of the line items is >, < or = to the net amount paid in or refunded on that contribution (this is important and I’ll come back to it)
This is a bit of a problem as it’s all a bit chicken and egg! If the user changes the status we need to understand whether we should be creating payments or not (or creating refund payments or not), and if the user records payments or refund payments we need to update the status to something meaningful and consistent.
The following is an analysis of the allowed contribution status changes from and to that a user can perform:
**Table 1:**
- Black = Option hidden
- X - Val = Option shown but user cannot change to it as we have a validation message
- Y (black) = Option shown, user can select this and I don’t see issues with accounting that occurs
- N/A = Couldn’t test
- Y (red) = Option shown, user can select this and there are issues with accounting that occurs
![Screenshot_2021-09-15_at_15.33.12](/uploads/8db825597f091f0bf34d590b38b2ed2f/Screenshot_2021-09-15_at_15.33.12.png)
I’d note that it’s a bit confusing to users to see a value in the dropdown they can’t use. I think we should just hide values they cannot select as this would be much clearer for them.
We end up with some very strange and in some cases incorrect behaviour when allowing users to change the status in a "partially paid" and "pending refund" scenarios:
**Table 2:**
![Screenshot_2021-09-15_at_15.47.11](/uploads/827aafd531d7dbe54866b8237758ce42/Screenshot_2021-09-15_at_15.47.11.png)
# Ground Rules
As such I would like to suggest some ground rules to work towards:
1. The only time a user can change the status of a contribution should be when it has no payments or refunds attached to it.
2. Once a payment has been received we manage everything through either the line item editor or the “change selections” on the event form or "record payment” or “record refund”. If any changes to each are made to any of these we recalculate the contribution status based on one set of rules:
The rules to calculate the contribution status should be:
**Table 3:**
![Screenshot_2021-09-15_at_15.38.43](/uploads/b77e518446862474f4e6823e045e11a3/Screenshot_2021-09-15_at_15.38.43.png)
Delving deeper, there are a number of situations within CiviCRM that do not confirm to this currently and instead we end up with a status this is confusing for the user:
(Note this is not be a comprehensive list - just to give some examples).
**Table 4:**
![Screenshot_2021-09-15_at_15.39.45](/uploads/3a9e238f9ec1071de6b056c543c68522/Screenshot_2021-09-15_at_15.39.45.png)
# Specific Scenarios
This all said there are some specific use cases that we need to consider and have appropriate workflows for:
Table 5:![Screenshot_2021-09-15_at_15.40.49](/uploads/a922e2c0f5a52b92adba895c5fd89654/Screenshot_2021-09-15_at_15.40.49.png)
# Actions:
As such I think the actions could be:
1. Agree to the "ground rules" for the contribution status field above so we are all working towards a common goal.
1. I think we should hide values they cannot select as this would be much clearer for them. i.e. all items that are marked as “X-val” in the table above. Perhaps we can refactor the code that show/hides the options to a central place.
1. I think we should change the way the status field is calculated to use the business logic suggested in Table 3 above in all cases. This shouldn’t be something that extensions should take care of but should be calculated any time a contribution haas it’s line items / financial transactions changed. Obviously I don’t know what this means from a code perspective and I assume this would be a significant refactor but I think we could clear up a lot of business logic by doing so.
1. Discuss and agree which of the options from table 5.1 are suitable and then agree the UX for this.
1. So that we can then remove the option to make the status changes as per table 1: 3f, 4e, 4f without degrading users ability to do the things they need.
I actually think if we do these things we can consider CiviCRM’s accounting to be “correct” if not completely intuitive (at least for now).
@mattwire @eileen @KarinG @JoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/2114Trigger-based logging doesn't log if just changing a letter to upper/lower case2023-06-29T12:55:38ZDaveDTrigger-based logging doesn't log if just changing a letter to upper/lower case1. Turn on logging. (Admin - System Settings - Misc - Logging).
1. Change the first name of a contact just changing e.g. the first letter from upper to lower case.
1. Either look in the database in log_civicrm_contact or go to CiviReport...1. Turn on logging. (Admin - System Settings - Misc - Logging).
1. Change the first name of a contact just changing e.g. the first letter from upper to lower case.
1. Either look in the database in log_civicrm_contact or go to CiviReports - Contact Reports - Contact Logging.
1. Change has not been logged.
It's because the standard collation for civi is the case-insensitive xxx_unicode_ci or possibly xxx_general_ci. You might have also changed it manually to use the same as your CMS but is likely still case-insensitive. And in mysql 8 the default utf8mb4_0900_ai_ci is also accent-insensitive (i.e. `é` is treated the same as `e`), if you manually changed your civi tables to use that.
The logging triggers should probably use `xxx_bin`. Related but separate: https://github.com/civicrm/civicrm-core/pull/18721https://lab.civicrm.org/dev/core/-/issues/1486Deadlocks on acl_cache2023-09-12T18:50:06ZeileenDeadlocks on acl_cacheOne of the prevalent deadlocks we see is on the acl_contact_cache. I've found that I can replicate this locally fairly consistently just by running 2 sets of tests at once.
The thing that is somewhat odd about this is that we don't use ...One of the prevalent deadlocks we see is on the acl_contact_cache. I've found that I can replicate this locally fairly consistently just by running 2 sets of tests at once.
The thing that is somewhat odd about this is that we don't use ACLs at all so in fact the table is always empty. Notably the table is also extremely slow to truncate - despite being empty.
**What happens**
The flow we have is
1) api call to create a contact
2) when the contact is created CRM_Contact_BAO_Contact_Utils::clearContactCaches() is called. It hits a deadlock because
a) it has an FK to contact.id (& in our case it has an FK and an index seemingly)
b) it is called a lot
3) it retries and succeeds
4) we then try to add an email - the add function fails on a foreign key constraint because the earlier deadlock rolled the contact create back
**Proposals**
I think there are a number of things we can do & we should do some combo:
1) Make the delete function less expensive & less locky
a) Add an index on modified date - we are constantly deleting where modified_date < x so let's index it
b) remove the index on acl_id - we ALSO have an FK so having both is probably harmless-but-confusing
c) alter the FK on contact ID to be an index not a foreign key. This is perhaps a confusing suggestion but it is also the one that will make a real dent in these deadlocks. Remember this is a cache table not a 'persistent' table. The impact of the rows outliving the existence of the contact for a little bit is basically none because we don't do ACL lookups on non-existent contacts (this is also potentially helpful for better handling 0 or anonymous contact_id where we've had to work around this before
2) Protect against conflict through mysql locks. I think we can use a mysql lock to avoid 2 processes attempting this flush at once. I'll do a PR for this
3) How often do we REALLY need to flush those caches. Maybe we could cache a 'last flushed' key & flush no more than every 30 seconds.
4) Consider checking if the table is empty before attempting to empty it.
5) Review the places where acl cache is called from & decide how necessary there are - here is the list:
**CRM_ACL_BAO_Cache::resetCache**
CRM/Contact/BAO/Contact/Utils.php: CRM_ACL_BAO_Cache::resetCache();
CRM/Core/BAO/Cache.php: CRM_ACL_BAO_Cache::resetCache();
CRM/Utils/System.php: CRM_ACL_BAO_Cache::resetCache();
CRM/ACL/Page/EntityRole.php: CRM_ACL_BAO_Cache::resetCache();
CRM/ACL/Form/ACLBasic.php: CRM_ACL_BAO_Cache::resetCache();
CRM/ACL/Form/EntityRole.php: CRM_ACL_BAO_Cache::resetCache();
CRM/ACL/BAO/ACL.php: CRM_ACL_BAO_Cache::resetCache();
**CRM_Contact_BAO_Contact_Utils::clearContactCaches()**
CRM/Contact/BAO/Contact/Utils.php: public static function clearContactCaches($isEmptyPrevNextTable = FALSE) {
CRM/Contact/BAO/GroupContact.php: CRM_Contact_BAO_Contact_Utils::clearContactCaches();
CRM/Contact/BAO/GroupContact.php: CRM_Contact_BAO_Contact_Utils::clearContactCaches();
CRM/Contact/BAO/Contact.php: CRM_Contact_BAO_Contact_Utils::clearContactCaches();
CRM/Contact/Import/Form/Preview.php: CRM_Contact_BAO_Contact_Utils::clearContactCaches(TRUE);
bin/cli.class.php: CRM_Contact_BAO_Contact_Utils::clearContactCaches();
6) A bigger task perhaps - but permit opportunistic flushing to be turned off in favour of a cron (per group contact cache)
**Deadlock output**
LATEST DETECTED DEADLOCK
------------------------
2019-12-19 11:29:45 0x700010cd2000
*** (1) TRANSACTION:
TRANSACTION 34518715, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 11 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 7
MySQL thread id 571, OS thread handle 123145583353856, query id 709677 localhost 127.0.0.1 drupalcivi_lkznr updating
DELETE
FROM civicrm_acl_cache
WHERE modified_date IS NULL
OR (modified_date <= '20191218222444')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 143182 page no 3 n bits 80 index PRIMARY of table `drupalcivi_lkznr`.`civicrm_acl_cache` trx id 34518715 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 32
0: len 4; hex 00003c14; asc < ;;
1: len 6; hex 0000020eb6ba; asc ;;
2: len 7; hex 3b000001442ac5; asc ; D* ;;
3: SQL NULL;
4: len 4; hex 00000002; asc ;;
5: SQL NULL;
*** (2) TRANSACTION:
TRANSACTION 34518714, ACTIVE 1 sec starting index read
mysql tables in use 2, locked 2
66 lock struct(s), heap size 8400, 71 row lock(s), undo log entries 74
MySQL thread id 573, OS thread handle 123145584189440, query id 710022 localhost 127.0.0.1 drupalcivi_lkznr updating
UPDATE civicrm_contact SET contact_type = 'Organization' , contact_sub_type = NULL , email_greeting_id = NULL , postal_greeting_id = NULL , addressee_id = 3 , employer_id = 15055 WHERE ( civicrm_contact.id = 15055 )
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 143182 page no 3 n bits 80 index PRIMARY of table `drupalcivi_lkznr`.`civicrm_acl_cache` trx id 34518714 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;seamusleeseamusleehttps://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/5068Do we need the qfkey in group urls?2024-03-07T13:49:27ZAndrew WestDo we need the qfkey in group urls?My users are forever emailing each other broken links to Civi groups, due to the qfkey in the URL. This doesn't seem to be needed in most of the rest of Civi - is it worth my investigating how to remove it? Or would we aim to replace tha...My users are forever emailing each other broken links to Civi groups, due to the qfkey in the URL. This doesn't seem to be needed in most of the rest of Civi - is it worth my investigating how to remove it? Or would we aim to replace that page with a search kit version soon anyway?https://lab.civicrm.org/dev/core/-/issues/4782Mailing system doesn't work with DigitalOcean managed databases2023-11-20T12:13:45ZrobertgarrigosMailing system doesn't work with DigitalOcean managed databasesOverview
----------------------------------------
When creating a new mailing adding a group in the recipients field triggers an error:
Possibly unhandled rejection: {"error_code":-1,"sql":"CREATE TEMPORARY TABLE civicrm_tmp_e_exrecipie...Overview
----------------------------------------
When creating a new mailing adding a group in the recipients field triggers an error:
Possibly unhandled rejection: {"error_code":-1,"sql":"CREATE TEMPORARY TABLE civicrm_tmp_e_exrecipient_dc8f2500b15714f5703ad66bc5a8bb37 (contact_id int primary key) ENGINE=MEMORY COLLATE utf8mb4_unicode_ci","debug_info":"CREATE TEMPORARY TABLE civicrm_tmp_e_exrecipient_dc8f2500b15714f5703ad66bc5a8bb37 (contact_id int primary key) ENGINE=MEMORY COLLATE utf8mb4_unicode_ci [nativecode=3161 ** Storage engine MEMORY is disabled (Table creation is disallowed).]","entity":"Mailing","action":"create","is_error":1,"error_message":"DB Error: unknown error","debug_information":"CREATE TEMPORARY TABLE civicrm_tmp_e_exrecipient_dc8f2500b15714f5703ad66bc5a8bb37 (contact_id int primary key) ENGINE=MEMORY COLLATE utf8mb4_unicode_ci”}
https://civicrm.stackexchange.com/questions/45905/storage-engine-memory-is-disabled-with-digitalocean-managed-database
Reproduction steps
----------------------------------------
1. Create a new mailing
1. add a group to the recipients field
1. Got error on console as well as "estimating" label get locked
1. You need to have the civicrm database hosted in a DigitalOcean manage database cluster
Expected behaviour
----------------------------------------
Groups should get added and count of contacts should be shown next to the recipients field
Comments
----------------------------------------
Fixed by changing line 67 of CRM/Utils/SQL/TempTable.php from `const MEMORY = 'ENGINE=MEMORY';` to `const MEMORY = 'ENGINE=InnoDB';`
I'm aware that you could think that this is a DigitalOcean Problem (they have unsetted the ability to set internal_tmp_mem_storage_engine to MEMORY), but I wonder if the Memory Engine is necessary at all.https://lab.civicrm.org/dev/core/-/issues/4743Refreshing event registration thank you page resulting error2023-11-17T15:44:51Zvakeesan26Refreshing event registration thank you page resulting errorRefreshing Event registration thank you page resulting error as below
**Could not find valid value for id**
![image](/uploads/15aa0a835556a286a3ab8172cb13c63d/image.png)Refreshing Event registration thank you page resulting error as below
**Could not find valid value for id**
![image](/uploads/15aa0a835556a286a3ab8172cb13c63d/image.png)https://lab.civicrm.org/dev/core/-/issues/4637Profile Update from SearchKit doesn't work2023-10-03T20:55:03ZlarsssandergreenProfile Update from SearchKit doesn't workIf you try to use Profile Update in SK, it pops up a modal to select the profile and then just closes when you click continue. Verified this is the behaviour back to at least 5.58. Probably makes more sense to get in-place editing workin...If you try to use Profile Update in SK, it pops up a modal to select the profile and then just closes when you click continue. Verified this is the behaviour back to at least 5.58. Probably makes more sense to get in-place editing working well enough to replace Profile Update, but at least we should remove it if is broken.https://lab.civicrm.org/dev/core/-/issues/4617Running Job.update_greeting without updating customized greetings2023-10-18T08:06:00ZCharlotteRunning Job.update_greeting without updating customized greetingsOverview
----------------------------------------
For the scheduled job `update_greeting` there are two options for the parameter `force` which are explained by the [documentation](https://docs.civicrm.org/user/ca/latest/initial-set-up/...Overview
----------------------------------------
For the scheduled job `update_greeting` there are two options for the parameter `force` which are explained by the [documentation](https://docs.civicrm.org/user/ca/latest/initial-set-up/scheduled-jobs/#job_update_greeting) as follows:
- `0` only contacts with null values are updated (default)
- `1` update all contacts
There is no explanation about what happens with customized greetings when using `force = 1`.
It turns out that all customized greetings will be overridden by the standard greeting. I did not expect this.
It would be great to have another option
- `2` update all contacts excluding customized greetings
If this is not possible, then a more detailed documentation could be helpful.
This issue has also been described on [stackexchange](https://civicrm.stackexchange.com/questions/41709/running-job-update-greeting-without-updating-customized-greetings).
Work around
----------------------------------------
Use API v4 to set all greetings that are not customized greetings to NULL.
Here an example for individuals and email greeting:
```
$contacts = civicrm_api4('Contact', 'get', [
'where' => [
['email_greeting_custom', 'IS EMPTY'],
['contact_type', '=', 'Individual'],
],
'chain' => [
'name_me_0' => ['Contact', 'update', ['values' => ['id' => '$id', 'custom_greeting_display' => NULL]]],
],
]);
```
Afterwards, the greetings are not NULL but already contain the new standard greeting. There is no need to run the job `update_greeting` with `force = 0`.
Environment information
----------------------------------------
* __CiviCRM:__ 5.63.2
* __PHP:__ 8.1
* __CMS:__ Drupal 9https://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/4437SearchKit dB Entity not able to save2023-07-17T19:46:43ZBruce ThompsonSearchKit dB Entity not able to saveWhen creating a dB Entity in searchkit if the search is complex it will not save. Just get an orange box with a spinning icon. I was able to recreate the issue here https://wpmaster.demo.civicrm.org/.
Details:
- Simple search such as a ...When creating a dB Entity in searchkit if the search is complex it will not save. Just get an orange box with a spinning icon. I was able to recreate the issue here https://wpmaster.demo.civicrm.org/.
Details:
- Simple search such as a search for individual contacts saved fine.
- A search with address state also saved fine
- When adding contact address & state abbreviation the error saving occurred.
With the simple searches that save OK I see the message ` Last refreshed: never. Click "Save" to refresh now.` if I click save I see `Checking last refresh date...` when I look in the database I see the table created but no data.
I tested on my test site running CiviCRM 5.63.1 with WordPress 6.2.2 and PHP 8.1.21. I was able to recreate all this in https://wpmaster.demo.civicrm.org/.https://lab.civicrm.org/dev/core/-/issues/4288Price set option limit = 0 should mean no spaces, rather than no limit2023-05-15T08:16:42ZlarsssandergreenPrice set option limit = 0 should mean no spaces, rather than no limitIf you set a price set option limit to 0, this is the same as not specifying a limit. I would expect that a limit of 0 would mean there are no spaces. Setting the limit to 0 is different than disabling the price set option, as disabling ...If you set a price set option limit to 0, this is the same as not specifying a limit. I would expect that a limit of 0 would mean there are no spaces. Setting the limit to 0 is different than disabling the price set option, as disabling makes it so the option does not appear on public forms, while I expect setting the limit to 0 would just make it sold out, but still appear. I can't think of a good reason you would want 0 to be the same as no limit, but maybe others can?
Will submit PR unless there are objections. Otherwise, will add help text.https://lab.civicrm.org/dev/drupal/-/issues/187Installing drupal/fontawesome causes CiviCRM to freeze the browser.2023-05-24T06:53:44Zdarren.woodsInstalling drupal/fontawesome causes CiviCRM to freeze the browser.Install vanilla Drupal 9 via composer.
Installed CiviCRM via composer according to docs.
Installed the Fontawesome module: composer require 'drupal/fontawesome:^2.25'
Loading any CiviCRM paths /civicrm/admin causes the browser to enter...Install vanilla Drupal 9 via composer.
Installed CiviCRM via composer according to docs.
Installed the Fontawesome module: composer require 'drupal/fontawesome:^2.25'
Loading any CiviCRM paths /civicrm/admin causes the browser to enter an infinite loop once the DOM is loaded.
Tracked it down to all.js from Fontawesome.
Removing Fontawesome module resolves it: composer remove 'drupal/fontawesome'
Could this be related to the civicrm asset plugin?
Before the browser freezes, I can see there are two icons for each admin menu option.
We would dearly love to use fa icons in our Drupal theme :pray:https://lab.civicrm.org/dev/core/-/issues/4018Extension upgrades are not run if there are no core upgrades2022-12-02T12:24:19ZherbdoolExtension upgrades are not run if there are no core upgrades@totten recently did: https://github.com/civicrm/civicrm-core/pull/24030 to include extension upgrades in the core upgrades.
I've noticed a couple times, however, that there seem to be extension upgrades still waiting after upgrading Ci...@totten recently did: https://github.com/civicrm/civicrm-core/pull/24030 to include extension upgrades in the core upgrades.
I've noticed a couple times, however, that there seem to be extension upgrades still waiting after upgrading CiviCRM code base and running `cv upgrade:db`. Could it be that if there are no core upgrade hooks waiting that it won't run the extension upgrades? It does seem likely given my chat with @colemanw https://chat.civicrm.org/civicrm/pl/cfd18cjpofg5iesh7o4zqejcbh.https://lab.civicrm.org/dev/core/-/issues/3836Searching by phone in Advanced Search with a non-default Search Profile retur...2022-11-14T19:16:04ZbrienneSearching by phone in Advanced Search with a non-default Search Profile returns DB Error: no such fieldOverview
----------------------------------------
If a user tries to search by a phone number via Advanced Search and uses a non-default Search Profile that includes a phone number and at least one location field (i.e. city), then the se...Overview
----------------------------------------
If a user tries to search by a phone number via Advanced Search and uses a non-default Search Profile that includes a phone number and at least one location field (i.e. city), then the search produces an error with the message `DB error: no such field`.
Reproduction steps
----------------------------------------
1. Go to **Administer > Custom Data and Screens > Profiles**
1. Click **Add Profile**
1. Enter a Profile Name and check the box next/to the left of *Search Views*
1. Add fields to your Profile. At a minimum, be sure to add **Contacts > Phone > Primary > Phone** and one address field, such as **Contacts > City > Primary**. (I also included first and last name as fields)
1. Go to **Administer > Custom Data and Screens > Search Preferences**. Select the name of your test Profile from the drop down menu for the **Default Contact Search Profile** (roughly halfway down on the settings page).
1. Hover over **Search** on the navbar and click **Advanced Search**
1. Enter a phone number (or even just a number/partial number) and click **Search**
1. At this point, the user will receive an error that states `DB error: no such field`
Current behaviour
----------------------------------------
Instead of returning the results when a user searches by phone number when a non-default Search Profile includes at least one address field, the user receives an error message that the field does not exist. From the SQL displayed in the error message, this happens because the query does not include a statement to join on the address table, but references it in another join statement in the `ON` clause.
```
| Type | DB_Error |
|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Code | -19 |
| Message | DB Error: no such field |
| Mode | 16 |
| UserInfo | SELECT DISTINCT LEFT(contact_a.sort_name, 1) as sort_name FROM civicrm_contact contact_a LEFT JOIN civicrm_phone `1-phone-1` ON contact_a.id = `1-phone-1`.contact_id AND ( `1-phone-1`.phone_type_id = '1' OR `1-phone-1`.phone_type_id IS NULL ) AND ( `1-phone-1`.is_primary = 1 ) LEFT JOIN civicrm_phone ON (contact_a.id = civicrm_phone.contact_id AND civicrm_phone.is_primary = 1) LEFT JOIN civicrm_location_type `1-location_type` ON ( ( `1-address`.location_type_id = `1-location_type`.id ) ) WHERE ( civicrm_phone.phone_numeric LIKE '%301%' ) AND ( 1 ) AND (contact_a.is_deleted = 0) [nativecode=1054 ** Unknown column '1-address.location_type_id' in 'on clause'] |
| DebugInfo | SELECT DISTINCT LEFT(contact_a.sort_name, 1) as sort_name FROM civicrm_contact contact_a LEFT JOIN civicrm_phone `1-phone-1` ON contact_a.id = `1-phone-1`.contact_id AND ( `1-phone-1`.phone_type_id = '1' OR `1-phone-1`.phone_type_id IS NULL ) AND ( `1-phone-1`.is_primary = 1 ) LEFT JOIN civicrm_phone ON (contact_a.id = civicrm_phone.contact_id AND civicrm_phone.is_primary = 1) LEFT JOIN civicrm_location_type `1-location_type` ON ( ( `1-address`.location_type_id = `1-location_type`.id ) ) WHERE ( civicrm_phone.phone_numeric LIKE '%301%' ) AND ( 1 ) AND (contact_a.is_deleted = 0) [nativecode=1054 ** Unknown column '1-address.location_type_id' in 'on clause'] |
```
Expected behaviour
----------------------------------------
When a user searches by phone number via Advanced Search they should not receive an error and instead be directed to the results page of the search.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.54.alpha1
Comments
----------------------------------------
[PR #24450](https://github.com/civicrm/civicrm-core/pull/24450) proposes a fix for this issue