Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-04-08T21:11:19Zhttps://lab.civicrm.org/dev/core/-/issues/2487Fix recurring contribution defaults2021-04-08T21:11:19ZeileenFix recurring contribution defaultsThe contribution_recur table defaults have some flaws. These don't really affect much in the way of existing code because people have been forced to pass them in and not rely on the defaults.
1) more fields should have defaults (mostly...The contribution_recur table defaults have some flaws. These don't really affect much in the way of existing code because people have been forced to pass them in and not rely on the defaults.
1) more fields should have defaults (mostly because it would stop test failures like this one https://test.civicrm.org/job/CiviCRM-Core-PR/40065/testReport/ - but it's also a case of bringing the API into line with the UI.
2) the default for the contribution_status_id should be pending not Completed. As long as it is correctly created as pending then the status will be updated by the BAO (to In Progress or Completed as appropriate) when a contribution is created that is linked to it. Core code correctly creates recurrings with the status id of Pending passed in but the api incorrectly defaults to Pending. Discussion is here https://github.com/civicrm/civicrm-core/pull/19512
- fields
| field | UI default | Old DB default | new db default |
| ------ | --------- | ------------- | -------------- |
| create_date | current time |none - must be passed in (required field)| current time |
| modified_date | current time |none - must be passed in (required field)| current time |
| start_date | current time |none - must be passed in (required field)| current time |
| frequency_unit | 1 |none - must be passed in (required field)| 1 |
| contribution_status_id | Pending |Completed| Pending |
Regarding frequency unit - I could see a case for the existing - required with no default - except that it's 'partner' field HAS a default of 'month' - which seems more of a leap than giving this a convenience default - especially since 1 really is the most frequent - more so than 'month' I expect5.37.0https://lab.civicrm.org/dev/core/-/issues/2485Search-kit - allow functions in the GROUP BY clause2022-05-12T13:39:07ZeileenSearch-kit - allow functions in the GROUP BY clause@colemanw I was hoping the answer to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/465 might be 'use search-kit' - but it seems reports allows the opportunity to include functions when grouping by date - eg
YEAR...@colemanw I was hoping the answer to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/465 might be 'use search-kit' - but it seems reports allows the opportunity to include functions when grouping by date - eg
YEAR(receive_date)
https://www.techonthenet.com/mysql/functions/year.php5.51.0https://lab.civicrm.org/dev/core/-/issues/2483Passing an array activity_id to ActivityContact.create silently casts it to a...2023-07-12T05:03:23ZDaveDPassing an array activity_id to ActivityContact.create silently casts it to activity id 1What happens is it silently updates activity id 1 with the new contact ids.
I think it would be better if it failed hard.
Where the cast is happening is in pear::DB because it's not expecting an array: https://github.com/civicrm/civicr...What happens is it silently updates activity id 1 with the new contact ids.
I think it would be better if it failed hard.
Where the cast is happening is in pear::DB because it's not expecting an array: https://github.com/civicrm/civicrm-packages/blob/c127df846491ee13b2a4dce5816f3da8b1d98d9a/DB/DataObject.php#L1224-L1231
It's the same in api3 and 4.https://lab.civicrm.org/dev/core/-/issues/2482$civicrm_root with relative paths causes core extensions to fail to be found2023-07-14T05:03:22Zanemirovsky$civicrm_root with relative paths causes core extensions to fail to be foundOverview
----------------------------------------
For some instances of CiviCRM, like with Drupal 8, CiviCRM is outside the web root. In that case, depending on how the $civicrm_root is generated/set, it can be set to something like "/va...Overview
----------------------------------------
For some instances of CiviCRM, like with Drupal 8, CiviCRM is outside the web root. In that case, depending on how the $civicrm_root is generated/set, it can be set to something like "/var/www/sitename.org/web/../vendor/civicrm/civicrm-core". After a change made in https://github.com/civicrm/civicrm-core/commit/ba89bdbde1aa7f21badab003b89b2cb0052fd175, paths like this cause CiviCRM to fail to locate core extensions which causes a fatal error.
Reproduction steps
----------------------------------------
1. Change the $civicrm_root to a path that contains a '..'.
1. Attempt to load CiviCRM.
1. Get an error "CRM_Extension_Exception_MissingException: Unknown extension: org.civicrm.shoreditch in CRM_Extension_Container_Collection->getContainer() (line 150 of /var/www/sitename.org/vendor/civicrm/civicrm-core/CRM/Extension/Container/Collection.php).".
Expected behaviour
----------------------------------------
CiviCRM should either handle paths with '..' gracefully or add validation/documentation that prevents $civicrm_root from being set to a path with invalid parts. For now, we're wrapping our $civicrm_root in realpath() to resolve the reference to '..'.https://lab.civicrm.org/dev/core/-/issues/2480Group filtering in search kit2021-06-17T03:25:47ZeileenGroup filtering in search kitI'm deliberately framing this issue as group filtering because group filtering has 99% of the gains and 2% of the complexity of adding group support to search kit / apiv4.
**History**
In the beginning there were groups are smart groups ...I'm deliberately framing this issue as group filtering because group filtering has 99% of the gains and 2% of the complexity of adding group support to search kit / apiv4.
**History**
In the beginning there were groups are smart groups and you could search on them.
There was no `group_contact_cache` table. It was possible to see 'hard' groups on the groups tab but it
was not possible to see smart groups. People asked to be able to see smart groups. Lobo said no.
Around 4.2 there was a sponsored 'improvement' to revert Lobo's 'no'. The group contact cache was added so that it was possible to populate all the smart groups and find out what group a contact was in.
Also around 4.2 and pretty much as soon as the new feature dropped a setting was added to allow sites to turn off the ability to see smart groups on the group tab because it was killing their sites.
Since 4.2 people have struggled with smart group cache performance, and lots of patches have been merged to try to address it.
Also since 4.2 people have been frustrated that there are very few places where you can access the smart groups a contact belongs to - we have had requests to show this on exports and my contact dashboard. However we switched back to the 'no' approach on this because it kills medium+ sizes sites.
More recently it has become effectively possible to turn off the smart group caching again by setting the time out to 0 and turning off opportunistic cache clearing. This is the approach I use and cautiously recommend.
**Smart groups, groups and performance**
So we have 3 things
1) which groups has someone actively been added to
2) which are the contacts that THIS saved search / smart group finds
3) of all the many many searches saved on this site which groups would find a person
Because we UI-conflate groups & smart groups we also conflate 3 into 1 & 2. I think there is a use-case for 3 but for most sites it is not worth the performance hit. We can deliver 1 & 2 in a performant way by following our existing code practices - most notably the one that made reports work ie:
If there is a group filter in play then
1) resolve the group filter to a list of relevant smart groups
2) create a temporary table of all the contacts in those groups (potentially but not necessarily using the `group_contact_cache`)
3) Use the table as the base ie `SELECT * FROM my_temp_table INNER JOIN civicrm_contact .....`
**Should we bypass the group contact cache?**
Probably codewise it's easier to populate it first because we have code that does. However, I have pretty strong doubts that it is very often effectively pre-populated before a query on a particular group runs.
There is a cron to prepopulate smart groups - on some sites this might make sense to use. My recommendation remains 'don't unless you have tested on your site'
**Could we filter off the saved search directly**
Yeah this is an interesting idea - add in a saved search rather than a group. Could be powerful. Let's keep pondering
**How would it look**
`Contact::get()->setWhere('group_id', 'IN', [8,7,89]);`
Note for not in we wouldn't be able to do the Base table inner join trick & TBH we can get the tests & contract right before we do any sort of optimisation5.39.0https://lab.civicrm.org/dev/core/-/issues/2479Loss of translation when copying (cloning) entities (multilingual)2021-06-09T21:46:53ZsamuelsovLoss of translation when copying (cloning) entities (multilingual)In a multilingual installation, copying/cloning of entities (like events) always result in a loss of the non-primary language.
For example, cloning a translated event in a English/French installation will result in having all the french ...In a multilingual installation, copying/cloning of entities (like events) always result in a loss of the non-primary language.
For example, cloning a translated event in a English/French installation will result in having all the french fields getting the english value of the original field.
It is particularly annoying when there are a lot of fields to (re)translate, i.e. :
- profile
- events
Also, not really a cloning but adding a translated custom field to a profile gives the same result.5.39.0https://lab.civicrm.org/dev/core/-/issues/2477Add job to cleanup acl_cache table, add setting to disable opportunistic flus...2021-04-06T20:03:10ZeileenAdd job to cleanup acl_cache table, add setting to disable opportunistic flushingThis is the same approach we use for smart groups - ie instead of cleaning up the cache on every contact edit there is a setting that allows for it to be done in a cron (or never if the cron is not enabled)
I am separately looking into ...This is the same approach we use for smart groups - ie instead of cleaning up the cache on every contact edit there is a setting that allows for it to be done in a cron (or never if the cron is not enabled)
I am separately looking into cleaning up the caching but I think this can & should be done independent of cleanup (it can evolve appropriately with the cleanup)5.37.0https://lab.civicrm.org/dev/core/-/issues/2476Proposal move weird acl stuff to extension2023-07-21T05:03:18ZeileenProposal move weird acl stuff to extensionI've been cleaning up the civicrm_acl table and the code supports 3 types of acls but the UI doesn't and hooks don't leverage them.
My take is that they started out with 2 - contact based & non-smart-group-based and then added a new rep...I've been cleaning up the civicrm_acl table and the code supports 3 types of acls but the UI doesn't and hooks don't leverage them.
My take is that they started out with 2 - contact based & non-smart-group-based and then added a new replacement - role based - without ever removing the first 2
The different types are denoted by the value entity_table in civicrm_acl. I believe this is only ever equal to civicrm_acl_role
I think we could simplify the code by moving the support for the other 2 to a core extension which ideally we only enable on upgrade IF we get results from
```SELECT * FROM civicrm_acl WHERE entity_table != 'civicrm_acl_role'```
@seamuslee @DaveD I'd be interested to see if you come to the same conclusionhttps://lab.civicrm.org/dev/core/-/issues/2475'Also include manual recipients' for schedule reminders broken2023-07-23T05:03:23ZPradeep Nayakpradpnayak@gmail.com'Also include manual recipients' for schedule reminders brokenOverview
----------------------------------------
'Also include manual recipients' for schedule reminders gets email only once for a reminder. The issue was reported just after Civi upgrade but i was able to replicate the issue for 5.25....Overview
----------------------------------------
'Also include manual recipients' for schedule reminders gets email only once for a reminder. The issue was reported just after Civi upgrade but i was able to replicate the issue for 5.25. This feature used to work on 4.7 but not sure when it stopped.
Reproduction steps
----------------------------------------
1. Create a schedule reminder for Membership with 0 from join date
1. Choose Limit or Add Recipients = Also include >> Choose Recipient(s).
1. Select recipients
1. Save the reminder by filling other details.
1. Create a membership for contact A and run schedule job for reminder manually.
1. Create a membership for contact B and run schedule job for reminder manually.
Current behaviour
----------------------------------------
The manual recipients gets email only for Contact A.
Also the recipients gets email for the first time even though no membership is present i.e create a schedule reminder with manual recipient and execute the reminder job. The manual recipients will get email but there are no membership present in the system.
Expected behaviour
----------------------------------------
The manual recipients gets email only for Contact A, Contact B and every time the reminder sends email.
Manual recipients should only get email when reminder to contact is sent
Environment information
----------------------------------------
* __CiviCRM: 5.35.1__
* __PHP: 7.3__
* __CMS: ALL CMS__https://lab.civicrm.org/dev/core/-/issues/2474Provide onscreen error reporting when ALTER TABLE fails during upgrade2023-07-18T05:03:24ZStoobProvide onscreen error reporting when ALTER TABLE fails during upgradeHUMBLY SUGGEST providing onscreen warning when ALTER TABLE fails during upgrade
This code CRM/Upgrade/Incremental/php/FiveThirtyFour.php was failing because of invalid date format 0000-00-00 in my older install
> public static function u...HUMBLY SUGGEST providing onscreen warning when ALTER TABLE fails during upgrade
This code CRM/Upgrade/Incremental/php/FiveThirtyFour.php was failing because of invalid date format 0000-00-00 in my older install
> public static function updatePledgeTable(
SOLUTION:
Either set my.cnf or my.ini
`innodb_strict_mode = OFF`
or
`ALTER TABLE civicrm_pledge MODIFY start_date datetime NULL DEFAULT NULL, MODIFY create_date datetime NULL DEFAULT NULL;`https://lab.civicrm.org/dev/financial/-/issues/171False positive message about missing INTL PHP extension on membership type form2021-03-31T23:26:43ZDaveDFalse positive message about missing INTL PHP extension on membership type formHappens on dmaster.demo too so it's not windows or anything weird.
1. Click add membership type.
2. Click cancel. It happens if you fill it out too but this is quicker and is enough to see it.
There might be a couple things here.
One ...Happens on dmaster.demo too so it's not windows or anything weird.
1. Click add membership type.
2. Click cancel. It happens if you fill it out too but this is quicker and is enough to see it.
There might be a couple things here.
One is that the message is tied partly to whether the value is numeric, which doesn't really have anything to do with the missing php extension.
The second is that for whatever reason the $amount value is being passed in as `<input size="6" maxlength="14" name="minimum_fee" type="text" id="minimum_fee" class="six crm-form-text" />`. I'm not sure yet what the mismatch is there.
It's kind of a regression because of the numeric part, but the form value might be old.5.37.0https://lab.civicrm.org/dev/core/-/issues/2471Email Greeting Update Job performance issue2023-07-23T05:03:22ZmclarkeEmail Greeting Update Job performance issueOverview
----------------------------------------
Recently tried to update all the email_greeting's on a large number of contacts. I ran into significantly long queries (10+ secs), that locked `civicrm_contact` table for updates! This ca...Overview
----------------------------------------
Recently tried to update all the email_greeting's on a large number of contacts. I ran into significantly long queries (10+ secs), that locked `civicrm_contact` table for updates! This caused very slow operation on production site and in a some cases timeouts.
Example use-case
----------------------------------------
1. Cleared all the `email_greeting_display` to NULL
1. Swapped in a new Default Email Greeting ID
1. Ran the `update_greeting` job with `ct=Individual gt=email_greeting force=0 limit=1000`
Current behaviour
----------------------------------------
Very poor performance on job run:
1. Very slow
1. Locks table for updates.
Proposed behaviour
----------------------------------------
Make it fast!
Tracked down the code to here: https://lab.civicrm.org/dev/core/-/blob/master/CRM/Contact/BAO/Contact/Utils.php#L1010
Ran an EXPLAIN on this SQL query and it is a table scan. Mystery explained.
I applied a tweak to the query that appears to fix the issue (at least for my paramters). Indeed I stole the idea from lower down in that very function.
adding `WHERE id IN (" . implode(',', $allContactIds) . ")` (after the huge CASE statement) to the main update query appears to remove the table scan and prevent the table locking.
Not sure this is a decent general solution, but just wanted to offer it!
Thanks!!
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/2468Deprecated function Redis::delete()2021-03-19T15:54:36ZwouterhDeprecated function Redis::delete()Overview
----------------------------------------
We receive a notification on flushing CiviCRM cache
```
Deprecated function: Function Redis::delete() is deprecated in CRM_Utils_Cache_Redis->delete() (line 148 of /var/www/html/vendor/c...Overview
----------------------------------------
We receive a notification on flushing CiviCRM cache
```
Deprecated function: Function Redis::delete() is deprecated in CRM_Utils_Cache_Redis->delete() (line 148 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Utils/Cache/Redis.php).
```
Reproduction steps
----------------------------------------
1. Setup environment like below
1. Flush CiviCRM cache
Environment information
----------------------------------------
* __CiviCRM:__ 5.35.1
* __PHP:__ 7.4.15
* __CMS:__ Drupal 8
* __Redis__ 5.3.3
Comments
----------------------------------------
_I'll provide a patch._5.37.0https://lab.civicrm.org/dev/core/-/issues/2466Can't export link custom fields2021-03-22T11:56:31ZtschuettlerCan't export link custom fieldsOverview
----------------------------------------
It is currently not possible to export custom fields of type link with length above around 110 chars. The added HTML markup pushes the length of the string above 256 chars in the export c...Overview
----------------------------------------
It is currently not possible to export custom fields of type link with length above around 110 chars. The added HTML markup pushes the length of the string above 256 chars in the export column for this field.
I'm not aware, that this is a recent regression.
Reproduction steps
----------------------------------------
1. Create a custom field `url` of type **Link**.
1. Add a reasonably long `url` to a contact (e.g. `https://stage.example.org/system/files/webform/way_too_long_url_that_still_fits_in_a_link_custom_field_but_fails_to_export.jpg`).
1. Export this Contact outputting the custom field `url`
1. Got an error "**Fatal error: DB error**".
Current behaviour
----------------------------------------
Export fails if it contains long links.
```
Mar 18 17:47:44 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] =>
INSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `custom_23`)
VALUES (1,'<a href=\"https://stage.example.org/system/files/webform/way_too_long_url_that_still_fits_in_a_link_custom_field_but_fails_to_export.jpg\" target=\"_blank\">https://stage.example.org/system/files/webform/way_too_long_url_that_still_fits_in_a_link_custom_field_but_fails_to_export.jpg</a>')
[nativecode=1406 ** Data too long for column 'custom_23' at row 1]
[type] => DB_Error
[user_info] =>
INSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `custom_23`)
VALUES (1,'<a href=\"https://stage.example.org/system/files/webform/way_too_long_url_that_still_fits_in_a_link_custom_field_but_fails_to_export.jpg\" target=\"_blank\">https://stage.example.org/system/files/webform/way_too_long_url_that_still_fits_in_a_link_custom_field_but_fails_to_export.jpg</a>')
[nativecode=1406 ** Data too long for column 'custom_23' at row 1]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="
INSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `custom_23`)
VALUES (1,'<a href=\"https://stage.example.org/system/files/webform/way_too_long_url_that_still_fits_in_a_link_custom_field_but_fails_to_export.jpg\" target=\"_blank\">https://stage.example.org/system/files/webform/way_too_long_url_that_still_fits_in_a_link_custom_field_but_fails_to_export.jpg</a>')
[nativecode=1406 ** Data too long for column 'custom_23' at row 1]"]
)
Mar 18 17:47:44 [debug] $backTrace = #0 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Error.php(942): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...")
#3 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...")
#4 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR::_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...", "DB_Error", TRUE)
#5 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#6 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-1, NULL, NULL, "\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...", "1406 ** Data too long for column 'custom_23' at row 1")
#7 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/db/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
#8 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...")
#9 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/packages/DB/DataObject.php(2696): DB_common->query("\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...")
#10 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/packages/DB/DataObject.php(1829): DB_DataObject->_query("\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...")
#11 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/DAO.php(454): DB_DataObject->query("\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...")
#12 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/DAO.php(1565): CRM_Core_DAO->query("\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...", TRUE)
#13 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Export/BAO/Export.php(365): CRM_Core_DAO::executeQuery("\nINSERT INTO civicrm_tmp_d_export_4cf7fb7cd8210f2fe06326f57a33263f (`id`, `c...")
#14 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Export/BAO/Export.php(199): CRM_Export_BAO_Export::writeDetailsToTable(Object(CRM_Export_BAO_ExportProcessor), (Array:1), (Array:1))
#15 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Export/Form/Map.php(142): CRM_Export_BAO_Export::exportComponents(TRUE, (Array:1), (Array:7), "`sort_name` asc", (Array:1), NULL, 1, " contact_a.id IN ( 202 ) ", "civicrm_contact", 0, 0, (Array:6), "AND")
#16 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Form.php(526): CRM_Export_Form_Map->postProcess()
#17 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/StateMachine.php(144): CRM_Core_Form->mainProcess()
#18 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Next.php(43): CRM_Core_StateMachine->perform(Object(CRM_Contact_Export_Form_Map), "next", "Next")
#19 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Contact_Export_Form_Map), "next")
#20 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Export_Form_Map), "next")
#21 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Controller.php(347): HTML_QuickForm_Page->handle("next")
#22 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(313): CRM_Core_Controller->run((Array:4), (Array:0))
#23 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:13))
#24 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:4))
#25 /opt/buildkit/build/dmaster/sites/all/modules/civicrm/drupal/civicrm.module(458): CRM_Core_Invoke::invoke((Array:4))
#26 /opt/buildkit/build/dmaster/includes/menu.inc(527): civicrm_invoke("contact", "search", "advanced")
#27 /opt/buildkit/build/dmaster/index.php(21): menu_execute_active_handler()
#28 {main}
```
Expected behaviour
----------------------------------------
Successfull export of long links.
I can think of two options:
1. Keep exporting the URL with HTML markup: Enlarge the field for links in the temporary table for exports.
1. **Breaking change** Just export the URL without markup
* I currently can't think of a reason to have HTML markup in the CSV.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
Does not seem to be related:
* __Browser:__ _Firefox 86.0.1_
* __CiviCRM:__ _Master_
* __PHP:__ _7.4_
* __CMS:__ _Drupal 7.78_
* __Database:__ _MySQL 8.0.23_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
Problem seems to be identical to the one solved in dev/core#1787.5.37.0tschuettlertschuettlerhttps://lab.civicrm.org/dev/core/-/issues/2464Fix Drupal Base 'isFrontEndPage' Returns Wrong Value After Saving A Settings...2021-03-29T20:13:19Ztunbola@compucorp.co.ukFix Drupal Base 'isFrontEndPage' Returns Wrong Value After Saving A Settings PageOverview
----------------------------------------
This [PR](https://github.com/civicrm/civicrm-core/pull/18397) fixed the way civicrm tells a civicrm page from a non civicrm page.
However when a settings page such as Civicase settings (...Overview
----------------------------------------
This [PR](https://github.com/civicrm/civicrm-core/pull/18397) fixed the way civicrm tells a civicrm page from a non civicrm page.
However when a settings page such as Civicase settings (civicrm/admin/setting/case), Mailing settings (civicrm/admin/mail) and most of the setting pages are saved, the `CRM_Utils_System_DrupalBase::isFrontEndPage` function reports that the `civicrm/admin` page redirected to after a setting is saved is a frontend page which could have a significant impact on functions that rely on this. For example, the shoreditch theme [relies on this function](https://github.com/civicrm/org.civicrm.shoreditch/blob/master/shoreditch.php#L188) to know whether the shoreditch JS and CSS assets need to be included for a particular page. This wrong value makes the shoreditch theme not to be applied after saving the settings page and the page is not shoreditch themed and loses the styling. Refreshing the page a second time however fixes the issue but this glitch needs to be fixed.
Reproduction steps
----------------------------------------
1. On a site with the shoreditch theme active, edit a settings page and click save. The user is directed to the Civicrm admin page with shoreditch styles not applied at all. Refreshing the page a second time however brings back the expected styling.
Current behaviour
----------------------------------------
![Administer_CiviCRM___c8008_2021-03-17_14-14-56](/uploads/200d1e52f00a157e825b71a85a4d9053/Administer_CiviCRM___c8008_2021-03-17_14-14-56.png)
Expected behaviour
----------------------------------------
![Administer_CiviCRM___c8008_2021-03-17_14-15-12](/uploads/7b62014d903561e081bb0281871c60c8/Administer_CiviCRM___c8008_2021-03-17_14-15-12.png)
Technical Details
----------------------------------------
In the Post Process function for the Admin Setting form class which is the base class for most settings page, this [line](https://github.com/civicrm/civicrm-core/blob/master/CRM/Admin/Form/Setting.php#L115) clears the db cache including the `civicrm_menu` table. When the form is redirected to a new page after saving, the civicrm initialization calls the `civicrm_html_head` function which calls this line in the function `https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/System/DrupalBase.php#L662`, because the menu table has been cleared, the `$item` variable is empty and the given path is returned as a frontend page, as a result, necessary shoreditch styles are not added.
Solution will be to add call the form's menu rebuild function [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Admin/Form/Setting.php#L120) to rebuild the menu table after it is cleared, same as is done for few of the forms e.g [the URL setting form](https://github.com/civicrm/civicrm-core/blob/master/CRM/Admin/Form/Setting/Url.php#L85) which is why the few forms that implement this does not have this issue.
Will put up a PR to fix this. Just documenting this here.5.37.0https://lab.civicrm.org/dev/core/-/issues/2463Feature to file emails on multiple case ids provided in the url not working2021-03-29T18:18:17ZDaveDFeature to file emails on multiple case ids provided in the url not workingI don't use this feature, and the ability to use multiple case ids appears to have originally been added for CiviHR, but this came up while looking into something else.
After https://lab.civicrm.org/dev/core/-/issues/1750, what happens ...I don't use this feature, and the ability to use multiple case ids appears to have originally been added for CiviHR, but this came up while looking into something else.
After https://lab.civicrm.org/dev/core/-/issues/1750, what happens now is multiple activities are created if there were multiple recipients. The code at https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/Form/Task/EmailTrait.php#L453-L457 loops thru all the case ids in the url and files the activity on them. However, after #1750, the activity id being used here is only the last activity created, because it's the one from [here](https://github.com/civicrm/civicrm-core/blob/9a518a43e3296153eae8a1bb22bcdc350aebea9a/CRM/Activity/BAO/Activity.php#L1180) which is now within the loop, but it's not returned until [after the loop](https://github.com/civicrm/civicrm-core/blob/9a518a43e3296153eae8a1bb22bcdc350aebea9a/CRM/Activity/BAO/Activity.php#L1206). So that would be the first problem, and is technically a regression in 5.36.
However, for a single case id it's not necessary anyway to do the filing loop in EmailTrait.php since it was already filed on the case by the api call at https://github.com/civicrm/civicrm-core/blob/9a518a43e3296153eae8a1bb22bcdc350aebea9a/CRM/Activity/BAO/Activity.php#L984.
However*2, if you have multiple case ids the problem is it doesn't even get to the first problem because that api call fails because `CiviCRM_API3_Exception: "case_id is not a valid integer"`. That might have broke at https://github.com/civicrm/civicrm-core/commit/f7f1cc3b179536bcf2b3e8d1c49a481c155fc933 but I haven't confirmed and possibly hasn't been working for a long time.
@jamienovick1 Does CiviHR still use this feature to set multiple case ids in the url for email activities?5.37.0https://lab.civicrm.org/dev/core/-/issues/2462Membership end date cannot be edited as "empty" (for lifetime Membership Types)2023-10-23T05:03:23Zsluc23Membership end date cannot be edited as "empty" (for lifetime Membership Types)Overview
----------------------------------------
When manually editing and overriding a Membership with "Active" status, the end date cannot be set as **empty** for lifetime membership types. It keeps the old end_date value
Reproductio...Overview
----------------------------------------
When manually editing and overriding a Membership with "Active" status, the end date cannot be set as **empty** for lifetime membership types. It keeps the old end_date value
Reproduction steps
----------------------------------------
1. Edit a *Cancelled* membership
2. Set **Status Override**: *Override Permanently* / **Status**: *Current*
3. Set **Membership Expiration Date**: *- empty -* (it's a*lifetime* Membership Type)
4. Save
5. The **Membership Expiration Date** remains the old value, it's not set as *empty*
![civicrm_membershipenddate](/uploads/d3477600cfbf6ac54a0232d1c79e2f97/civicrm_membershipenddate.gif)
*It can be reproduced as well as editing a Membership already overridden with Current status, just trying to clean end_date*
Current behaviour
----------------------------------------
The **Membership Expiration Date** remains the old value, it's not set as *empty*
Expected behaviour
----------------------------------------
The **Membership Expiration Date** must be empty
Environment information
----------------------------------------
Tested in Drupal 7.78 / CiviCRM 5.35.0
Comments
----------------------------------------https://lab.civicrm.org/dev/wordpress/-/issues/96Incorrect capability assigned to CiviCRM menu items2021-10-16T13:35:41ZhaystackIncorrect capability assigned to CiviCRM menu itemsThe capability assigned to CiviCRM sub-menu items in 5.34+ is `access_civicrm` and should be `administer_civicrm` by default.
Edit: because `administer_civicrm` is not automatically granted to WordPress admins, `manage_options` seems a ...The capability assigned to CiviCRM sub-menu items in 5.34+ is `access_civicrm` and should be `administer_civicrm` by default.
Edit: because `administer_civicrm` is not automatically granted to WordPress admins, `manage_options` seems a more sensible default capability. I have add filters so that this can be overridden if required.
https://github.com/civicrm/civicrm-wordpress/pull/245haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/2460Ordering of theme CSS files2023-07-30T05:03:20Zaydunsaidan.saunders@squiffle.ukOrdering of theme CSS filesOverview
----------------------------------------
Change the ordering of CSS files so that theme files can easily override core files.
Current behaviour
----------------------------------------
A theme can declare itself through a `myex...Overview
----------------------------------------
Change the ordering of CSS files so that theme files can easily override core files.
Current behaviour
----------------------------------------
A theme can declare itself through a `myextension.theme.php` file which is handled by the civix boilerplate using `hook_civicrm_themes()`. If the theme is active it causes the theme's CSS files to be loaded in place of the default Greenwich theme.
Other CSS files like `contactSummary.css` are loaded after the theme's CSS file making it difficult to override.
Proposed behaviour
----------------------------------------
Change the order so that theme CSS files are loaded after other core CSS so that theme files can do their job more easily.
Example
-------
`contactSummary.css` has:
```
#crm-container div.crm-summary-display_name {
font-size: 19px;
padding-bottom: 10px;
}
```
`civicrm.css` (from Finsbury Park) has:
```
#crm-container div.crm-summary-display_name {
font-size: 1.4rem;
margin: 30px 0 20px;
line-height: 1.4rem;
}
```
The current ordering results in the theme's font-size being overridden by core.
Comments
----------------------------------------
Can someone point me to where the theme's CSS gets added to the page?https://lab.civicrm.org/dev/core/-/issues/2459Changing a custom field from multiple choice to Text breaks the API2021-03-16T14:41:38ZJonGoldChanging a custom field from multiple choice to Text breaks the APIOverview
----------------------------------------
Changing a custom field from a multiple choice (Radio, Checkboxes, etc.) to a free-entry text box works, until you try to write to the custom field via the API.
Reproduction steps
------...Overview
----------------------------------------
Changing a custom field from a multiple choice (Radio, Checkboxes, etc.) to a free-entry text box works, until you try to write to the custom field via the API.
Reproduction steps
----------------------------------------
1. On a demo site, go to **Administer » Customize Data and Screens » Custom Fields**.
1. In *Constituent Information*, edit the *Most Important Issue* field to have a *Field Input Type* of **Single-line input field (text or numeric)** and save.
1. Attempt to use APIv3 `Contact.create` to write a value to the field that wasn't in the original set of multiple-choice values.
Current behaviour
----------------------------------------
API Error - your value isn't an accepted value for this field.
Expected behaviour
----------------------------------------
A custom field with a data type of "String" and HTML type of "Text" should take any alphanumeric value.
Comments
----------------------------------------
Changing the HTML type doesn't remove the Option Group ID. While arguably the API code should ignore that, it seems more important that the data be correct.5.37.0JonGoldJonGold