CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-06-17T00:00:49Zhttps://lab.civicrm.org/dev/core/-/issues/2317CiviMail, Tracked Opens and Unique Opens should also be counted when click-th...2023-06-17T00:00:49Zjustinfreeman (Agileware)CiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email clientCiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email client. Thus enabling some statistics to be captured and avoid si...CiviMail, Tracked Opens and Unique Opens should also be counted when click-through events occurs to workaround issues where the tracked open, pixel is blocked by the email client. Thus enabling some statistics to be captured and avoid situations where Tracked Opens and Unique Opens have a statistic of 0 but all the other metrics have non-zero numbers.
PS. I had always thought that this was already the case, but discovered otherwise whilst investigating a support request. Quite surprised.
This would also require a documentation change.
Agileware Ref: CIVICRM-1649https://lab.civicrm.org/dev/core/-/issues/2304Mailing List Subscription page does not display authenticated users their exi...2023-06-16T19:32:16Zjustinfreeman (Agileware)Mailing List Subscription page does not display authenticated users their existing group subscriptions, therefore unable to determine which groups to subscribe or unsubscribeThe built-in CiviCRM Mailing List Subscription page (/civicrm/mailing/subscribe/?reset=1) does not display authenticated users their existing group subscriptions, therefore they are unable to determine which groups to subscribe or unsubs...The built-in CiviCRM Mailing List Subscription page (/civicrm/mailing/subscribe/?reset=1) does not display authenticated users their existing group subscriptions, therefore they are unable to determine which groups to subscribe or unsubscribe. It would be great to add this as a feature. Would make this page much more useful.
Agileware Ref: CIVICRM-1641https://lab.civicrm.org/dev/core/-/issues/2290Look at REMOVING id column from cache tables2022-12-13T11:58:44ZjitendraLook at REMOVING id column from cache tablesThis is a continuation of the "In Progress" JIRA https://issues.civicrm.org/jira/browse/CRM-19385
which aimed at removing the id from the cache tables but unfortunately was never completed since I see we still have id column in all the ...This is a continuation of the "In Progress" JIRA https://issues.civicrm.org/jira/browse/CRM-19385
which aimed at removing the id from the cache tables but unfortunately was never completed since I see we still have id column in all the cache tables.
```
civicrm_acl_cache
civicrm_acl_contact_cache
civicrm_cache
civicrm_group_contact_cache
civicrm_prevnext_cache
civicrm_relationship_cache
```
Related PRs -
- https://github.com/civicrm/civicrm-core/pull/9743 (Closed)
- https://github.com/civicrm/civicrm-core/pull/9801 (Closed)
- https://github.com/civicrm/civicrm-core/pull/10019 (Merged) - This removed the dependency in the code so think we can start by removing the column directly.
Thoughts @eileen @johnkhttps://lab.civicrm.org/dev/core/-/issues/2266Wording beside on-behalf-of checkbox isn't required, but has no default eithe...2023-11-23T07:25:09ZDaveDWording beside on-behalf-of checkbox isn't required, but has no default either, so appears as a mysterious checkboxI'm not sure yet if this is recent. I remember there being a default but it's not a strong memory.
1. Create a contribution page.
1. On the title page there's a choice to "Allow individuals to contribute and / or signup for membership o...I'm not sure yet if this is recent. I remember there being a default but it's not a strong memory.
1. Create a contribution page.
1. On the title page there's a choice to "Allow individuals to contribute and / or signup for membership on behalf of an organization". Check it.
1. In the section that appears there's a box for a label that has no default and is not required. Leave it blank.
1. Finish off the rest of the settings - doesn't matter too much what.
1. Visit the contribution page. It looks like this:
![Untitled](/uploads/4776b6636a1ea3fb9106face184bd545/Untitled.png)
It's easily fixable by adding words in the label box, but it just a seems a wrong default and I don't remember it coming up as a problem before.
I notice the label box is a textarea for some reason. Maybe it used to be a normal textbox and so the default now isn't getting set correctly?
Also ignore the decimal places in the dollar amounts in the screenshot - that's a known windows issue with civi.https://lab.civicrm.org/dev/core/-/issues/2255Proposal, Allow the CiviCRM CKEditor to be disabled for specific components a...2023-06-07T05:38:36Zjustinfreeman (Agileware)Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.
CKEditor is alwa...Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.
CKEditor is always displayed for custom Message Templates which in our experience reliably mangles the HTML and Smarty Tags. CKEditor is NOT disabled for "System" Message Templates and therefore does not have this issue.
Agileware Ref: CIVICRM-1609 CIVICRM-1608https://lab.civicrm.org/dev/core/-/issues/2237Provide some way for an extension's database tables to automatically get incl...2022-08-24T18:56:45ZDaveDProvide some way for an extension's database tables to automatically get included when a site runs utf8mb4 conversionThere's an option in the api call / api explorer when running the utf8mb4 conversion to specify some tablename patterns, but this requires the user to know what the tables are that all their extensions create.
One idea is a hook that le...There's an option in the api call / api explorer when running the utf8mb4 conversion to specify some tablename patterns, but this requires the user to know what the tables are that all their extensions create.
One idea is a hook that lets an extension advertise the names of tables it creates. If it wants to manage the charset itself for a table then it can just not list it.
Another is a standard naming like civicrm_ext_FOO, which then core knows not to conflict for its own tables, but which starts with civicrm so gets picked up by default.
Open to other ideas. The status quo is also technically an option. And it's only important if there's some connection between text data in the extension's tables and core tables, or it stores emojis and such.https://lab.civicrm.org/dev/core/-/issues/2225Add a contact.checksum_raw token that does not include "cs="2023-09-24T22:53:45ZherbdoolAdd a contact.checksum_raw token that does not include "cs="Unlike all the other tokens which only include the actual data, such as `{contact.contact_id}`, the `{contact.checksum}` also includes the parameter name. There doesn't seem to be any good reason other than that is how it was always done...Unlike all the other tokens which only include the actual data, such as `{contact.contact_id}`, the `{contact.checksum}` also includes the parameter name. There doesn't seem to be any good reason other than that is how it was always done.
I suppose it's not possible to fix this token at this point since lots of existing links rely on it. But perhaps a new token? A bit messy but I need something like `{contact.checksum.raw}`https://lab.civicrm.org/dev/core/-/issues/2195Custom fields of type money and drop-down list with round numbers don't updat...2023-07-04T12:55:04ZDaveDCustom fields of type money and drop-down list with round numbers don't update existing values when you change the option valueCame up reviewing https://github.com/civicrm/civicrm-core/pull/18959
For example:
1. Edit or create a custom field group for contacts.
1. Add a custom field of type money and make it a drop-down select list.
1. For the values, make cho...Came up reviewing https://github.com/civicrm/civicrm-core/pull/18959
For example:
1. Edit or create a custom field group for contacts.
1. Add a custom field of type money and make it a drop-down select list.
1. For the values, make choice 1 have value 10 and choice 2 have value 20.
1. Create a contact and pick one of the choices. Save.
1. Note that in the database in the civicrm_value_XX table this has been stored as 10.00, with the decimals. Note that in civicrm_option_value that the choice is stored as 10, without the decimals.
1. Go and edit the option value and change the value to anything else.
1. What's supposed to happen is that the contact's custom field values should be updated to match. But because of the mismatch above it doesn't change it in civicrm_value_XX and it now appears blank when viewing the contact.
I don't think this is recent.https://lab.civicrm.org/dev/core/-/issues/2163log_date is missing on logging detail report2023-05-26T16:05:01ZDaveDlog_date is missing on logging detail report1. Turn on logging at Admin - System Settings - Misc.
2. Update a contact.
3. Go to the logging summary civireport.
4. Click on "Update" in the row for your update.
5. At the top of the detail report it will say something like `Change to...1. Turn on logging at Admin - System Settings - Misc.
2. Update a contact.
3. Go to the logging summary civireport.
4. Click on "Update" in the row for your update.
5. At the top of the detail report it will say something like `Change to blah made by somebody on :`
6. It's supposed to show the modified date at the end.
It's coming from [this check](https://github.com/civicrm/civicrm-core/blob/4d660b8e1e6ac980a06b096fbc4cde1e1666e0b9/CRM/Report/Form/Contact/LoggingSummary.php#L193) which decides the log date isn't needed. The comment when that check was added says it can make the report less accurate because of some older data that used to be the way things were logged. So I'm hesitant to just remove that check.
Some other options include passing it but with a different name, and then in the detail report know that that new name is just used in intro text. Or looking it up in the detail report.
TBD.
@VangelisP just FYI.https://lab.civicrm.org/dev/core/-/issues/2157Array to string conversion in DB_DataObject when doing on behalf of and no st...2023-05-26T16:13:04ZDaveDArray to string conversion in DB_DataObject when doing on behalf of and no state/provinceIf you submit a contribution on behalf of an org and leave the state/province blank, you get `Notice: Array to string conversion in DB_DataObject->_build_condition() (line 2903 of .../web/sites/all/modules/civicrm/packages/DB/DataObject....If you submit a contribution on behalf of an org and leave the state/province blank, you get `Notice: Array to string conversion in DB_DataObject->_build_condition() (line 2903 of .../web/sites/all/modules/civicrm/packages/DB/DataObject.php)`
(At the moment to see this you need to make the field not required on the profile, but it happens either way it's just there's currently a separate issue when the field is required and the country has no state/provinces.)
What happens is that at that code line `$this->name` and `$this->abbreviation` contain a big long list of numbers and letters, including, oddly, the strings "_A", "_B", "_C", etc, but ONLY up to "_P".https://lab.civicrm.org/dev/core/-/issues/2122Account for time zone on event registration pages2023-11-05T14:13:53ZwmortadaAccount for time zone on event registration pagesOverview
----------------------------------------
There doesn't appear to be a way to account for the time zone on an event registration page.
This is less of an issue for a local event, but is quite a problem for a global online event....Overview
----------------------------------------
There doesn't appear to be a way to account for the time zone on an event registration page.
This is less of an issue for a local event, but is quite a problem for a global online event.
At a minimum I would expect there to be an option to set the time zone for the event and for the time zone to display on the event registration page. (Ideally you'd want the page to show the time in the user's time zone.)
Current behaviour
----------------------------------------
There is no option to set the time zone for an event. (I presume that the system time zone is used but I'm not sure.)
![image](/uploads/6727ccb71e4b3129120a3275240c56cf/image.png)
The time zone isn't displayed on the event registration page.
![image](/uploads/a16d1c595ab9020e2d9e9c2d668e114c/image.png)
Proposed behaviour
----------------------------------------
There is an option to set the time zone when creating an event. This should default to the user's time zone.
The time zone is displayed on the event registration page.
Comments
----------------------------------------
I became aware of this when trying to register for this event: https://civicrm.org/civicrm/event/info?reset=1&id=1553
Probably relates to https://lab.civicrm.org/dev/core/-/issues/441
Agileware Ref: CIVICRM-404 (feature not found)https://lab.civicrm.org/dev/core/-/issues/2114Trigger-based logging doesn't log if just changing a letter to upper/lower case2023-06-29T12:55:38ZDaveDTrigger-based logging doesn't log if just changing a letter to upper/lower case1. Turn on logging. (Admin - System Settings - Misc - Logging).
1. Change the first name of a contact just changing e.g. the first letter from upper to lower case.
1. Either look in the database in log_civicrm_contact or go to CiviReport...1. Turn on logging. (Admin - System Settings - Misc - Logging).
1. Change the first name of a contact just changing e.g. the first letter from upper to lower case.
1. Either look in the database in log_civicrm_contact or go to CiviReports - Contact Reports - Contact Logging.
1. Change has not been logged.
It's because the standard collation for civi is the case-insensitive xxx_unicode_ci or possibly xxx_general_ci. You might have also changed it manually to use the same as your CMS but is likely still case-insensitive. And in mysql 8 the default utf8mb4_0900_ai_ci is also accent-insensitive (i.e. `é` is treated the same as `e`), if you manually changed your civi tables to use that.
The logging triggers should probably use `xxx_bin`. Related but separate: https://github.com/civicrm/civicrm-core/pull/18721https://lab.civicrm.org/dev/core/-/issues/2107scheduled reminders incorrectly exclude emails with on_hold = opt-out2023-05-20T05:50:59Zlcdwebscheduled reminders incorrectly exclude emails with on_hold = opt-outTo reproduce:
1. create a contact with an email and flag it on_hold = opt out
2. create a scheduled reminder that can be easily triggered. e.g. on creation of a scheduled activity
3. create the conditions for the scheduled reminder (e.g....To reproduce:
1. create a contact with an email and flag it on_hold = opt out
2. create a scheduled reminder that can be easily triggered. e.g. on creation of a scheduled activity
3. create the conditions for the scheduled reminder (e.g. create a scheduled activity of the selected type)
4. run the scheduled reminder job
Result: the contact will not receive the scheduled reminder because it skips email addresses with on_hold of either type (either bound or opt out).
Expected result: contact receives email.
This is worth some discussion as I know scheduled reminders sometimes fall into a grey area between bulk email and transactional email. Personally I believe they are more transactional than bulk, and believe we have historically viewed them that way.
The offending code is in: CRM_Contact_BAO_Contact::getPrimaryEmail(). That method has a parameter $polite = (bool) which is only used once in the codebase when called by CRM_Core_BAO_ActionSchedule::sendReminderEmail(). When that is true we condition on civicrm_email.on_hold = 0. I believe it should be civicrm_email.on_hold != 1 (doesn't equal bounce). As it's the only place that parameter/condition is used, we just need to decide if scheduled reminders are indeed transactional and should not exclude opt outs.
It's worth noting that the condition in that function also excludes civicrm_contact.do_not_email but does NOT exclude civicrm_contact.is_opt_out. We're not currently treating it like a bulk email at the contact level -- just at the email level.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/2083If using the email processor to file inbound emails on cases via subject, it ...2022-09-27T16:29:36ZDaveDIf using the email processor to file inbound emails on cases via subject, it can file it on the wrong case on even moderately large sitesCame up as a side-thought while testing https://github.com/civicrm/civicrm-core/pull/18624.
On Manage Case, in the case roles section, you can send an outbound email to people by clicking the mail icon. In this context, civi will add a ...Came up as a side-thought while testing https://github.com/civicrm/civicrm-core/pull/18624.
On Manage Case, in the case roles section, you can send an outbound email to people by clicking the mail icon. In this context, civi will add a hash to the subject. If you've set up the inbound email processor, you can autofile responses onto cases since it will try to match the hash.
The problem is the algorithm used for the hash stops being unique at some point, and so matches a different case. It turns out you're almost guaranteed hash collisions on a site with 20000 cases. The exact first collision depends on CIVICRM_SITE_KEY which is different for every site. In fact for the site_key on a dev site where I was testing the PR you get the first collision around 11000 cases.
The easy solution is stop using substrings of hashes and just use case id as has been requested several times over the years and there's an extension that does this (self-promo): https://lab.civicrm.org/extensions/caseidinsubject
(Further promo: It also lets you remove the hash completely.)
Civi would still need to accept the 7-character version for inbound emails since there will be a (possibly lengthy) period of time where external recipients will still reply to older emails with the 7-character hash in the subject. But eventually that could be moved to an extension for anyone who wants to support it for longer.
For some background on why it's a hash, I've mentioned in several places that I vaguely recall this being a misunderstanding during initial development. Well-meant, as a privacy thought, but not necessary.
If there's desire to still have a hash, an obvious alternate solution is use a bigger substring or the whole string. In theory this could also be done by an extension.https://lab.civicrm.org/dev/core/-/issues/2081Proposal: Extension upgrades should reconcile managed entities2023-01-19T22:49:26ZJonGoldProposal: Extension upgrades should reconcile managed entitiesWhen you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension up...When you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension upgrade, we run this code.
Recently, I've had two different extensions fail to work on deployment because the upgrade process doesn't reconcile managed entities. I imagine I'm not alone.https://lab.civicrm.org/dev/core/-/issues/2074Case activity assignees receive an email copy every time activity is edited2023-05-16T12:45:13ZDaveDCase activity assignees receive an email copy every time activity is editedNot sure yet when this changed. It used to only send newly added assignees an email. Investigating...Not sure yet when this changed. It used to only send newly added assignees an email. Investigating...https://lab.civicrm.org/dev/core/-/issues/2072Why does composer.json contain `"include-path": ["vendor/tecnickcom"]`2023-05-10T12:51:31ZDaveDWhy does composer.json contain `"include-path": ["vendor/tecnickcom"]`As per https://lab.civicrm.org/extensions/cdntaxreceipts/-/issues/110#note_47514 it seems to cause issues with extensions that try to use TCPDF in drupal 8 since composer creates a vendor/composer/include_paths.php file that then makes t...As per https://lab.civicrm.org/extensions/cdntaxreceipts/-/issues/110#note_47514 it seems to cause issues with extensions that try to use TCPDF in drupal 8 since composer creates a vendor/composer/include_paths.php file that then makes the path relative to /vendor/civicrm/civicrm-core, instead of relative to just /vendor.
Maybe the line was from an early iteration of autoloading and using composer?https://lab.civicrm.org/dev/core/-/issues/2048Rename crmStripAlternatives function and its friend CRM_Utils_String::stripAl...2023-05-05T14:13:30ZDaveDRename crmStripAlternatives function and its friend CRM_Utils_String::stripAlternativesIt's not used much at least in core, and it's not clear from the name what it does, and there's potential for it to be mistaken as a security function.
I'd suggest something like getFirstEmailMultipart or stripAlternativeEmailMultiparts.It's not used much at least in core, and it's not clear from the name what it does, and there's potential for it to be mistaken as a security function.
I'd suggest something like getFirstEmailMultipart or stripAlternativeEmailMultiparts.https://lab.civicrm.org/dev/core/-/issues/2021Contribution receipt has donor's name printed twice, once with non-printable ...2023-11-23T07:22:03ZBobSContribution receipt has donor's name printed twice, once with non-printable charactersOverview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
...Overview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
Jane Mary Smith <$first . \x20 . $middle . \x20 . $last>
123 Main St
...
```
The two \x01 characters (ASCII SOH, CRM_Core_DAO::VALUE_SEPARATOR) are displayed as boxes in some email clients, although they aren't displayable in this bug report.
The message template "Contributions - Receipt (on-line)" includes:
```
{if $billingName}
<tr>
<th {$headerStyle}>
{ts}Billing Name and Address{/ts}
</th>
</tr>
<tr>
<td colspan="2" {$valueStyle}>
{$billingName}<br />
{$address|nl2br}<br />
{$email}
</td>
</tr>
{elseif $email}
```
For Stripe contributions, $billingName contains the first/middle/last names separated by SOH characters, as found in civicrm_address.name. The {if $billingName} block therefore gets printed, including both $billingName and the $address variable which contains the second instance of the donor's name, followed by their address.
The SOH characters in the first line of $address (the donor's name) are replaced with spaces in CRM_Core_BAO_Address::addDisplay().
Contributions via Paypal standard, in contrast, do not display the $billingName block as addresses created that way store NULL in civicrm_address.name.
Reproduction steps
----------------------------------------
1. Create a contribution with CiviCRM Stripe extension v. 6.4.2.
1. Observe the Billing Name and Address section of the emailed receipt.
Current behaviour
----------------------------------------
The donor's name is printed twice. Once with SOH separators, and again with spaces. If the middle name is blank, the second instance contains two spaces between first and last name.
Expected behaviour
----------------------------------------
The name should be printed once, with a single space between non-blank name components.
Additional comments
----------------------------------------
1. Perhaps the fix is to simply remove "$billingName\<br \/\>" from the template(s). Ideally, the double spaces in the case of a null middle name should be corrected also.
2. Event and Membership templates seem to have the same structure as the template shown above.
3. The Thank You page displays the donor's name as expected -- only once, with a single \x20 character between first and last name.
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. -->
* __CiviCRM:__ 5.28.2
* __CiviCRM Stripe extension__ v. 6.4.2
* __mjwshared extension__ v. 0.8.1
* __PHP:__ 7.3
* __CMS:__ Drupal 7.72https://lab.civicrm.org/dev/core/-/issues/1984Sometimes Custom fields missing on profile2023-06-05T20:22:11ZPradeep Nayakpradpnayak@gmail.comSometimes Custom fields missing on profileCustom fields are not rendered on profile front end pages like contribution or event pages. As soon as civi cache is cleared they start appearing.
```
Php - 7.3
opcahe disabled
Clean-up Temporary Data and Files schedule job executed hou...Custom fields are not rendered on profile front end pages like contribution or event pages. As soon as civi cache is cleared they start appearing.
```
Php - 7.3
opcahe disabled
Clean-up Temporary Data and Files schedule job executed hourly by cron job
```