CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-23T17:54:21Zhttps://lab.civicrm.org/dev/core/-/issues/11Email - send now error screen should display earlier2023-06-23T17:54:21ZJchesterEmail - send now error screen should display earlierIn Advanced Search if you are displaying results as contacts and then:
* select more than 50 of the results
* select **Email - send now (to 50 or less)**
you see the Error message telling you that you can't email more than 50 contac...In Advanced Search if you are displaying results as contacts and then:
* select more than 50 of the results
* select **Email - send now (to 50 or less)**
you see the Error message telling you that you can't email more than 50 contacts this way and the process stops
However, if you display the results as contributions or as memberships then
* select more than 50 of the results
* select **Email - send now (to 50 or less)**
you are taken to the email set up page. It is not until you click on Send Email on that page that you see the Error message telling you that you can't email more than 50 contacts this way and the process is stopped.
It would be a better user experience if the error message always appeared when **Email - send now (to 50 or less)** was selected.5.9https://lab.civicrm.org/dev/core/-/issues/3522Soften messages for read-only extensionsDir2022-06-11T14:41:07ZtiotsopSoften messages for read-only extensionsDirImprove messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only on...Improve messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only one message ("Read-Only Extensions"). It still encourages web-writable policy, but it lowers the severity and presents it a choice ("if you want X, do Y").
Probably, changing the `warning` into a `notice` is the only thing to update:- a `warning` implies something is wrong, while a `notice` says it's merely out of the ordinary.5.9tiotsoptiotsophttps://lab.civicrm.org/dev/core/-/issues/3544Bounce processing doesn't catch pattern "user doesn't exist"2022-06-11T14:50:31ZDetlev SieberBounce processing doesn't catch pattern "user doesn't exist"CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
...CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
Some email providers throw the bounce pattern "user doesn't exist", which is not found, and therefore results in bounce_type "syntax". However, this bounce pattern should result in immediately switching the email address to "inactive".
Solution is:
> insert into civicrm_mailing_bounce_pattern (bounce_type_id, pattern) values (6, 'user doesn\'t exist');
5.9Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3610Jira Issue CRM-21666 still exists in 5.8.12022-06-11T14:56:07ZjeffmikelsJira Issue CRM-21666 still exists in 5.8.1https://issues.civicrm.org/jira/browse/CRM-21666
CRM/Mailing/DAO/Mailing.php
and
CRM/Mailing/BAO/Mailing.php
still have a discrepancy regarding the naming of the mailing_date field
messageNotice: Undefined property: CRM_Mailing_BAO...https://issues.civicrm.org/jira/browse/CRM-21666
CRM/Mailing/DAO/Mailing.php
and
CRM/Mailing/BAO/Mailing.php
still have a discrepancy regarding the naming of the mailing_date field
messageNotice: Undefined property: CRM_Mailing_BAO_Mailing::$mailing_modified_date in CRM_Mailing_BAO_Mailing::report()5.9https://lab.civicrm.org/dev/core/-/issues/125Invalid link to custom-fields documentation2018-12-15T22:50:50ZedgimarInvalid link to custom-fields documentationOn the `index.php?q=civicrm/admin/custom/group&reset=1` screen, the "learn more..." link appears to be broken -- this target of this link is currently https://docs.civicrm.org/user/en/latest/organising-your-data/custom-fields but should ...On the `index.php?q=civicrm/admin/custom/group&reset=1` screen, the "learn more..." link appears to be broken -- this target of this link is currently https://docs.civicrm.org/user/en/latest/organising-your-data/custom-fields but should instead be https://docs.civicrm.org/user/en/latest/organising-your-data/creating-custom-fields/.
Using CiviCRM 5.1.1.5.9https://lab.civicrm.org/dev/core/-/issues/153Pending Pay Later /w Custom payment method2020-11-19T07:07:10ZADG CreativePending Pay Later /w Custom payment methodCiviCRM 5.1.2
Joomla 3.8.7
(Replicated on civicrm.demo.civihosting.com - CiviCRM 5.0.0 - Drupal)
Create a custom Payment Method (ie. Undetermined), with Financial Account = Accounts Receivable
On the administrative side, register contac...CiviCRM 5.1.2
Joomla 3.8.7
(Replicated on civicrm.demo.civihosting.com - CiviCRM 5.0.0 - Drupal)
Create a custom Payment Method (ie. Undetermined), with Financial Account = Accounts Receivable
On the administrative side, register contact for an event with Payment Method=Undetermined, Payment Status=Pending
Go to the Contribution tab, the contribution is Pending Pay Later
Do Record Payment, Payment Method=Check, Add Check #, Payment Status=Complete, (Full Amount Paid)
The Contribution will be marked with a Payment Status of Partially Paid
Admin can edit the contribution and mark it as Payment Status = Complete, but...
Expand the payment information, Record Payment links are still visible, but will throw an error if clicked
civicrm_contribution.payment_instrument_id = Undetermined (Although payment method was set to Check)
civicrm_financial_trxn.from_financial_account_id = Accounts Receivable
civicrm_financial_trxn.to_financial_account_id = Accounts Receivable
Contribution not listed in Bookkeeping Report
Also cannot find contribution by Check# in Contributions->Find Contributions (Not sure if related or separate issue)
![CompletedMarkedasPartiallyPaid](/uploads/26c971d0956ac4c6abd40cb6933fd917/CompletedMarkedasPartiallyPaid.jpg)5.9https://lab.civicrm.org/dev/core/-/issues/174Consistently use swappable cache interfaces2023-12-20T06:26:25ZtottenConsistently use swappable cache interfaces# Background
CiviCRM caches were originally (and are primarily) stored in the table `civicrm_cache`. This design is great for small sites (easy to deploy on server with less software to administer). However, for larger sites that get va...# Background
CiviCRM caches were originally (and are primarily) stored in the table `civicrm_cache`. This design is great for small sites (easy to deploy on server with less software to administer). However, for larger sites that get value from using multiple MySQL servers, it's not so great: cache data (by its nature) is frequently written+read, but it's expensive to write cache data when there are multiple MySQL servers... and the overhead doesn't give us much benefit because the data is fundamentally expendable. A lighter system (like Memcache/Redis) would be more generally appropriate.
You might recall that CiviCRM's cache subsystem can optionally incorporate Memcache/Redis (since roughly 4.3ish?). This appears as `CRM_Utils_Cache_*`, and it started some great improvements (e.g. using faster cache providers; and swapping cache providers). Notably, the functionality uses Memcache/Redis as an *extra cache tier* (i.e. when reading a cache, it first checks memcache; then it falls back to checking `civicrm_cache` in MySQL). This helps *read performance* (because your cache-hit usually returns faster), but it doesn't help *write performance* (because you need to propagate cache-writes to every tier). Using *only* Memcache/Redis (as a single tier -- without MySQL) would be even better for performance.
I don't believe that the status quo reflects a technical necessity. (If you can handle deployment/configuration of Memcache/Redis a front-tier... then you can probably handle it as the main tier.) Rather, it reflects a development practicality: *the app was originally written to only use `civicrm_cache`*. Consequently, there are a handful of oddball use-cases/code-paths which directly access `civicrm_cache` or `CRM_Core_BAO_Cache`, and it would've been harder to do anything if it had required finding+fixing all of them.
# Scope
The general scope of this ticket is to hunt down the oddball use-cases/code-paths which directly reference `civicrm_cache` or `CRM_Core_BAO_Cache`. I expect the project to produce a handful of distinct PRs. To avoid redundantly documenting this, I'm aiming for each PR to have a more concrete discussion about the use-cases/code-paths being cleaned up.
# PR List
* [12330 - CRM_Utils_Cache_Redis::flush() - Respect prefixes](https://github.com/civicrm/civicrm-core/pull/12330) (m)
* [12331 - CRM_Utils_Cache - Always use a prefix. Standardize delimiter](https://github.com/civicrm/civicrm-core/pull/12331) (m)
* [12336 - systemStatusCheckResult - Migrate from settings to cache](https://github.com/civicrm/civicrm-core/pull/12336) (m)
* [12342 - Caching - Comply with PSR-16 interfaces](https://github.com/civicrm/civicrm-core/pull/12342) (m)
* [215 - Import PSR-16 compliance test](https://github.com/civicrm/civicrm-packages/pull/215) (m)
* [12348 - Cache-keys for CRM_Utils_Cache_* should avoid reserved chars](https://github.com/civicrm/civicrm-core/pull/12348) (m)
* ~~[12350 - civicrm_cache - Allow storage of binary data](https://github.com/civicrm/civicrm-core/pull/12350)~~
* [12354 - civicrm_cache - Allow storage of binary data](https://github.com/civicrm/civicrm-core/pull/12354) (m)
* [~~12360~~ - Full PSR-16 compliance for ...](https://github.com/civicrm/civicrm-core/pull/12360) (*depends: ~~12342, 12348, 12354~~*). Cherry-picked to form smaller PRs:
* [12376 - Add various utilities to support PSR-16](https://github.com/civicrm/civicrm-core/pull/12376) (m)
* [12378 - ArrayCache, Redis](https://github.com/civicrm/civicrm-core/pull/12378) (m)
* [12379 - SqlGroup](https://github.com/civicrm/civicrm-core/pull/12379) (m)
* [12380 - Memcache(d)](https://github.com/civicrm/civicrm-core/pull/12380) (m)
* [12381 - APCcache](https://github.com/civicrm/civicrm-core/pull/12381) (m)
* [12389 - Add test to prevent hidden interactions among caches](https://github.com/civicrm/civicrm-core/pull/12389) (m)
* [12362 - Forms/Sessions - Store state via Civi::cache('session')](https://github.com/civicrm/civicrm-core/pull/12362) (*depends: 12360*)
* [12368 - ~~civicrm_cache - Finish transition from DATETIME to TIMESTAMP](https://github.com/civicrm/civicrm-core/pull/12368)~~ (m)
See also
--------
* dev/core#217 - Allow replacement of PrevNextCache implementation (for search screens)
* dev/core#284 - Aggressive cache clearing significantly increases test time5.9tottentottenhttps://lab.civicrm.org/dev/core/-/issues/217Allow replacement of PrevNextCache implementation (for search screens)2019-01-10T10:07:11ZtottenAllow replacement of PrevNextCache implementation (for search screens)This is a major sub-task of dev/core#174 (*Consistently use swappable cache interfaces*).
# Background
The PrevNextCache is used to temporarily save the results of a query. It is specifically used in the following scenarios:
* Contact...This is a major sub-task of dev/core#174 (*Consistently use swappable cache interfaces*).
# Background
The PrevNextCache is used to temporarily save the results of a query. It is specifically used in the following scenarios:
* Contact searches (Related -- other derived searches and the "View Contact" result screen)
* Dedupe/merge
For this issue, our aim is specifically to allow the contact-searches to retain their results via Redis/Memcache (instead of MySQL).
# Touch Points
We want to make it possible to swap the prev-next implementation, but the functionality of `CRM_Core_BAO_PrevNextCache` is a bit more sophisticated than `CRM_Utils_Cache_Interface`. So, first, we need to understand the places which touch the prev-next cache (*before patching*).
__Q1: Where does it `INSERT` into `civicrm_prevnext_cache`?__
* `CRM_Contact_Selector::fillupPrevNextCache`
* `CRM_Campaign_Selector_Search::buildPrevNextCache`
__Q2: Where does it `SELECT` from `civicrm_prevnext_cache`?__
* `CRM_Contact_BAO_Query::getCachedContacts`
__Q3: What are all the functions supported by the BAO? When are they relevant__
* (Group A) Relevant to contact searches (and maybe also dedupe/merge)
* `public static function markSelection($cacheKey, $action = 'unselect', $cIds = NULL, $entity_table = 'civicrm_contact') {`
* `public static function getSelection($cacheKey, $action = 'get', $entity_table = 'civicrm_contact') {`
* `public static function getPositions($cacheKey, $id1, $id2, &$mergeId = NULL, $join = NULL, $where = NULL, $flip = FALSE) {`
* `public static function deleteItem($id = NULL, $cacheKey = NULL, $entityTable = 'civicrm_contact') {`
* `public static function getSelectedContacts() {`
* `public static function getCount($cacheKey, $join = NULL, $where = NULL, $op = "=", `$params = array()) {
* (Group B) Only relevant to dedupe/merge
* `public static function flipPair(array $prevNextId, $onlySelected) {`
* `public static function deletePair($id1, $id2, $cacheKey = NULL, $isViceVersa = FALSE, $entityTable = 'civicrm_contact') {`
* `public static function markConflict($id1, $id2, $cacheKey, $conflicts) {`
* `public static function setItem($values) {`
* `public static function refillCache($rgid, $gid, $cacheKeyString, $criteria, $checkPermissions, $searchLimit = 0) {`
* `public static function retrieve($cacheKey, $join = NULL, $whereClause = NULL, $offset = 0, $rowCount = 0, $select = array(),...)`
* (Group C) Special, internal, or unused
* `public static function cleanupCache() {`
* `public static function is_serialized($string) {`
* `public static function buildSelectedContactPager(&$form, &$params) {`
# General Approach
* Define a service `Civi::service('prevnext')` which satisfies an interface `CRM_Core_PrevNextCache_Interface`.
* Create two implementations of the service:
* `CRM_Core_PrevNextCache_Sql` (which is pretty thin -- it generally delegates to the existing BAO code)
* ~~`CRM_Core_PrevNextCache_Memory` (which uses a memory-backed cache)~~
* `CRM_Core_PrevNextCache_Redis` (which uses Redis for a memory-backed cache)
* The scope of the interface would include:
* Functionality needed by the inserters (`CRM_Contact_Selector::fillupPrevNextCache` and `CRM_Campaign_Selector_Search::buildPrevNextCache`)
* Functionality needed by the reader (`CRM_Contact_BAO_Query::getCachedContacts`)
* Functionality from the BAO that's relevant to contact-searches (eg `markSelection` but not `deletePair`)
* In the contact-search use-cases, change to use the service instead of the BAO.
* Ex: `CRM_Core_BAO_PrevNextCache::markSelection(...)` => `Civi::service('prevnext')->markSelection(...)`
*Note*: I initially considered a different relationship (where `CRM_Core_BAO_PrevNextCache` remains the canonical/front-facing interface and `CRM_Core_PrevNextCache_Interface` remains hidden behind the BAO). However, given that dedupe/merge needs to continue using the existing SQL implementation, it felt like that would get messier; it seemed cleaner to split them apart more clearly ("use-case (1) always invokes code (A), and use-case (2) always invokes code (B)" -- i.e. "all contact-search code invokes `Civi::service('prevnext')`, and all dedupe code invokes PrevNext BAO").
![Screen_Shot_2018-06-28_at_6.55.29_PM](/uploads/7fc6852ecefe6e5638e0b3a21fb37e44/Screen_Shot_2018-06-28_at_6.55.29_PM.png)
# PR List
* [12377 - General/overall patchset](https://github.com/civicrm/civicrm-core/pull/12377)
* [12438 - CRM_Contact_Selector::getRows() - Use generator instead of DAO loop](https://github.com/civicrm/civicrm-core/pull/12438)
* [12528 - Add skeletal PrevNextCache service ](https://github.com/civicrm/civicrm-core/pull/12528)
* [12543 - PrevNext - Probe for best available implementation (memory-backed or SQL-backed)](https://github.com/civicrm/civicrm-core/pull/12543)
* [12544 - CRM_Utils_Cache_Redis::connect() - Allow pooling connections](https://github.com/civicrm/civicrm-core/pull/12544)
* [12545 - PrevNext - Define and use fillWithSql()/fillWithArray()](https://github.com/civicrm/civicrm-core/pull/12545)
* [12556 - Migrate selection methods](https://github.com/civicrm/civicrm-core/pull/12556)
* [12558 - Allow swapping getPositions (etal) for contact-search](https://github.com/civicrm/civicrm-core/pull/12558)
* [12663 - Use more consistent cache-keys while adjusting filters](https://github.com/civicrm/civicrm-core/pull/12663)
* [12664 - Remove references to entity_table and entity_id2 from service. Add test.](https://github.com/civicrm/civicrm-core/pull/12664)
* [12665 - Implement Redis. Decouple Query::getCachedContacts()](https://github.com/civicrm/civicrm-core/pull/12665)
# Test Scenarios
The prev-next cache has evolved a number of conditionals to handle edge-cases in which it's used. We should be testing these in a targeted/incremental way during development. Once we have a fairly complete PR, we should do a final/comprehensive pass through these use-cases.
* __Quick Search Box / Advanced Search / Search Builder__: This is the main section of the code that we're targetting for revision.
* Execute a search with multiple pages of results
* Execute a search with one page of results
* Drill-down and view a contact in the search results. Navigate using "Previous" button, "Next" button, and the breadcrumb "Search Results"
* [CRM-9096](https://issues.civicrm.org/jira/browse/CRM-9096) Create a profile. Mark some fields as visible/enabled for listings. Run an "Advanced Search" and use this profile. Re-sort results.
* Select a handful of contacts on different pages. Execute a task (e.g. "Export") and ensure that it has the appropriate contacts.
* Select all contacts. Execute a task (e.g. "Export") and ensure that it has the appropriate contacts.
* __Custom Search__: Most of the code is shared with above, but a few lines are different.
* Run a few custom searches. Use various sort/filter options.
* __CiviCampaign__: This component has logic to fill the cache directly -- which doesn't use the same code-paths.
* Create a survey. Reserve respondents. Interview. Release. (When browsing respondents, try to sort.)
* __CiviRules__: This component uses some of the code from contact-search, and there's a comment about special case.
* Browse the list of available rules.
* __Dedupe/Merge__: In principle, this code isn't supposed to be touched/changed by our PR, and there is test coverage over this functionality. OTOH, if one made a mistake (inappropriately changing shared code), there could be a regression. So do a couple tests with this anyway.5.9tottentottenhttps://lab.civicrm.org/dev/core/-/issues/321Prevent duplicate entries in civicrm_entity_file2018-11-17T02:41:11ZMonish DebPrevent duplicate entries in civicrm_entity_fileSteps to replicate:
1. Enable CiviCase
2. Create a new Case.
3. Edit any Case Activity >> add an attachment >> Save
4. Reopen the Edit Activity form and simply save.
DB result: There will duplicate entries in civicrm_entity_fileSteps to replicate:
1. Enable CiviCase
2. Create a new Case.
3. Edit any Case Activity >> add an attachment >> Save
4. Reopen the Edit Activity form and simply save.
DB result: There will duplicate entries in civicrm_entity_file5.9Monish DebMonish Debhttps://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/3725.6.alpha1 notice2018-11-11T20:41:11ZJoeMurray5.6.alpha1 noticeCreate simple Meeting activity with minimal options. View activity:
Notice: Undefined index: details in CRM_Activity_Form_Activity->preProcess() (line 526 of /home/git-civicrm/civicrm-core/CRM/Activity/Form/Activity.php).
http://cividemo...Create simple Meeting activity with minimal options. View activity:
Notice: Undefined index: details in CRM_Activity_Form_Activity->preProcess() (line 526 of /home/git-civicrm/civicrm-core/CRM/Activity/Form/Activity.php).
http://cividemo.jmaconsulting.biz/civicrm/activity/add?reset=1&atype=1&action=update&reset=1&id=720&cid=203&context=activity5.9Monish DebMonish Debhttps://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/467Case Start Date and End Date don't work properly in Batch Update2018-11-15T11:18:29ZRayWrightCase Start Date and End Date don't work properly in Batch UpdateWhen trying to batch update a case start date or end date you get the following error: Notice: Undefined index: formatType in CRM_Utils_Date::addDateMetadataToField() (line 1878 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/C...When trying to batch update a case start date or end date you get the following error: Notice: Undefined index: formatType in CRM_Utils_Date::addDateMetadataToField() (line 1878 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Utils/Date.php).
This results in
Start Date: the current date being filled into all values
End Date: if it's not already filled in, you can only select today's date.5.9https://lab.civicrm.org/dev/core/-/issues/498Undefined index in mailing report for mailing_modified_date; and room for ref...2018-12-14T23:17:06ZJKingsnorthUndefined index in mailing report for mailing_modified_date; and room for refactoringNotice: Undefined property: CRM_Mailing_BAO_Mailing::$mailing_modified_date in CRM_Mailing_BAO_Mailing::report() (line 1821 of /home/developer/buildkit/build/civicrmdev/sites/all/modules/civicrm/CRM/Mailing/BAO/Mailing.php).
Appears on ...Notice: Undefined property: CRM_Mailing_BAO_Mailing::$mailing_modified_date in CRM_Mailing_BAO_Mailing::report() (line 1821 of /home/developer/buildkit/build/civicrmdev/sites/all/modules/civicrm/CRM/Mailing/BAO/Mailing.php).
Appears on pages like: /civicrm/mailing/report?mid=7&reset=1
This is because the DAO key for the field is 'mailing_modified_date' - but the name is 'modified_date'.
And the way the field values are assigned to the object does not account for this difference.
This is a very minor issue as the modified date doesn't actually get used in the report!
We should probably refactor the query/code to only load the fields we're actually interested in; and get rid of the raw SQL in the file at the same time: https://github.com/civicrm/civicrm-core/blob/f87c35c7308fc6876e1a4fea8ac3ea908d3d9453/CRM/Mailing/BAO/Mailing.php#L18075.9https://lab.civicrm.org/dev/core/-/issues/503Editing Rich Text custom field on relationship non-functional2018-11-13T03:11:11ZmclarkeEditing Rich Text custom field on relationship non-functional## Summary
Editing a Note/RichTextEditor custom field on a relationship causes the HTML tags to be encoded into the content. Each time you edit the field the tags get literally added to the content, piling up.
## Steps to Reproduce
- ad...## Summary
Editing a Note/RichTextEditor custom field on a relationship causes the HTML tags to be encoded into the content. Each time you edit the field the tags get literally added to the content, piling up.
## Steps to Reproduce
- add a custom field set on relationships
- add a custom field to the set of type Note->Rich Text Editor
- add a relevant relationship to a contact, put in any content to the rich field, save
- re-edit the relationship
- note that the paragraph tags are rendered into the rich editor as literals
- rinse, repeat to see the tags continue to pile up
[Screenshot_2018-11-02_14.15.10](/uploads/1e3e5bc6158cf32813ce73dade0b25a8/Screenshot_2018-11-02_14.15.10.png)5.9https://lab.civicrm.org/dev/core/-/issues/505Allow for Extensions to set the CRM Type and PHP Type when dealing with unusu...2018-11-29T10:05:35ZseamusleeAllow for Extensions to set the CRM Type and PHP Type when dealing with unusual MySQL TypesAt present the type specified in the DAO when your dealing with an unusual MySQL type is set by whatever is the column type however there may not be that CRM_Utils_Type:: defined var for it so sometimes an extension may want to set it so...At present the type specified in the DAO when your dealing with an unusual MySQL type is set by whatever is the column type however there may not be that CRM_Utils_Type:: defined var for it so sometimes an extension may want to set it so that the DAO can operate sensibly5.9https://lab.civicrm.org/dev/core/-/issues/511Membership Dashboard shows incorrect month2018-11-09T22:11:45Zaydunsaidan.saunders@squiffle.ukMembership Dashboard shows incorrect month![Screenshot_from_2018-11-08_11-56-38](/uploads/1778dee40d7c1e2aa1ecfdb9c80a362a/Screenshot_from_2018-11-08_11-56-38.png)
Last month = October - correct
This month = April - incorrect. Should be November
This problem was introduced i...![Screenshot_from_2018-11-08_11-56-38](/uploads/1778dee40d7c1e2aa1ecfdb9c80a362a/Screenshot_from_2018-11-08_11-56-38.png)
Last month = October - correct
This month = April - incorrect. Should be November
This problem was introduced in 4.7.23-rc5.9aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.ukhttps://lab.civicrm.org/dev/core/-/issues/513Contribution Transact API - Use the payment processor payment method instead ...2018-11-11T00:10:14Zomar_compucorpContribution Transact API - Use the payment processor payment method instead of the payment_type field## Problem
When using the Contribution.Transact API, CiviCRM will either change the payment instrument to "Credit Card" or "Debit Card" based on the the value of payment_type field.
## How should it work
This is wrong and the payment...## Problem
When using the Contribution.Transact API, CiviCRM will either change the payment instrument to "Credit Card" or "Debit Card" based on the the value of payment_type field.
## How should it work
This is wrong and the payment instrument type should be taken form the used payment processor payment_instrument_id field.5.9https://lab.civicrm.org/dev/core/-/issues/518Lybunt performance improvement2019-02-19T04:55:07ZeileenLybunt performance improvementA couple of years back I did some work on the performance of the Lybunt report https://issues.civicrm.org/jira/browse/CRM-17837 which succeeded in improving the query enough that it would run for prior years there is still an exponential...A couple of years back I did some work on the performance of the Lybunt report https://issues.civicrm.org/jira/browse/CRM-17837 which succeeded in improving the query enough that it would run for prior years there is still an exponential inefficiency in the query which means that 2 years later & some large number of donations later we are back to it not running.
The current query is
```
CREATE TEMPORARY TABLE civicrm_tmp_e_rptlybunt_20181114_5beb5dc8d8e46 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci
SELECT SQL_CALC_FOUND_ROWS contact_civireport.id as cid FROM civicrm_tmp_e_rptgrp_20181114_5beb5dc8d1b4b group_temp_table INNER JOIN civicrm_contact contact_civireport
ON group_temp_table.id = contact_civireport.id INNER JOIN civicrm_contribution contribution_civireport ON contribution_civireport.contact_id = contact_civireport.id
AND contribution_civireport.is_test = 0
AND contribution_civireport.receive_date BETWEEN '20170101000000' AND '20171231235959'
LEFT JOIN civicrm_contribution cont_exclude ON cont_exclude.contact_id = contact_civireport.id
AND cont_exclude.receive_date BETWEEN '2018-01-01' AND '20181231235959' WHERE cont_exclude.id IS NULL AND 1 AND 1
GROUP BY contact_civireport.id;
```
and it takes 394 seconds
to return only a few hundred rows (the group has only 730 contacts).
Playing around I was able to reduce this time to .24 second by re-writing the query as
```
SELECT SQL_CALC_FOUND_ROWS contact_civireport.id as cid
FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table INNER JOIN civicrm_contact contact_civireport
ON group_temp_table.id = contact_civireport.id
WHERE group_temp_table.id IN
(
SELECT group_temp_table.id FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table
INNER JOIN civicrm_contribution contribution_civireport ON contribution_civireport.contact_id = group_temp_table.id
AND contribution_civireport.is_test = 0
AND contribution_civireport.receive_date BETWEEN '20170101000000' AND '20171231235959'
)
AND group_temp_table.id IN
(
SELECT group_temp_table.id FROM civicrm_tmp_d_dflt_3b5e17ad9138b8cc56282f75b2967e9e group_temp_table LEFT JOIN
civicrm_contribution cont_exclude ON cont_exclude.contact_id = group_temp_table.id
AND cont_exclude.receive_date BETWEEN '2018-01-01' AND '20181231235959'
WHERE cont_exclude.id IS NULL
)
GROUP BY contact_civireport.id;
```
I experimented on our staging site on running the query on our WHOLE data base (ie. without the group constraint) and it completed in 720 seconds - which is outrageously good really since that legitimately queries a LOT of records.
I'm going to look at how to fix up the LYBUNT report to use the above query. There are already some tests from last time I worked on performance on this report.5.9https://lab.civicrm.org/dev/core/-/issues/525Extraneous br-tags in rendered note-fields2018-11-16T00:44:05Zthomas_SYSTOPIAExtraneous br-tags in rendered note-fieldsHow to reproduce on a fresh 5.7er CiviCRM:
* Create a contact-inline-custom-group and a note-field with a TextArea- or a RichTextEditor-FieldType.
* Save this field with a multiline text on an arbitrary Contact.
You may see all linebrea...How to reproduce on a fresh 5.7er CiviCRM:
* Create a contact-inline-custom-group and a note-field with a TextArea- or a RichTextEditor-FieldType.
* Save this field with a multiline text on an arbitrary Contact.
You may see all linebreaks displayed doubly.5.9https://lab.civicrm.org/dev/core/-/issues/526Feedback cannot be translated when saving Contribution Page forms in language...2018-11-15T19:32:34ZhaystackFeedback cannot be translated when saving Contribution Page forms in languages other than EnglishWhen saving forms to configure a Contribution Page in languages other than English, the feedback given is not translated or translatable.
Example below (FWIW that's the CiviCRM Admin Utilities theme):
![Screen_Shot_2018-11-15_at_12.37....When saving forms to configure a Contribution Page in languages other than English, the feedback given is not translated or translatable.
Example below (FWIW that's the CiviCRM Admin Utilities theme):
![Screen_Shot_2018-11-15_at_12.37.55](/uploads/a7b2bf0762d271e82c595b4bdc490a16/Screen_Shot_2018-11-15_at_12.37.55.png)
This can be rectified by applying [the same logic as exists for Event Management forms](https://github.com/civicrm/civicrm-core/blob/master/CRM/Event/Form/ManageEvent.php#L376-L378).5.9https://lab.civicrm.org/dev/core/-/issues/528Advanced Search -> Contribution Tab and Contribution Dashboard returns a fata...2018-11-17T02:37:46ZjitendraAdvanced Search -> Contribution Tab and Contribution Dashboard returns a fatal error.On Dmaster
https://dmaster.demo.civicrm.org/civicrm/contact/search/advanced?reset=1 -> Expanding the contribution div section displays a network error
![image](/uploads/1fe2c8909315b51ebded571fcb0d023d/image.png)
Similarly, Contributi...On Dmaster
https://dmaster.demo.civicrm.org/civicrm/contact/search/advanced?reset=1 -> Expanding the contribution div section displays a network error
![image](/uploads/1fe2c8909315b51ebded571fcb0d023d/image.png)
Similarly, Contribution Dashboard returns a fatal error - https://dmaster.demo.civicrm.org/civicrm/contribute?reset=15.9jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/532Multi-select field not respected in batch search2018-12-10T17:15:43ZPradeep Nayakpradpnayak@gmail.comMulti-select field not respected in batch searchThe "Search by Financial Type" is a multi-select, but if you try to search by multiple values it fails validation (see screenshot 653 attached).
![Selection_653](/uploads/a61c238371a509c511a625d116d56413/Selection_653.png)
PR:https://...The "Search by Financial Type" is a multi-select, but if you try to search by multiple values it fails validation (see screenshot 653 attached).
![Selection_653](/uploads/a61c238371a509c511a625d116d56413/Selection_653.png)
PR:https://github.com/civicrm/civicrm-core/pull/131215.9https://lab.civicrm.org/dev/core/-/issues/539Create a hook for custom relative date filters (CRM-16195)2024-03-25T15:18:49ZJonGoldCreate a hook for custom relative date filters (CRM-16195)To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved rel...To summarize: From the time relative date filters debuted in 4.2(?) until 4.7, each release added a number of relative date filters that one person needed and the rest of the world didn't. To prevent this happening forever, we moved relative dates into an OptionGroup, and intended to give the ability to create new ones.
I worked on this last year but some cleanup PRs got stalled. They're all merged now so I'm submitting this.
While @eileen did work recently to support relative dates like "32 months in the past", it's still not possible to do relative dates like, "from 6 months ago to the end of this year", or "from Thanksgiving to Christmas". A former client of mine had reports that went from October to September, but this was NOT their fiscal year.
A simple hook facilitates the creation of custom relative date filters. I'll submit tests, but you can see an extension that uses it here: https://github.com/MegaphoneJon/com.megaphonetech.relativedatetest5.9JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/551Bookkeeping Transactions Report insufficient permissions2018-11-28T20:33:36ZfrancescbassasBookkeeping Transactions Report insufficient permissionsWhen a user without administer_civicrm permission try to run the Bookeeping Transactions Report finds the following error comes up:
`"API permission check failed for FinancialAccount/get call;
insufficient permission: require administe...When a user without administer_civicrm permission try to run the Bookeeping Transactions Report finds the following error comes up:
`"API permission check failed for FinancialAccount/get call;
insufficient permission: require administer CiviCRM"`
As noted [here](https://civicrm.stackexchange.com/q/23135/104), it seems that it occurs at least since version 4.29.5.9https://lab.civicrm.org/dev/core/-/issues/563Duplicate Case manager role2018-12-05T10:41:12ZMonish DebDuplicate Case manager roleSteps to replicate:
1. Create case
2. Go to 'Manage case' and change case manager to someone else
3. Change case manager back to original contact: error - duplicate relationship
4. From the contact's relationship tab, enable a relationsh...Steps to replicate:
1. Create case
2. Go to 'Manage case' and change case manager to someone else
3. Change case manager back to original contact: error - duplicate relationship
4. From the contact's relationship tab, enable a relationship
-- note that the end date is preserved, which may mean that the newly re-enabled relationship is still considered inactive
-- note that in the manage case roles panel the newly re-enabled relationship is not listed as the case manager
5. From the manage case roles panel, add a new role with the same case manager type, to one of the existing contacts: error, duplicate relationship
-- so if you change the case manager, there's currently no way to go back and set the original contact as case manager again5.9Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/594WYSIWYG Editor affected in CiviCRM 5.8.02018-12-28T08:55:55Zvakeesan26WYSIWYG Editor affected in CiviCRM 5.8.0After changing Display preference Wysiwig Editor setting from Text-Area to CKEditor
the editor not loaded anywhere.
Also the Configure CKEditor button is not visible in display preference page.
![image](/uploads/bf12c40db9672e5b0ad876...After changing Display preference Wysiwig Editor setting from Text-Area to CKEditor
the editor not loaded anywhere.
Also the Configure CKEditor button is not visible in display preference page.
![image](/uploads/bf12c40db9672e5b0ad8767f211260e7/image.png)
**New Activity**
![image](/uploads/ba87691aaab34031a6f363e7a6136fc2/image.png)
**Manage Events**
![image](/uploads/c74efdd95f623d4eac15fd7735e350a1/image.png)5.9https://lab.civicrm.org/dev/core/-/issues/606Wrong redirection when view/editing Option Groups inside a modal2018-12-18T20:26:39ZDavi AlexandreWrong redirection when view/editing Option Groups inside a modalThis seems like a regression caused by #259.
Before it, when opening the Option Group page via a modal, the behavior of clicking the "Done" button was to just close the modal so that people could continue filling the form:
![541](/uplo...This seems like a regression caused by #259.
Before it, when opening the Option Group page via a modal, the behavior of clicking the "Done" button was to just close the modal so that people could continue filling the form:
![541](/uploads/a1be12ccd111ef1c8a5926a6f0b3235c/541.gif)
After it, when clicking the "Done" button, the user is now redirected to the Option Groups page and lose all the data they might have already entered:
![581](/uploads/81741dc567d72fb1d583c43b045e7007/581.gif)5.9https://lab.civicrm.org/dev/core/-/issues/615PHP 7.2 compatibility: PHP warnings for improper usage of count()2018-12-19T20:02:57ZjensschuppePHP 7.2 compatibility: PHP warnings for improper usage of count()#118 took care of some of those warnings, but seems to have missed Smarty template code, which yields those warnings in the rendered PHP templates in templates_c.
An example: Line 20 in CRM/Contribute/Form/Contribution/OnBehalfOf.tpl:
...#118 took care of some of those warnings, but seems to have missed Smarty template code, which yields those warnings in the rendered PHP templates in templates_c.
An example: Line 20 in CRM/Contribute/Form/Contribution/OnBehalfOf.tpl:
```smarty
{if $onBehalfOfFields|@count}
```5.9https://lab.civicrm.org/dev/core/-/issues/619Custom field of type contact reference stopped working2019-01-03T00:27:11ZPradeep Nayakpradpnayak@gmail.comCustom field of type contact reference stopped workingCustom field of type contact reference stopped working for address field when upgraded to 5.8.1 from 4.7.31
The commit that might have caused this break is https://github.com/civicrm/civicrm-core/pull/12790/files#diff-bdea9a3ec62827e6c9...Custom field of type contact reference stopped working for address field when upgraded to 5.8.1 from 4.7.31
The commit that might have caused this break is https://github.com/civicrm/civicrm-core/pull/12790/files#diff-bdea9a3ec62827e6c90a70202ea9f7ccL1066
![Screen_Shot_2018-12-22_at_23.25.10](/uploads/0b37ef9862869048426f122485447c15/Screen_Shot_2018-12-22_at_23.25.10.png)5.9