CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-12-11T05:03:27Zhttps://lab.civicrm.org/dev/core/-/issues/793Improve administrative experience for managing/upgrading bundled extensions2023-12-11T05:03:27ZtottenImprove administrative experience for managing/upgrading bundled extensionsBackground
----------
The canonical release of CiviCRM now includes a couple extensions (e.g. `org.civicrm.api4` and `com.iatspayments.civicrm`). The business-need for distributing bundled extensions will continue to grow as we progress...Background
----------
The canonical release of CiviCRM now includes a couple extensions (e.g. `org.civicrm.api4` and `com.iatspayments.civicrm`). The business-need for distributing bundled extensions will continue to grow as we progress on "leap by extension".
Problem
-------
Suppose we have a process like this:
1. Administrator Alice downloads/installs CiviCRM 5.0 with a bundled copy of an extension, APIv4 (4.0.0).
2. Developer Bob publishes a new version of APIv4 (4.0.1).
3. Alice sees APIv4 (4.0.1) and upgrades it.
4. Bob publishes another version of APIv4 (4.1.0).
5. The next version of CiviCRM (5.1.0) is released. It bundles APIv4 (4.1.0).
6. Alice installs CiviCRM (5.1.0). It includes APIv4 (4.1.0), but Alice's system still uses APIv4 (4.0.1).
The situation should be resolvable by either removing or upgrading Alice's extra copy of APIv4 (4.0.1) stored in the site's customizable `extensionsDir` (e.g. `$WEBROOT/sites/default/files/civicrm/ext`).
However, the situation can be confusing (leading to support requests). This particularly true if there are any intertwined dependencies.
Analysis
--------
Why does this happen? Well, CiviCRM loads extensions from a list of *prioritized layers*:
* (E1) Extensions installed by the web-based administrator in the customizable extensionsDir (e.g. `$WEBROOT/sites/default/files/civicrm/ext`).
* (E2) Extensions installed with the CiviCRM bundle (e.g. `$WEBROOT/sites/all/modules/civicrm`).
* (E3) Extensions installed in site's master composer project (e.g. `$WEBROOT/vendor`).
When Alice (step 3) downloads any extension manually (whether upgrade or anew), it goes into the first layer E1. The version she specifically downloads will always take precedence over any versions in layer E2/E3.
Generally, this prioritization is a result of two opinions that:
* Web-administrators tend to be "closer to the ground" on the goal/situation for a particular site -- their upstream providers (e.g. civicrm.org and/or saas/partner) are more disconnected. Therefore, *if* the admin forms an opinion about what version to run, then it should take precedence.
* Only one of those layers (the first) tends to be writable at run-time. This may be a general security prophylactic, or it may specifically be a protection in multitenant deployments.
Those opinions are valid in many cases, but they are certainly not universal. For example:
* Many web-based administrators are only casually engaged (e.g. they're not tracking the nitty-gritty of each release every day), and many don't really *want* to think about the versions of each extension. They may not realize their upgrade today causes them to take greater ownership over future upgrades.
* Many WordPress and Joomla builds are usually web-writeable, which means that they are not confined to the customizable `extensionsDir` -- one can put upgraded code in any location desired/appropriate/necessary.
Possible Resolutions
--------------------
There are several possible ways to resolve this. The choice is an *ambiguous question* -- none is stand-out obvious winner; each option involves a trade-off which has some impact on the developer-experience/administrator-experience and which will likely be good and bad for different groups of people. However, to resolve the ambiguous question, it may help to list the possible resolutions:
* **REORDER**: Change the order of the layers -- put the custom folder (E1) below the others (E2/E3).
* **Strengths**: It is probably the simplest change (i.e. the explanation and implementation are both short).
* **Challenges**: It inhibits the ability of site-owners to act as testers and early-adopters on those extensions. Also, when it goes live, it may cause unexpected changes for sites who have tried to manage these extensions on their own.
* **BLOCK**: In step 3, block Alice from upgrading the extension. She may only upgrade an extension if it's stored in E1. If an extension is provided by another layer (E2/E3), then prohibit downloads/upgrades that would go into E1. Provide messaging to indicate why upgrades aren't allowed.
* **Strength**: This tightens the general shape of deployments across the ecosystem, which would be an overall simplification that makes it easier to reason about the system.
* **Challenges**: It inhibits the ability of site-owners to act as testers and early-adopters on those extensions. It also puts a greater responsibility on upstream bundler to issue a new bundle whenever one if its constituent parts has a critical fix.
* **ADVISE**: After step 3, the "Manage Extensions" screen (and possibly the status-check screen) should display a notice indicating that an extension is overridden. The administrator still has the prerogative here, but the app should try harder to educate/inform them about the consequences/responsibilities.
* **Strength**: This is the most backward-compatible resolution -- it doesn't change the real behavior, so no one can accuse of breaking anything.
* **Challenges**: The underlying situation (multiple copies of the same extension) can be confusing, and we're giving more of a blessing. That may lead to questions like "what order should I apply upgrades in?" for which there may not be a simple+generic answers.
* **UPGRADE-IN-PLACE**: In step 3, allow Alice to upgrade the extension. However, the upgrade should **not** go into the extension folder -- it should replace the existing code (wherever that may be). If the folder is not writeable, display a warning with advice on how to make it writeable/upgradeable.
* **Strength**: Most people reading the user-interface (but without any expertise in CMS+Civi file-structures) would probably expect this behavior.
* **Challenges**: The extensions can live in spaces which we don't "own" (like E3 - `$WEBROOT/vendor`). It's a bit scary to automatically delete a whole file-tree if we haven't traditionally "owned" that part of the filesystem. Also, if Alice in step 3 had upgraded really far ahead (APIv4 4.3.beta1), then the upgrade in step 6 would revert her system to 4.2.0.
* **DEFER => COMPOSER**: This issue reflects only one of several edge-cases in managing dependencies for a build. Don't spend any more time trying to solve this one scenario -- instead, focus energy on adopting a more powerful build system like `composer`, where their documentation/workflows/UIs address the various edge-cases.
* **Strength**: More comprehensive approach. More "industry standard".
* **Challenges**: Generally, longest process of any of this list. Most extensions aren't currently accessible via `composer` (although there's a [proof-of-concept bridge](https://github.com/totten/comex)). `composer` is primarily a CLI tool, and it's not currently widely deployed among Civi sites, so adoption will be an undertaking.
* **VERSION-PRECEDENCE**: Continue to allow extension code to be stored in all these locations. However, change prioritization -- it doesn't matter *where* the extension is stored. It only matters *what the version number* is. Highest local version wins.
* **Strength**: This also feels intuitive to me.
* **Challenges**: During the life of an extension, the absolute URL+path of its assets may fluctuate. For some use-cases (where hyperlinks and paths are integrated with another system or stored as content), this could cause problems.https://lab.civicrm.org/dev/core/-/issues/794Expose address name in the invoice templates2022-10-09T05:03:32ZyashodhaExpose address name in the invoice templatesAllow *domain_address_name* to be used as address name in invoice template.Allow *domain_address_name* to be used as address name in invoice template.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/795PHP Warning "explode() expects parameter 2 to be string, array given" for mul...2019-03-20T14:59:22ZVirenmagePHP Warning "explode() expects parameter 2 to be string, array given" for multi-value country fieldsI am getting above error while trying to save multiple country for agent profile. And when I search about this error I found that unnecessary use of explode() function on line 127. You can see more about on https://lab.civicrm.org/dev/co...I am getting above error while trying to save multiple country for agent profile. And when I search about this error I found that unnecessary use of explode() function on line 127. You can see more about on https://lab.civicrm.org/dev/core/issues/216 and code file
https://lab.civicrm.org/dev/core/blob/master/CRM/Core/BAO/CustomValueTable.php#L127
So according to me you need to ask to civiCRM team to comment line 127
$mulValues = explode(',', $value);
![error](/uploads/c124cf6618247c06ef570df0639f869c/error.png)5.13.0https://lab.civicrm.org/dev/core/-/issues/796Updating priceset when selected option is full2022-10-09T05:03:32ZwdecraeneUpdating priceset when selected option is fullYou want to edit as an admin the priceset of an participant, the option the participant selected is full.
![Schermafbeelding_2019-03-12_om_21.21.42](/uploads/4e6f018316f4f102805ad121f83f46d7/Schermafbeelding_2019-03-12_om_21.21.42.png)
...You want to edit as an admin the priceset of an participant, the option the participant selected is full.
![Schermafbeelding_2019-03-12_om_21.21.42](/uploads/4e6f018316f4f102805ad121f83f46d7/Schermafbeelding_2019-03-12_om_21.21.42.png)
You change the value to another option and save it.
![Schermafbeelding_2019-03-12_om_21.24.34](/uploads/cab5f64141209839934a3f517be84095/Schermafbeelding_2019-03-12_om_21.24.34.png)
After saving, the option did not change.
But, when you change the radio after the selected one it does save it.
Reason: behind the option which is selected and full, there is a hidden option field which is selected. When you select the option before this radio and post the form, the browser only post the last one (a radio field can only have one selected value). That is also the reason why the value is changed when you select the radio after the original one.
Solution ? No hidden/disabled options for admins? Should admins be able to override the max possibilities per participant?https://lab.civicrm.org/dev/core/-/issues/3553Preview as HTML doesn't open window at all2022-06-11T14:50:54ZscardiniusPreview as HTML doesn't open window at allCRM_Mailing_BAO_TrackableURL::getTrackerURL() requires id of mailing but after https://lab.civicrm.org/dev/mail/issues/20 mailing_id is removed from params to Mailing.preview
https://github.com/civicrm/civicrm-core/commit/0075b0cb75e542...CRM_Mailing_BAO_TrackableURL::getTrackerURL() requires id of mailing but after https://lab.civicrm.org/dev/mail/issues/20 mailing_id is removed from params to Mailing.preview
https://github.com/civicrm/civicrm-core/commit/0075b0cb75e5422660366acf280538167369d8ba#diff-d08e5d3ceca1972df6d467b2824ffab5R279
errors from api rest
```
{"error_code":"unknown error","sql":"INSERT INTO civicrm_mailing_trackable_url (url ) VALUES ('https:\/\/onet.pl' )
[nativecode=1364 ** Field 'mailing_id' doesn't have a default value]",
"tip":"add debug=1 to your API call to have more info about the error",
"is_error":1,
"error_message":"DB Error: unknown error",
"debug_information":"INSERT INTO civicrm_mailing_trackable_url (url ) VALUES ('https:\/\/onet.pl' ) [nativecode=1364 ** Field 'mailing_id' doesn't have a default value]"}
```5.12.3https://lab.civicrm.org/dev/core/-/issues/797KAM appearing on front-end under WordPress2019-03-13T12:54:12ZhaystackKAM appearing on front-end under WordPress@colemanw The KAM menu is appearing on the front-end when it shouldn't. See this form on the base page when logged in:
https://wpmaster.demo.civicrm.org/contribution-page/
Probably just a question of checking `$config->userFrameworkFro...@colemanw The KAM menu is appearing on the front-end when it shouldn't. See this form on the base page when logged in:
https://wpmaster.demo.civicrm.org/contribution-page/
Probably just a question of checking `$config->userFrameworkFrontend`https://lab.civicrm.org/dev/core/-/issues/798Prefix/suffix select2 renders oddly on public-facing pages2019-03-14T21:07:10ZJonGoldPrefix/suffix select2 renders oddly on public-facing pagesPrefix and suffix fields in contribution/event profiles render incorrectly on public-facing pages. See screenshot:
![Selection_823](/uploads/5d05559371fa6c062b2dad8ecd8c2901/Selection_823.png)
There are a couple of ways to fix, I'll do...Prefix and suffix fields in contribution/event profiles render incorrectly on public-facing pages. See screenshot:
![Selection_823](/uploads/5d05559371fa6c062b2dad8ecd8c2901/Selection_823.png)
There are a couple of ways to fix, I'll do whatever folks like best.
One is to fix `civicrm.css` here:
```css
.crm-container.crm-public .select2-container .select2-choice {
padding: 5px 5px 5px 8px;
height: auto;
}
```
Changing `height: auto` to `height: 26px` matches the backend `select2.css`. Other select2 widgets are unaffected because they have placeholder text. I could also add placeholder text to the default rendering of this widget, but I think the CSS fix makes more sense.
I'll submit a PR to continue this discussion.5.13.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/799While upgrading from CiviCRM 4.6 to 5.10.x , old smartgroups stopped refreshi...2020-07-13T02:47:16ZVangelisPWhile upgrading from CiviCRM 4.6 to 5.10.x , old smartgroups stopped refreshing contactsSteps to reproduce:
1) Save a smartgroup that was using eg. a customfield value on a CiviCRM 4.6.x environment
2) Migrate to the latest CiviCRM
3) Change a contact so that the change can reflect to that smartgroup
4) Do a simple search ...Steps to reproduce:
1) Save a smartgroup that was using eg. a customfield value on a CiviCRM 4.6.x environment
2) Migrate to the latest CiviCRM
3) Change a contact so that the change can reflect to that smartgroup
4) Do a simple search using this smartgroup. Contact should not appear. `drush cvapi job.group_rebuild` doesn't fix the issue.
Resolution:
We traced this down to the fact that old form values and in general saved search settings were not being converted to new form values during the upgrade process.
There are 2 possible solutions on this:
1) Open the smartgroup criteria, do a search and `update smartgroup`. This is efficient if there are not many smartgroups in the installation.
2) Include a fix during the upgrade process that will call in essence those lines:
```php
// Read the existing form values
$formValues = CRM_Contact_BAO_SavedSearch::getFormValues($SavedSearchId);
// Update saved search record.
$savedSearch = new CRM_Contact_BAO_SavedSearch();
$savedSearch->id = $SavedSearchId;
$savedSearch->form_values = serialize(CRM_Contact_BAO_Query::convertFormValues($formValues));
$savedSearch->save();
```
In our case, we followed this path:
1) We've made a custom API call to do a search for all smartgroups and then apply the above fix on each one of these.
2) Then we issued a `TRUNCATE TABLE civicrm_group_contact_cache`.
3) Lastly, we issued a `drush cvapi job.group_rebuild` to force a smartgroup rebuild.
It seems that it's fixing our issue.
Do you believe that the upgrader needs a patch to resolve this situation?https://lab.civicrm.org/dev/core/-/issues/800Allow operator as a parameter for Advanced Filter in auto-complete Contact Re...2022-10-10T05:03:25ZyashodhaAllow operator as a parameter for Advanced Filter in auto-complete Contact Reference fieldCurrently you can specify Advanced filters for auto-complete Contact Reference fields
> EXAMPLE: To list Students in group 3: "action=get&group=3&contact_sub_type=Student"
But if I want to search all contacts with `contact_sub_type ...Currently you can specify Advanced filters for auto-complete Contact Reference fields
> EXAMPLE: To list Students in group 3: "action=get&group=3&contact_sub_type=Student"
But if I want to search all contacts with `contact_sub_type != 'Student'`
I propose that we pass operator something like` contact_sub_type_op = 'neq'`
which would do the same. This is consistent with what we are doing in reports as well.https://lab.civicrm.org/dev/core/-/issues/801Thank You letters have an invalid 'from' when sending from the contact's emai...2019-03-25T21:48:33ZbgmThank You letters have an invalid 'from' when sending from the contact's email addressTo reproduce:
* Record a contribution for a contact
* Find Contributions, select the contribution, Send Thank You Letters
* Select the option to send emails
* Use the default from of the contact, which should be the email on their conta...To reproduce:
* Record a contribution for a contact
* Find Contributions, select the contribution, Send Thank You Letters
* Select the option to send emails
* Use the default from of the contact, which should be the email on their contact record.
When sending the emails, CiviCRM will throw an error that there is no 'from' in the email, which sounds like this SE question: https://civicrm.stackexchange.com/questions/21780/civicontribute-thank-you-letter-not-emailed-using-cividesk-sparkpost/24948
Inspecting the form html reveal's this:
![Capture_d_écran_de_2019-03-14_12-45-04](/uploads/04998410f1c204cb52310c0dbb6da0fc/Capture_d_écran_de_2019-03-14_12-45-04.png)
It seems very familiar to issue #3575.12.0https://lab.civicrm.org/dev/core/-/issues/802Unsubscribe message doesn't display consistently2022-10-10T05:03:26ZRoseLaniganUnsubscribe message doesn't display consistentlyWhen an individual unsubscribes from a mailing group, they get a standard message confirmation message that says they have been unsubscribed (see image 001). However, the message specified in the Headers, Footers and Automated Messages l...When an individual unsubscribes from a mailing group, they get a standard message confirmation message that says they have been unsubscribed (see image 001). However, the message specified in the Headers, Footers and Automated Messages list includes a link to resubscribe (image 002) that doesn't appear.
![image001](/uploads/737d703e38b8ec9a63b0baa549715a30/image001.jpg)
![image002](/uploads/457215465165297186362e2938ab07f8/image002.jpg)https://lab.civicrm.org/dev/core/-/issues/803Upgrade and vendor HMTLPurifier2019-04-11T00:26:06ZmfbUpgrade and vendor HMTLPurifierHTMLPurifier version 4.3.0 can be found at https://github.com/civicrm/civicrm-packages/blob/master/IDS/vendors/htmlpurifier but current version, with PHP 7.2 compatibility, is 4.10.0
Ideally we could move it to composer.json for core.HTMLPurifier version 4.3.0 can be found at https://github.com/civicrm/civicrm-packages/blob/master/IDS/vendors/htmlpurifier but current version, with PHP 7.2 compatibility, is 4.10.0
Ideally we could move it to composer.json for core.https://lab.civicrm.org/dev/core/-/issues/804Address indiscrepancy in participant count in summary report - due to presenc...2023-04-26T05:03:22ZeileenAddress indiscrepancy in participant count in summary report - due to presence of currency in $0 participant recordsOpened this to track
https://github.com/civicrm/civicrm-core/pull/13037Opened this to track
https://github.com/civicrm/civicrm-core/pull/13037https://lab.civicrm.org/dev/core/-/issues/805CiviCRM cases don't appear on contact case tab if no activities2023-09-28T05:03:22ZDevAppCiviCRM cases don't appear on contact case tab if no activitiesWhen viewing a client record, then clicking the Cases tab - The cases are not displayed if the case has no activities associated with it. This can happen if you don't have a standard timeline with the case, which typically has the open j...When viewing a client record, then clicking the Cases tab - The cases are not displayed if the case has no activities associated with it. This can happen if you don't have a standard timeline with the case, which typically has the open job activity.
Doing some debugging, the SQL join appears to be an INNER JOIN and not a LEFT JOIN for civicrm_activity. When changed to a LEFT JOIN, then the cases without activities show as the join doesn't filter by the join.
```
SELECT civicrm_case.id as case_id
FROM civicrm_contact contact_a
LEFT JOIN civicrm_phone
ON (contact_a.id = civicrm_phone.contact_id AND civicrm_phone.is_primary = 1)
LEFT JOIN civicrm_case_contact
ON civicrm_case_contact.contact_id = contact_a.id
INNER JOIN civicrm_case ON civicrm_case_contact.case_id = civicrm_case.id
LEFT JOIN civicrm_relationship case_relationship ON ( case_relationship.contact_id_a = civicrm_case_contact.contact_id AND case_relationship.contact_id_b = 1 AND case_relationship.case_id = civicrm_case.id )
LEFT JOIN civicrm_relationship_type case_relation_type ON ( case_relation_type.id = case_relationship.relationship_type_id AND case_relation_type.id = case_relationship.relationship_type_id )
LEFT JOIN civicrm_case_activity
ON civicrm_case_activity.case_id = civicrm_case.id
INNER JOIN civicrm_activity case_activity
ON ( civicrm_case_activity.activity_id = case_activity.id AND case_activity.is_current_revision = 1 )
LEFT JOIN civicrm_option_group option_group_activity_type
ON (option_group_activity_type.name = 'activity_type')
LEFT JOIN civicrm_option_value rec_activity_type ON (case_activity.activity_type_id = rec_activity_type.value AND option_group_activity_type.id = rec_activity_type.option_group_id )
LEFT JOIN civicrm_option_group option_group_case_status
ON (option_group_case_status.name = 'case_status')
LEFT JOIN civicrm_option_value case_status
ON (civicrm_case.status_id = case_status.value AND option_group_case_status.id = case_status.option_group_id )
LEFT JOIN civicrm_case_type ON civicrm_case.case_type_id = civicrm_case_type.id WHERE ( contact_a.id = '1' AND civicrm_case.is_deleted = 0 ) AND (contact_a.is_deleted = 0)
GROUP BY civicrm_case.id
```
Page: CRM_Case_BAO_Casehttps://lab.civicrm.org/dev/core/-/issues/806DB Error:: Already exists during renewing membership automatically2019-04-03T16:58:22ZPradeep Nayakpradpnayak@gmail.comDB Error:: Already exists during renewing membership automaticallyI have a cron job that runs smart debit sync every day for recurring contribution and its failing with DB Error: already exists
After looking it carefully in details found that it fails when the original contribution of recurring has ta...I have a cron job that runs smart debit sync every day for recurring contribution and its failing with DB Error: already exists
After looking it carefully in details found that it fails when the original contribution of recurring has tax_amount set.
Mar 18 10:53:06 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id , tax_amount ) VALUES ('civicrm_contribution' , 20069 , 20069 , 1 , 'Contribution Amount' , 1 , 30.00 , 30.00 , 1 , 33 , 6 ) [nativecode=1062 ** Duplicate entry 'civicrm_contribution-20069-20069-1-1' for key 'UI_line_item_value']
[type] => DB_Error
[user_info] => INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id , tax_amount ) VALUES ('civicrm_contribution' , 20069 , 20069 , 1 , 'Contribution Amount' , 1 , 30.00 , 30.00 , 1 , 33 , 6 ) [nativecode=1062 ** Duplicate entry 'civicrm_contribution-20069-20069-1-1' for key 'UI_line_item_value']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="INSERT INTO civicrm_line_item (entity_table , entity_id , contribution_id , price_field_id , label , qty , unit_price , line_total , price_field_value_id , financial_type_id , tax_amount ) VALUES ('civicrm_contribution' , 20069 , 20069 , 1 , 'Contribution Amount' , 1 , 30.00 , 30.00 , 1 , 33 , 6 ) [nativecode=1062 ** Duplicate entry 'civicrm_contribution-20069-20069-1-1' for key 'UI_line_item_value']"]
)https://lab.civicrm.org/dev/core/-/issues/807Error in participant counts on events with waitlists2022-10-11T05:03:32ZCharlie DunlaveyError in participant counts on events with waitlistsThere seems to be a participant calculation error at a specific stage in the workflow for events using waitlists, which is making the waitlist feature unuseable.
When a place becomes available on an event with a waitlist, the reminder e...There seems to be a participant calculation error at a specific stage in the workflow for events using waitlists, which is making the waitlist feature unuseable.
When a place becomes available on an event with a waitlist, the reminder email is being sent correctly to the person at the top of the waitlist, but when this user clicks on the registration link in the email, they see the 'Oops, it looks like there are no spaces' message.
At the confirmation page stage, it looks like Civi is counting all participants as opposed to just those with counted set to true. Are you able to take a look?
Thank you,
Charliehttps://lab.civicrm.org/dev/core/-/issues/808support reCaptcha v32020-11-24T22:45:22ZJoeMurraysupport reCaptcha v3There's a new reCaptcha that does not show I am not a robot, but does require evaluation of a score returned. Would be good to support it before current v2 goes away (this is Google, days before Google+ is disappearing ;) ).
See https:/...There's a new reCaptcha that does not show I am not a robot, but does require evaluation of a score returned. Would be good to support it before current v2 goes away (this is Google, days before Google+ is disappearing ;) ).
See https://developers.google.com/recaptcha/docs/versionshttps://lab.civicrm.org/dev/core/-/issues/809Bug with CiviCRM 5.10.3 Remote Profiles HTML Form Snippet Form Action URL2022-10-24T05:03:34ZjohngehrigBug with CiviCRM 5.10.3 Remote Profiles HTML Form Snippet Form Action URLVersion: CiviCRM 5.10.3
Type: Bug
With the update to CiviCRM 5.10.3, I noticed the form action URL in the HTML Form Snippet generated for Remote Profile submissions has changed, breaking the form submission functionality for anonymous ...Version: CiviCRM 5.10.3
Type: Bug
With the update to CiviCRM 5.10.3, I noticed the form action URL in the HTML Form Snippet generated for Remote Profile submissions has changed, breaking the form submission functionality for anonymous users with all newly generated HTML Form Snippets.
This is the first time I have noticed this bug, which was definitely introduced sometime after version CiviCRM 5.7.2, the last time I generated an HTML Form Snippet that was used with a Remote Profile.
Previously, the HTML Form Snippet generated code with a form action URL that posted to the "create profile" URL, allowing form submissions from anonymous users:
`<form action="https://wpmaster.demo.civicrm.org/civicrm/?page=CiviCRM&q=civicrm%2Fprofile%2Fcreate" method="post" name="Edit" id="Edit" class="CRM_Profile_Form_Edit" >`
After the update, the code generated by the HTML Form Snippet includes a form action URL that posts to the default "admin group":
`<form action="https://wpmaster.demo.civicrm.org/civicrm/?page=CiviCRM&q=civicrm%2Fadmin%2Fuf%2Fgroup" method="post" name="Edit" id="Edit" class="CRM_Profile_Form_Edit" >`
With the above form action URL, anonymous users see the following error when the user clicks the "Submit" button:
> You do not have permission to access this content.
Manually changing the code in the HTML Form Snippet to use a form action URL with the previous "create profile" version restores the functionality.
This bug is specifically related to the generate HTML Form Snippet code as Profiles work properly for anonymous users when inserted using the "Add CiviCRM Public Pages" button within WordPress, which inserts the code that includes the correct "create profile" form action URL.
I tested both WordPress and Drupal 7 demo sites and was able to replicate the bug with ONLY the WordPress demo site:
https://wpmaster.demo.civicrm.org/
https://dmaster.demo.civicrm.org/
----
Steps to Reproduce Bug with WordPress CiviCRM 5.10.3+:
Login
CiviCRM > Administer > System Settings > Misc (Undelete, PDFs, Limits, Logging, Captcha, etc.)
For the "Accept profile submissions from external sites" option, select "Yes" and then click "Save"
Administer > Custom Data and Screens > Profiles
For any Profile, generate the code by clicking: more > HTML Form Snippet
The code generated by the updated version includes a "post" action URL to the "admin group"https://lab.civicrm.org/dev/core/-/issues/810Non-primary details exported in primary-only exports, when the setting 'Searc...2023-04-05T05:03:18ZAndrew WestNon-primary details exported in primary-only exports, when the setting 'Search Primary Details Only' is set to 'no'If you run an export with 'Export PRIMARY fields', but you have the setting 'Search Primary Details Only' set to 'No', the primary filter is not applied and you simply get the first available row in the table. This also happens when you ...If you run an export with 'Export PRIMARY fields', but you have the setting 'Search Primary Details Only' set to 'No', the primary filter is not applied and you simply get the first available row in the table. This also happens when you select the 'Primary' option when exporting individual fields.
This definitely applies to postal addresses. I haven't tested emails but I think it'll happen there too.
It happens because of this line in CRM_Contact_BAO_Query:
https://github.com/civicrm/civicrm-core/blob/a2540ad336faf7fb0218055a485c1a702200293f/CRM/Contact/BAO/Query.php#L446
which defaults to using the value from the setting. If this is set to no, the result SQL clause doesn't include 'is_primary = 1'.
CRM_Export_BAO_ExportProcessor creates the Query object here:
https://github.com/civicrm/civicrm-core/blob/a2540ad336faf7fb0218055a485c1a702200293f/CRM/Export/BAO/ExportProcessor.php#L509
but doesn't pass through a value for 'primaryLocationOnly' to override the default setting.
I can presumably adapt the above to pass through primaryLocationOnly when users have selected the 'Export PRIMARY fields' option - that *seems* simple enough. I haven't had a chance to dig into how it works when the export specifies individual fields, though - that seems like it'd be more complicated.
To replicate on demo site:
1. Create a new tmp group
2. Find a contact with an existing primary address
3. Add a new address for them, and set it to primary
4. Add this contact to the tmp group
4. Turn off the setting 'Search Primary Details Only'
5. Search for all members of the tmp group, and export them using 'Export PRIMARY fields only'
6. The contact's address in the CSV will be the original address, which is non-primaryhttps://lab.civicrm.org/dev/core/-/issues/811Autocomplete select list disabled options2019-03-19T23:27:09ZPradeep Nayakpradpnayak@gmail.comAutocomplete select list disabled optionsCustom field with type Autocomplete-select lists disabled options.
![Autocomplete-select](/uploads/4255d3183f1e8baf55aee8e4201b95cc/Autocomplete-select.gif)Custom field with type Autocomplete-select lists disabled options.
![Autocomplete-select](/uploads/4255d3183f1e8baf55aee8e4201b95cc/Autocomplete-select.gif)5.13.0