CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2021-09-13T00:04:33Zhttps://lab.civicrm.org/dev/core/-/issues/522Add case tokens to email activities2021-09-13T00:04:33ZeileenAdd case tokens to email activitieshttps://lab.civicrm.org/dev/core/-/issues/521PCP Owner notification email sending before payment2023-08-14T05:03:17Zrita_compucorpPCP Owner notification email sending before paymentHi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates y...Hi there,
When you are the owner of a fundraising page, you are supposed to receive a notification email after a successful donation has been made to your fundraising page. However when you are using a payment processor that navigates you out from civicrm to its own payment page (like sagepay, or paypal standard) the owner notification is sent before the payment has been made.
Steps:
- create a contribution page and enable fundraising pages to be created under it
- make the payment processor to be Sagepay or Paypal standard
- create a fundraising page
- then log out and start donating to the fundraising page
- when you click confirm button on the fundraising page, you will get navigated to the payment processor you set up for the contribution page --> this is the point when the notification email is sent to the fundraiser
Expected result: notification for the owner is sent only after a successful donation to the fundraising pagehttps://lab.civicrm.org/dev/core/-/issues/519Event receipts for paid events contains extraneous information2022-09-15T05:03:47ZmadhaviEvent receipts for paid events contains extraneous informationCurrently using CiviCRM 5.3.2 and drupal 7.60
Receipts for events paid via PayPal have extra information related to contribution.
**To reproduce issue:**
1. Add custom fields of your choice for Contributions
2. Create a paid event a...Currently using CiviCRM 5.3.2 and drupal 7.60
Receipts for events paid via PayPal have extra information related to contribution.
**To reproduce issue:**
1. Add custom fields of your choice for Contributions
2. Create a paid event and assign `PayPal Standard` payment processor.
3. Enable online registration for the event and set `Send Confirmation Email` to `Yes`.
4. Register a participant for the event.
5. Check the receipt received and see if you get Contribution related custom fields in the email.
Anyone is facing this issue? May be with other payment processor?https://lab.civicrm.org/dev/core/-/issues/512Cannot update checkbox fields in activities using "Update Multiple Activities"2022-10-25T05:03:40ZalarmingcodCannot update checkbox fields in activities using "Update Multiple Activities"Error found on client site (5.3.1) replicated on sandbox today
Updating activity custom data via "Update multiple activities" (Batch update via profile)
When data in a checkbox field is updated, error message appears
```
CiviCRM_API3_...Error found on client site (5.3.1) replicated on sandbox today
Updating activity custom data via "Update multiple activities" (Batch update via profile)
When data in a checkbox field is updated, error message appears
```
CiviCRM_API3_Exception: "'' is not a valid option for field custom_15"
#0 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Activity/Form/Task/Batch.php(242): civicrm_api3("activity", "create", (Array:7))
#1 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Form.php(489): CRM_Activity_Form_Task_Batch->postProcess()
#2 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/StateMachine.php(160): CRM_Core_Form->mainProcess()
#3 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Next.php(61): CRM_Core_StateMachine->perform(Object(CRM_Activity_Form_Task_Batch), "next", "Next")
#4 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Activity_Form_Task_Batch), "next")
#5 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Activity_Form_Task_Batch), "next")
#6 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("next")
#7 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(309): CRM_Core_Controller->run((Array:3), (Array:1))
#8 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
#9 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#10 /srv/buildkit/build/dmaster/sites/all/modules/civicrm/drupal/civicrm.module(445): CRM_Core_Invoke::invoke((Array:3))
#11 /srv/buildkit/build/dmaster/includes/menu.inc(527): civicrm_invoke("activity", "search")
#12 /srv/buildkit/build/dmaster/index.php(21): menu_execute_active_handler()
#13 {main}
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
'' is not a valid option for field custom_15
Return to home page.
```
Text fields, radio fields, select fields update without issue.
Issue does not arise when updating contact records via profilehttps://lab.civicrm.org/dev/core/-/issues/495CQ: Migrate simple Preferences & Settings forms to using a Generic class.2023-06-27T05:03:25ZeileenCQ: Migrate simple Preferences & Settings forms to using a Generic class.Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the cl...Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the class 'CRM_Admin_Form_Preferences_Event' and all classes that don't need special sauce would be removed & the xml would be altered to
```
<item>
<path>civicrm/admin/setting/preferences/event</path>
<title>CiviEvent Component Settings</title>
<page_callback>CRM_Admin_Form_Generic</page_callback>
</item>
```
This page would load settings based on filtering setting metadata - so any fields with a key in their metadata like this
```
settings_pages => [
'event' => ['weight' => 10]
]
```
would show up at the url above (note the last value on the url is the filter).
Extensions could use the existing alterSettingMetadata hook to add & remove fields from any pages that use the Generic form to choose their settings and extensions could add settings pages by just adding an xml entry & their metadata
We would convert simple forms & for more complex forms we would attempt to break the inheritance on the 2 existing forms (CRM_Admin_Form_Preferences & CRM_Admin_Form_Setting) in favour of using just the CRM_Admin_Form_SettingTrait in an attempt to grandfather them out.https://lab.civicrm.org/dev/core/-/issues/489Contribution reports don't show Custom Field Sets that extend Organizations o...2022-09-07T05:03:51ZguyiacContribution reports don't show Custom Field Sets that extend Organizations or HouseholdsNone of the contribution reports will show any custom field sets that are used explicitly for extending Organization or Household contact types. The same custom field set will show up if you change it in the database to extend All Contac...None of the contribution reports will show any custom field sets that are used explicitly for extending Organization or Household contact types. The same custom field set will show up if you change it in the database to extend All Contacts or Individuals.
I experienced this on a client site running CiviCRm 5.3.1 under WordPress, and tested it on the WordPress Civi master running 5.8.alpha1 at https://wpmaster.demo.civicrm.org/.https://lab.civicrm.org/dev/core/-/issues/477Print Summary is missing some contact info2018-10-29T20:49:47ZJonGoldPrint Summary is missing some contact infoFrom Stack Exchange: https://civicrm.stackexchange.com/q/27063/12
To replicate:
* Open any individual's contact.
* From the "Actions" button, select "Print Summary".
**Expected**
The contact's employer/job title should be in the print...From Stack Exchange: https://civicrm.stackexchange.com/q/27063/12
To replicate:
* Open any individual's contact.
* From the "Actions" button, select "Print Summary".
**Expected**
The contact's employer/job title should be in the print summary.
**Actual**
It's not.
The last line of `<civiroot>/templates/CRM/Contact/Page/View/Print.tpl` is:
```js
cj('#contact-summary' ).children(':first').remove();
```
The reason for this is lost to the ages, but I suspect this referred to some other DOM element that's long since been removed.
Personally I'd deprecate this whole functionality - but apparently folks are using it, so let's make it work.
If someone wants to mark this "concept: approved" I'll submit the PR.5.8https://lab.civicrm.org/dev/core/-/issues/468Missing transaction ids on reports2023-09-10T05:03:24ZfrancescbassasMissing transaction ids on reports**How to reproduce**
1. Create `contributionA` on `contactA` without assigning any *transaction_id*. A record on `civicrm_contribution` is created with `transaction_id = NULL`
2. Modify `contributionA` to assign a *transaction_id = aaaa...**How to reproduce**
1. Create `contributionA` on `contactA` without assigning any *transaction_id*. A record on `civicrm_contribution` is created with `transaction_id = NULL`
2. Modify `contributionA` to assign a *transaction_id = aaaaaa*. The record previously created on `civicrm_contribution` stills have `transaction_id = ǸULL`
3. Create `contributionB` on `contactA` with a *transaction_id = bbbbbb*
4. Visualize a *Contribution Details* report with column *transaction_id* enabled and filtering results for `contactA`
5. Note that *transaction_id* column for `contributionA` is *empty* instead of *aaaaaa* and *transaction_id* column for `contributionB` is *bbbbbb*
Same happens on *Event Participants List* report for event related contributions in which the *transaction_id* was edited a posteriori.https://lab.civicrm.org/dev/core/-/issues/465Multiselect for Event Type in Advanced Search2023-06-03T05:03:27ZfrancescbassasMultiselect for Event Type in Advanced SearchOriginal issue: https://issues.civicrm.org/jira/browse/CRM-20183
Affected versions: at least from 4.7.16
[Richard](https://issues.civicrm.org/jira/secure/ViewProfile.jspa?name=magnolia61) reports:
> Hello there, for creating a specifi...Original issue: https://issues.civicrm.org/jira/browse/CRM-20183
Affected versions: at least from 4.7.16
[Richard](https://issues.civicrm.org/jira/secure/ViewProfile.jspa?name=magnolia61) reports:
> Hello there, for creating a specific smartgroup I want to be able to select multiple event types from the advanced search page.
>
> The event type is currently a one value field. I would love to make it behave like the participant status or role so more than one can be selected.
>
> Who can point me in the right direction. When I know which files are involved and see some examples I think I can create the PR myself.
>
> This would definitely make our life easier, since the difference search options (the builder, participant search and advanced search are so different in behavior
![Screenshot_from_2017-02-26_17-02-54](/uploads/83d2cb5614dade321364c4fab597dc79/Screenshot_from_2017-02-26_17-02-54.png)https://lab.civicrm.org/dev/core/-/issues/445Proposal - Custom Fields, Is this Field Searchable? option should be enabled ...2021-04-13T03:25:40Zjustinfreeman (Agileware)Proposal - Custom Fields, Is this Field Searchable? option should be enabled by default, currently it is disabled by defaultWhen creating Custom Fields the option **Is this Field Searchable?** is **disabled by default** and as a result any new Custom Field is not searchable. This is frustrating since there is rarely a case when you would not want a field to b...When creating Custom Fields the option **Is this Field Searchable?** is **disabled by default** and as a result any new Custom Field is not searchable. This is frustrating since there is rarely a case when you would not want a field to be available in search. For end users the experience of adding a Custom Field in CiviCRM is like this:
1. Add the Custom Field
1. Add some data to CiviCRM using the new Custom Field
1. Open Search and try to search using the new Custom Field, it is not shown
1. Confusion about why it is not shown in Search
1. Finally, navigate back to the Custom Field and enable the option, Is this Field Searchable?
1. Return to Search and bingo! There it is.
1. Repeat steps for every Custom Field created.
**Proposed Change**
The **Is this Field Searchable?** option should be **enabled by default**, making new Custom Fields available in Search when created - reducing potential confusion as noted above. The user would then have to explicitly disable this option to remove from search.
Agileware Ref: CIVICRM-964https://lab.civicrm.org/dev/core/-/issues/444Updated alterReportVars or new hook for reports2023-08-31T08:51:04ZJoeMurrayUpdated alterReportVars or new hook for reportsThere is no way to currently change a core report to get it to expose custom fields for a component if it does not do it already. It's not unusual an unusual use case to combine creating a custom field with exposing it in a core report....There is no way to currently change a core report to get it to expose custom fields for a component if it does not do it already. It's not unusual an unusual use case to combine creating a custom field with exposing it in a core report. What's needed is to be able to use a hook to add values to $_customGroupExtends. This would also allow extensions to define their own custom fields and add them to a report.
The alterReportVar hook is one place where this functionality could be added https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterReportVar/. The current three supported varTypes, columns, rows and sql, could be extended by a new one, customFields, or some similar name.
There has been criticism in the past of this hook. IIRC @eileen the concern was especially around how it was not well designed for the sql argument, but I don't recall the details. Perhaps it was that the hook was trying to do too many things and provided too broad a surface.
Rather than further complexifying this hook, an alternative approach would be to create a new one focussed exclusively on the issue of changing custom field exposed by a report. Perhaps it could be call alterReportCustomFields.
So we'd like feedback on
1. Should there be hook support for changing the custom fields exposed by reports?
2. If so, should we change alterReportVar or create a new hook, alterReportCustomFields?https://lab.civicrm.org/dev/core/-/issues/442Misc form issues2018-12-08T21:12:48ZAkA84Misc form issuesFound a handful of form-related issues that are pretty quick to fix, just wanted to have the green light on them before opening the PR. All screenshots are taken from https://dmaster.demo.civicrm.org (`v5.8.alpha1`)
## Wrong layout in "...Found a handful of form-related issues that are pretty quick to fix, just wanted to have the green light on them before opening the PR. All screenshots are taken from https://dmaster.demo.civicrm.org (`v5.8.alpha1`)
## Wrong layout in "Tags and Groups" accordion of "New Individual" form
The "Tag(s)" label+select group is missing a `<br>`
*Before*
![tags-before](/uploads/69da499d7792714de2dcf417981cfab7/tags-before.png)
*After*
![tags-after](/uploads/1fc640e4a276e0e0e6b7d70917d7337a/tags-after.png)
## Missing class on text fields in "Dedupe exceptions"
The input fields are missing the standard `crm-form-text class
*Before*
![dedupe-before](/uploads/0861f7c3c98f5b0a8a722b98a858fe92/dedupe-before.png)
*After*
![dedupe-after](/uploads/ca670378bf85ed8b3b8d8caba04764d4/dedupe-after.png)
## Wrong class on `<select>`s in "Submit Credit Card Contribution" modal
The <select> elements have the wrong class: `crm-form-date`
![contribute-select-before](/uploads/09ec405fac0bac56fe5c5cd10db1589f/contribute-select-before.png)
Applying the correct class, `crm-form-select` doesn't change much, but allows Shoreditch to style the selects correctly
![contribute-select-after](/uploads/3fd8125dcae0301d83381e329f543a3e/contribute-select-after.png)
## Textareas instead of text input in "Word Replacements" form
This one I'm not really sure is really a markup error, but it looks to me that instead of `<textarea>` elements, the form would benefit by using `input[type="text"]` fields instead (see how the checkboxes get a vertical alignment, for example)
*Before*
![replacement-before](/uploads/47d5a07307d2bb2d2a19850626ad8ee3/replacement-before.png)
*After*
![replacement-after](/uploads/362b5b8591a1171121562e31ca46dded/replacement-after.png)5.9https://lab.civicrm.org/dev/core/-/issues/427Let CiviCRM accept unix domain sockets for the database URL.2022-09-03T05:03:50ZatheiaLet CiviCRM accept unix domain sockets for the database URL.Currently the database address input of the onboarding page expects an address of the format of $host:$port number.
The issue is that some databases may be set up instead to communicate through a unix domain socket.
A solution would be...Currently the database address input of the onboarding page expects an address of the format of $host:$port number.
The issue is that some databases may be set up instead to communicate through a unix domain socket.
A solution would be to allow for additional address parsing that would recognise the use of a socket instead of a port number.
This address format is supported by mysqli_connect already, so we just need to adapt our handling of the input field. The solution would allow the user to specify the address something like unix:///var/run/mysql-socket.
Best wishes,
Alexhttps://lab.civicrm.org/dev/core/-/issues/425"Force Secure URLs" setting sometimes does not behave as expected, deprecate ...2022-08-30T05:03:32Zxurizaemon"Force Secure URLs" setting sometimes does not behave as expected, deprecate it ... Slowly :)Various issues have reported over time that the SSL enforcement doesn't work as expected.
* [CRM_Core_Invoke::runItem()](https://github.com/civicrm/civicrm-core/blob/ae3dbe533c627d8882a59f15502ebeb1a60376f8/CRM/Core/Invoke.php#L188) cal...Various issues have reported over time that the SSL enforcement doesn't work as expected.
* [CRM_Core_Invoke::runItem()](https://github.com/civicrm/civicrm-core/blob/ae3dbe533c627d8882a59f15502ebeb1a60376f8/CRM/Core/Invoke.php#L188) calls CRM_Utils_System::redirectToSSL()
* [CRM_Utils_System::redirectToSSL()](https://github.com/civicrm/civicrm-core/blob/7a47ff14f4553230ff12ae19337ba750a421a898/CRM/Utils/System.php#L1177) uses [CRM_Utils_System::isSSL()](https://github.com/civicrm/civicrm-core/blob/7a47ff14f4553230ff12ae19337ba750a421a898/CRM/Utils/System.php#L1164)
* The setting is named "enableSSL" but it kind of works like "enforce SSL" (you can enable SSL and have it set to false, and if it's true then it will try to *enforce* SSL)
For some hosting environments, this (in particular the method of detecting whether a request is SSL or not) leads to confusing behaviour where a site will reject attempts to visit particular pages (`civicrm/admin/*` but not `civicrm/*`?), and show "access denied" in Drupal logs, and serve circular 302 redirects.
What we have apparently may not work if you are behind an SSL terminator, and probably for other setups which aren't accounted for.
Previous issues / PRs / work on that setting:
* [GH#9452](https://github.com/civicrm/civicrm-core/pull/9452) (see here for me going :shrug: :angry: about how we verify SSL)
* [CRM-11160](https://issues.civicrm.org/jira/browse/CRM-11160), [GH#1098](https://github.com/civicrm/civicrm-core/pull/1098)
* [CRM-16639](https://issues.civicrm.org/jira/browse/CRM-16639)
* [CRM-20448](https://issues.civicrm.org/jira/browse/CRM-20448)
* [CRM-19609](https://issues.civicrm.org/jira/browse/CRM-19609)
My opinion is that it's tricky to work out in CiviCRM whether the request is being served via SSL or not and that this is best resolved at the most user-facing layer - it can be tricky to resolve in Drupal too if you're behind haproxy+varnish etc, and for @alexymik it seemed to be raising issues under Docker ([1](https://chat.civicrm.org/civicrm/pl/sbadqkybzjgh9biadb46776fbe), [2](https://chat.civicrm.org/civicrm/pl/8izphwoi9ifa7gs7br5y4k1tyo)).
### How @xurizaemon thinks you should ensure CiviCRM is SSL'd
* Enforce SSL at the client-facing proxy, if you have one. Terminating SSL here is fine.
* If clients talk directly to nginx / apache / what have you, try to enforce SSL here as part of canonical URL config.
* .htaccess is next best after webserver config if you're using a server that supports it. Fine for small sites.
* If you can't do that, enforce SSL in the CMS using a module like Drupal's Securepages.
* Last resort should be CiviCRM, but we should really encourage people to do any of the above (in that order).
* Since you aren't any more relying on CiviCRM to enforce SSL, you can now set "enableSSL" to NO as it's a poorly named setting which may have unfortunate side-effects. Visit CiviCRM > Settings > Resource URLs and set " Force Secure URLs (SSL)" to "No".
So - I get that people are using this setting, I don't want to break things for them (that'll reduce security), but I did want to write up my reasoning behind why we should not encourage relying on that setting.
I propose we start defaulting it to off and aim to hide / deprecate / remove the config over time.
As a first step, I'm going to PR a log message that would have saved @alexymik a few hours of painful debugging today :grin:5.7https://lab.civicrm.org/dev/core/-/issues/354Price Field Options garbled upon edit with German money format2021-06-06T21:22:06ZBjörn EndresPrice Field Options garbled upon edit with German money formatIf you set (civicrm/admin/setting/localization) the thousands separator to '.' and the decimal to ',' as it's commonly used in Germany, editing price sets goes horribly wrong: If you have a price field with options, and you want to edit ...If you set (civicrm/admin/setting/localization) the thousands separator to '.' and the decimal to ',' as it's commonly used in Germany, editing price sets goes horribly wrong: If you have a price field with options, and you want to edit the options, the amount, let's say ``169.00``, is given as ``169.000000000``. If you save the form without changing the value, this gets interpreted as ["1.000.000.000,00"](http://weknowmemes.com/generator/uploads/generated/g1392854909775055094.jpg), which then gets even worse when you edit the field again.
The whole issue seems to go back to an unfortunate combination of the ``CRM_Utils_Money::format()`` function with German localisation, and the underlying DB field ``civicrm_price_field_value.amount`` having type ``decimal(18,9)`` - yes, *nine* decimals.
Observed on CiviCRM ``5.3.2``.https://lab.civicrm.org/dev/core/-/issues/337QuickForm Error on Contact Search Form when using select custom field of type...2021-01-06T22:42:24ZPradeep Nayakpradpnayak@gmail.comQuickForm Error on Contact Search Form when using select custom field of type IntegerTo Replicate:
Create a 'Select' custom field of type Integer or Number with 'Is this Field Searchable?' checked.
The Advance search form throws fatal error
```
Aug 17 10:16:57 [info] $Fatal Error Details = Array
(
[callback] => Ar...To Replicate:
Create a 'Select' custom field of type Integer or Number with 'Is this Field Searchable?' checked.
The Advance search form throws fatal error
```
Aug 17 10:16:57 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -3
[message] => QuickForm Error: nonexistent html element
[mode] => 16
[debug_info] => Element 'custom_8_from' does not exist in HTML_QuickForm::addRule()
[type] => HTML_QuickForm_Error
[user_info] => Element 'custom_8_from' does not exist in HTML_QuickForm::addRule()
[to_string] => [html_quickform_error: message="nonexistent html element" code=-3 mode=callback callback=CRM_Core_Error::handle prefix="QuickForm Error: " info="Element 'custom_8_from' does not exist in HTML_QuickForm::addRule()"]
)
Aug 17 10:16:57 [info] $backTrace = #0 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/Error.php(232): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 [internal function](): CRM_Core_Error::handle(Object(HTML_QuickForm_Error))
#2 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/PEAR.php(921): call_user_func((Array:2), Object(HTML_QuickForm_Error))
#3 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/HTML/QuickForm.php(2084): PEAR_Error->__construct("nonexistent html element", -3, 16, (Array:2), "Element 'custom_8_from' does not exist in HTML_QuickForm::addRule()")
#4 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/PEAR.php(575): HTML_QuickForm_Error->__construct(-3, 16, (Array:2), "Element 'custom_8_from' does not exist in HTML_QuickForm::addRule()")
#5 [internal function](): PEAR::_raiseError(NULL, NULL, -3, NULL, 512, "Element 'custom_8_from' does not exist in HTML_QuickForm::addRule()", "HTML_QuickForm_Error", TRUE)
#6 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/PEAR.php(237): call_user_func_array((Array:2), (Array:8))
#7 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/HTML/QuickForm.php(1076): PEAR::__callStatic("raiseError", (Array:7))
#8 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/HTML/QuickForm.php(1076): PEAR::raiseError(NULL, -3, NULL, 512, "Element 'custom_8_from' does not exist in HTML_QuickForm::addRule()", "HTML_QuickForm_Error", TRUE)
#9 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/BAO/CustomField.php(1103): HTML_QuickForm->addRule("custom_8_from", "number-select From must be a number (with or without decimal point).", "numeric")
#10 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Contact/Form/Search/Criteria.php(567): CRM_Core_BAO_CustomField::addQuickFormElement(Object(CRM_Contact_Form_Search_Advanced), "custom_8", "8", FALSE, TRUE)
#11 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Contact/Form/Search/Advanced.php(150): CRM_Contact_Form_Search_Criteria::custom(Object(CRM_Contact_Form_Search_Advanced))
#12 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/Form.php(606): CRM_Contact_Form_Search_Advanced->buildQuickForm()
#13 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Display.php(92): CRM_Core_Form->buildForm()
#14 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Contact_Form_Search_Advanced), "display")
#15 /var/www/html/civicrm-master/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Form_Search_Advanced), "display")
#16 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("display")
#17 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/Invoke.php(309): CRM_Core_Controller->run((Array:4), (Array:0))
#18 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/Invoke.php(84): CRM_Core_Invoke::runItem((Array:13))
#19 /var/www/html/civicrm-master/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:4))
#20 /var/www/html/civicrm-master/sites/all/modules/civicrm/drupal/civicrm.module(445): CRM_Core_Invoke::invoke((Array:4))
#21 [internal function](): civicrm_invoke("contact", "search", "advanced")
#22 /var/www/html/civicrm-master/includes/menu.inc(527): call_user_func_array("civicrm_invoke", (Array:3))
#23 /var/www/html/civicrm-master/index.php(21): menu_execute_active_handler()
#24 {main}
```
When i checked the field through database i found that this field has 'is_search_range' set to TRUE which should be only incase of text or date field i believe.5.9https://lab.civicrm.org/dev/core/-/issues/324System status page doesn't detect new version of CiviCRM, nor does it print a...2022-08-24T05:03:35ZsudomanSystem status page doesn't detect new version of CiviCRM, nor does it print an error.When I visit the system status page at `https://example.com/civicrm/a/#/status`, I am not notified of a new version of CiviCRM. This may be due to our outbound firewall, but we are also not notified of an error in trying to fetch the upd...When I visit the system status page at `https://example.com/civicrm/a/#/status`, I am not notified of a new version of CiviCRM. This may be due to our outbound firewall, but we are also not notified of an error in trying to fetch the update information.
We are using CiviCRM 5.3.1.https://lab.civicrm.org/dev/core/-/issues/323Delete contact image does not remove the file2023-03-18T01:48:44ZJKingsnorthDelete contact image does not remove the fileSummary:
Contact images are not deleted from the server when they are 'deleted' through the front end.
Steps to recreate:
* Edit a contact and upload a contact image, save
* Look in the site directory for contact images - the file is t...Summary:
Contact images are not deleted from the server when they are 'deleted' through the front end.
Steps to recreate:
* Edit a contact and upload a contact image, save
* Look in the site directory for contact images - the file is there
* Edit the contact and choose 'Delete contact image'
* Refresh the directory, the file is still there (and still accessible over the web - even to anonymous users)
Technical:
The function that deletes the contact image only removes the database reference: https://github.com/civicrm/civicrm-core/blob/7432a41c4cccb22ab035aea2c5ed4780617f3676/CRM/Contact/BAO/Contact.php#L1066-L1077
What should happen:
Recognisable portraits are special personal information according to GDPR legislation. Deleting a portrait, whether at a user's request or to remove it, or if it's done by a user through a profile, should also remove that file from the server.
How to make it happen:
Make the deleteContactImage function also remove the file from the server.
How to make it happen retrospectively:
It would be feasible to create an extension(?) that would scrape through the user image directory and delete all files that aren't referenced in in the image_url of the civicrm_contact table, or the civicrm_file table? This has previously been suggested in this StackExchange response: https://civicrm.stackexchange.com/a/24206/124https://lab.civicrm.org/dev/core/-/issues/318opting out of bulk emails also opts you out of SMS messages2022-08-23T05:03:34Zjamieopting out of bulk emails also opts you out of SMS messagesNow, if you opt out of bulk email messages, you won't receive any SMS messages either.
The field name is is_opt_out (which seems pretty general) but the user interface clearly says: "NO BULK EMAILS (User Opt Out)" And the description re...Now, if you opt out of bulk email messages, you won't receive any SMS messages either.
The field name is is_opt_out (which seems pretty general) but the user interface clearly says: "NO BULK EMAILS (User Opt Out)" And the description re-enforces the notion that this is a user-set variable for not receiving email messages.
Most people use mass email and SMS in very different ways, especially given the limitations on the number of SMS messages can be sent (which makes them more targeted).
As a result, it's reasonable for someone to opt out of bulk email but expect to get SMS messages.
My preference would be to eliminate this check so that SMS messages ignore this field. My second choice would be to change the language in the UI.
Thoughts?https://lab.civicrm.org/dev/core/-/issues/310Incorrect allocation of payment on an edited multi-line item event registration2018-10-23T15:30:07ZJoeMurrayIncorrect allocation of payment on an edited multi-line item event registrationOn default data set on dmaster, create new Financial Type Event Fees 2. At Administer > Financial Accounts, navigate to the Financial Account this creates also called Event Fees 2 and enter 4301 as the Accounting Code.
1. Create event ...On default data set on dmaster, create new Financial Type Event Fees 2. At Administer > Financial Accounts, navigate to the Financial Account this creates also called Event Fees 2 and enter 4301 as the Accounting Code.
1. Create event with priceset with two fields, first with financial Type Event fees, second with FT of Event Fees 2.
2. Register in event with payment of say $25 for first ticket (Event Fees) and $10 for second ticket (Event fees 2), total $35.
3. Edit Event registration. Click Change selections. Change quantity for second field from 1 to 5, line item total of $50, contribution total of $75, total paid $35. Save. Balance is $40.
4. Click Record Payment.
To review the database records that would be sent to accounting applications, you can:
5. Navigation to Contributions > Accounting Batches > New Batch, create a batch, assign the relevant transactions of $35 (original payment), $40 (edit with implied purchase with pay later) and $40 (payment of outstanding balance) to the new batch and export to csv.
6. At Contributions > Accounting Batches > Open Batches, select the batch just created and export as csv, open and view the resulting transactions:
[Financial_Transactions_3_20180807210702.csv](/uploads/cd4c2989ca42cff4e7f6bba22b8ddfa1/Financial_Transactions_3_20180807210702.csv)
The initial purchase (first two lines) and the edit of the order to increase the number of event fees from $10 to $50 are (the third line) are all correct. However, the payment of the outstanding balance is incorrect. Instead of a single line with a $40 payment (Debit Bank Account 1150, Credit Accounts Receivable 1200), there are two lines:
Debit Bank Account 1150, Credit Accounts Receivable 1200: $16.67, Item description: Member
Debit Bank Account 1150, Credit Accounts Receivable 1200: $23.33, Item description: Guest
It seems the payment is being equally allocated to the two line items in proportion to their current line item total. If there had been a simple partial payment, this would be correct. The algorithm for determining the allocation should not be based on the line item totals (or more accurately, their corresponding financial_item.amount), but on the amount of each financial item that has been paid so far (entity_financial_trxn.amount for the entries linking financial_trxn records to these financial_item records.
We should first verify that the entity_financial_trxn.amount fields are being properly recorded. Then it will be apparent that sum(entity_financial_trxn.amount) pointing to first financial_item is $25, the same as its financial_item.amount, while sum(entity_financial_trxn.amount) pointing to second financial_item is $10, which is $40 less than the financial_item.amount. So all of the second payment would be allocated to a single new entity_financial_trxn.amount of $40 pointing to the second financial_item.
This is not a high priority since the two entries add up to the same as the proposed single entry from an accounting perspective. Having two general journal entries is confusing, and the item description of one is inaccurate, so a fix would be good.Monish DebMonish Deb