Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-11-11T08:00:35Zhttps://lab.civicrm.org/dev/financial/-/issues/212Why does lineitem.financial_type_id have a db constraint ON DELETE SET NULL2022-11-11T08:00:35ZDaveDWhy does lineitem.financial_type_id have a db constraint ON DELETE SET NULLThe UI won't let you delete financial types that have records that use them. And I can't see a reason why if somebody were to go into the database and try to delete a financial type that you would want to allow this if it has records tha...The UI won't let you delete financial types that have records that use them. And I can't see a reason why if somebody were to go into the database and try to delete a financial type that you would want to allow this if it has records that use it.
The default action for foreign key constraints is to allow deletion if not in use, prevent it if it is in use, which seems exactly right for this field. To make it explicit can use ON DELETE RESTRICT.https://lab.civicrm.org/dev/release/-/issues/20Configure dependabot to always target the RC2023-02-08T03:11:21ZDaveDConfigure dependabot to always target the RCThis maybe belongs in infra. Not sure.
Dependabot is almost always making security-related PRs. But it does it against master, so we end up manually recreating and then deleting the original, which angers dependabot (not really since it...This maybe belongs in infra. Not sure.
Dependabot is almost always making security-related PRs. But it does it against master, so we end up manually recreating and then deleting the original, which angers dependabot (not really since it's a robot, but it posts a response). There is https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#target-branch, but the civi naming for branches doesn't make it easy to target the RC.
It may be more trouble than it's worth just for this, but branch-naming the RC so that it can be targeted more easily would be useful elsewhere too.https://lab.civicrm.org/dev/core/-/issues/3983SearchKit: Exports should include tags2023-10-07T21:13:16ZlarsssandergreenSearchKit: Exports should include tagsMinor issue, but would make sense to also export the tags. Perhaps a complicating factor would be if the Search was imported to a site that didn't have the tag, not sure if we'd have to support adding it in that case.Minor issue, but would make sense to also export the tags. Perhaps a complicating factor would be if the Search was imported to a site that didn't have the tag, not sure if we'd have to support adding it in that case.https://lab.civicrm.org/dev/core/-/issues/3976Upgrades slow as a result of snapshot code2022-11-10T06:58:52ZeileenUpgrades slow as a result of snapshot codeThe addition of the snapshot code causes queries to run that are slow on a large database - eg. `SELECT COUNT(*) FROM civicrm_contact` - this is for a database update with NO changes to any of the large tables it is doing slow queries on...The addition of the snapshot code causes queries to run that are slow on a large database - eg. `SELECT COUNT(*) FROM civicrm_contact` - this is for a database update with NO changes to any of the large tables it is doing slow queries on.
All the messaging about the snapshot is about how to turn it ON - not about how to stop it from doing it's 'activation test'
Note the test is an arbitrary check on the size of some tables thought to possibly signal a large database - but then it turns it ALL off or ALL on after some slow queries. This means the sorts of updates we would have found this useful on (scheduled reminders) may be unnecessarily de-activated.
@tottenhttps://lab.civicrm.org/dev/core/-/issues/3972SearchKit: allow custom fields to be used in the JOIN conditions (like they'r...2023-03-29T15:54:36ZherbdoolSearchKit: allow custom fields to be used in the JOIN conditions (like they're available in where)As far as I can tell, the custom fields on the entity that is joined are not available for the JOIN conditions. But they are visible in the WHERE.
Here's a scenario: there's a custom field on a contact. Create a new SearchKit with prima...As far as I can tell, the custom fields on the entity that is joined are not available for the JOIN conditions. But they are visible in the WHERE.
Here's a scenario: there's a custom field on a contact. Create a new SearchKit with primary being Address. Then JOIN the Contact. Add a condition for the join and search the contact's custom field. It's not available. Then check for that same custom field in the WHERE - it should be available.
This is useful when using GROUP BY and cannot use the WHERE. And where it would be inconvenient/impossible to add the field as a column and use HAVING. For example, if the added field has a transformation to COUNT then HAVING won't help.https://lab.civicrm.org/dev/core/-/issues/3971SearchKit data segmentation: add Clone and Export actions2022-11-10T07:04:03ZherbdoolSearchKit data segmentation: add Clone and Export actionsCurrently there are Edit and Delete actions. It would be useful to also have Clone and Export actions, just like the main SearchKit tab.Currently there are Edit and Delete actions. It would be useful to also have Clone and Export actions, just like the main SearchKit tab.https://lab.civicrm.org/dev/core/-/issues/3970SearchKit data segmentation: ability to AND/OR conditions per item2022-11-10T16:53:45ZherbdoolSearchKit data segmentation: ability to AND/OR conditions per itemI'm guessing that the conditions are currently AND. I have a use case for needing an OR if this is possible.
For example, a field either has a specific string OR that same field is blank.I'm guessing that the conditions are currently AND. I have a use case for needing an OR if this is possible.
For example, a field either has a specific string OR that same field is blank.https://lab.civicrm.org/dev/core/-/issues/3969Notice: Undefined offset: 1 in /var/www/html/civicirm/wp-content/plugins/civi...2023-01-17T02:01:54ZyodatakNotice: Undefined offset: 1 in /var/www/html/civicirm/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 908Overview
----------------------------------------
I got this error showing in civicrm on PHP7.4 and civicrm 5.55.0, Wordpres 6.1 , Nginx
Reproduction steps
----------------------------------------
Go to a report and on top this show
N...Overview
----------------------------------------
I got this error showing in civicrm on PHP7.4 and civicrm 5.55.0, Wordpres 6.1 , Nginx
Reproduction steps
----------------------------------------
Go to a report and on top this show
Notice: Undefined offset: 1 in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 908https://lab.civicrm.org/dev/core/-/issues/3966Contact ID, External ID and CRM User ID should only be shown once on the cont...2022-11-10T07:07:58ZlarsssandergreenContact ID, External ID and CRM User ID should only be shown once on the contact pageCurrently, out of the box, Contact ID and External ID are shown both in the Contact footer, which is visible on all Contact tabs and in the ID, Type, Tags block which is shown on the Contact Summary tab. [A PR](https://github.com/civicrm...Currently, out of the box, Contact ID and External ID are shown both in the Contact footer, which is visible on all Contact tabs and in the ID, Type, Tags block which is shown on the Contact Summary tab. [A PR](https://github.com/civicrm/civicrm-core/pull/24883) will add CRM User ID to the footer as well.
![image](/uploads/4aa3cf01bb4ed418a9c8aaae4ee30dd5/image.png)
I think we should not be duplicating this data on the Contact page. Either it should be shown in a block or it should be shown in the footer, but not both by default as that just wastes space and contributes to an overly busy UI that discourages adoption of CiviCRM.
I think it makes sense to separate the Tags block from the IDs and Contact Type block, as these are very different pieces of data and some may want to see one and not the other.
Some options:
1) Show Contact ID, CRM User ID, External ID and Contact Type in the footer. Remove the Summary tab block with these items, leaving just the Tags block. Or, if we want to give people the option to show the IDs and Contact Type as a block, keep it available, but not visible by default (like the Open ID block, which still exists, but isn't shown by default on new installs). The downside of showing this data in the footer is it is not configurable like the blocks are. The advantage is that the footer is less prominent than a block, which fits with the lower importance of this data, and the footer is visible on all Contact tabs, not just the Summary.
2) Remove all of these items from the footer and only show them in a block.
3) Make the footer only visible to those with Administer CiviCRM permission (as a convenience for admins) and also show the IDs in a block for everyone.
4) Keep everything as is, there are good reasons to duplicate this information.https://lab.civicrm.org/dev/core/-/issues/3964Activity import: source_record_id field not importable2022-12-12T16:43:41ZSandor SemseyActivity import: source_record_id field not importableOverview
---
During activity import (**Contacts >> Import Activities**) Source Record ID field cannot be mapped and imported. In my understanding that is because this field is not marked as importable. If I add the `import => TRUE` to th...Overview
---
During activity import (**Contacts >> Import Activities**) Source Record ID field cannot be mapped and imported. In my understanding that is because this field is not marked as importable. If I add the `import => TRUE` to the relevant DAO, `source_record_id` can be mapped and imported successfully.
I haven't found any references except for this unresolved StackExchange question (https://civicrm.stackexchange.com/questions/33639/importing-signatures-into-petition) and a related issue (https://lab.civicrm.org/dev/core/-/issues/1380) where the OP wants to import petition signatures into Civi.
I checked the oldest available version of Civi on GitHub and this field wasn't marked as importable even then. So this seems quite historical.
I wonder, is there any reasons why this field can't be imported?
Example use-case
---
Importing petition signatures from other systems to CiviCRM.
Current behaviour
---
Not possible to import `source_record_id` for activities.
Proposed behaviour
---
Possible to import `source_record_id` for activities.
Comments
---
I'm happy to open a PR if it gets approved.https://lab.civicrm.org/dev/core/-/issues/3961Proposal: Create stub extensions for civicrm core + all components2023-07-13T10:41:05ZcolemanwProposal: Create stub extensions for civicrm core + all components*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so i...*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so is no longer relevant to this issue.
**Motivation 2**
We are starting to package SearchKit displays as replacements for Smarty/DataTables in the UI. This has worked out great for CiviGrant: now that it's an extension we can easily package Afforms, SavedSearches and other managed entities with it. But other components are not extensions and so have no mechanism for including their own managed entities, afforms, etc. Components are less modular and more monolithic than extensions.
**Motivation 3**
Currently an extension has no way to require a component, e.g. an extension cannot declare a dependency on CiviEvent.
**Motivation 4**
Extensions and Components are similar but not the same, and this is confusing to new users and new developers. In most respects Extensions are better than Components, and it would be great to "some day" have all components simply be extensions.
**Proposal**
Given the experience of converting CiviGrant to an extension was a "harder than expected" undertaking, I think converting all other components to extensions at once is not a realistic goal. It would need to be a slow, iterative process, and I propose this as the first iteration:
1. Create a small stub extension for each component (CiviEvent, CiviContribute, etc).
2. Use hooks to sync between the `civicrm_extension` table and the `civicrm_component` table, so that enabling the "CiviEvent" extension also enables the "CiviEvent" component, and vice-versa.
3. Get rid of the "Manage Components" screen. Admins can enable/disable components via the "Manage Extensions" screen.https://lab.civicrm.org/dev/core/-/issues/3959Event Scheduled Reminder Behavior2022-11-10T07:20:20ZLKuttnerEvent Scheduled Reminder BehaviorI am wondering if this behavior has been changed-- I did not see any online mention of a change with Scheduled Reminders.
Scenario: A schedule event reminder was set for 24 hours before the event start time 4:00 PM Tuesday.
On Monday at...I am wondering if this behavior has been changed-- I did not see any online mention of a change with Scheduled Reminders.
Scenario: A schedule event reminder was set for 24 hours before the event start time 4:00 PM Tuesday.
On Monday at 4:00 PM, 24 Hours before the event, the reminder is successfully sent to registered attendees.
On Tuesday, the day of the event, additional contacts register.
Expected behavior: The scheduled reminder that was sent on the previous day is NOT sent to new registrants.
Experienced behavior: The reminder scheduled for the previous day is sent ten minutes after a new contact registered.
I do not find any explanation for the later sent reminder emails.
This is with CiviCRM 5.45.7 on Drupal 7 with PHP 7.3.29https://lab.civicrm.org/dev/financial/-/issues/211Sending receipt auto when editing a payment (editing financial trx payment)2023-01-18T20:26:40Zlevi.kSending receipt auto when editing a payment (editing financial trx payment)@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial...@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial type on the contribution eventhough it effects a plus and minus transaction (when the account is different))
3. The system will then send a unwanted email receipt (think its using the payment receipt (not contribution receipt)
Drupal 7
civicrm 5.53.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3958PHP 8.2 deprecations2024-01-11T18:55:35ZseamusleePHP 8.2 deprecationsThis is to be a catch all issue for working on PHP8.2 issues
@bradleyt had already created the following issues for some specific PHP8.2 issues
* [Dynamic Properties are Deprecated](https://lab.civicrm.org/dev/core/-/issues/3833)
* [De...This is to be a catch all issue for working on PHP8.2 issues
@bradleyt had already created the following issues for some specific PHP8.2 issues
* [Dynamic Properties are Deprecated](https://lab.civicrm.org/dev/core/-/issues/3833)
* [Deprecated ${} string interpolation](https://lab.civicrm.org/dev/core/-/issues/3831)
* [utf8_encode and utf8_decode functions deprecated](https://lab.civicrm.org/dev/core/-/issues/3832)
There are probably others out there but adding this to help us navigate to the various sub issueshttps://lab.civicrm.org/dev/core/-/issues/3955Add show spaces remaining setting for price set fields2023-05-30T22:23:49ZlarsssandergreenAdd show spaces remaining setting for price set fieldsWith multiple participant registrations and price set options with registration limits, the fact that registrants can't see how many spaces are remaining in a specific option can cause a lot of frustration. What happens is Bob wants to r...With multiple participant registrations and price set options with registration limits, the fact that registrants can't see how many spaces are remaining in a specific option can cause a lot of frustration. What happens is Bob wants to register his family of four for a workshop that only has space remaining for three people. He fills out his details, selects the workshop, fills out his 2nd and 3rd family members' details and selects the workshop for them and only when he arrives on the 4th family members' registration page does he find out there aren't actually enough spaces in the workshop for his family. So he goes back to the start, changes the workshop to another one for each family member one by one, only to find out that the substitute workshop only has space for two... Cue frustration and annoyed emails or, even worse, Bob gives up and doesn't register at all.
To prevent this issue, I propose to add an option to price fields called "Show spaces remaining", which would only be shown when the price set is used for event registration. When this is enabled, each price option will include "(N left)" at the end of the option label, where the (Sold out) text would go, e.g. Identifying pinecones - $ 5.00 (4 left). Of course, this won't be shown for sold out options or options with no limit.
On the backend only, this will also be shown for oversubscribed options (N over limit), replacing (Sold out).
With the recent work I've done to simplify the process of building the [price set option labels](https://github.com/civicrm/civicrm-core/pull/24639), this will be much more easily accomplished.https://lab.civicrm.org/dev/wordpress/-/issues/133WPML URL Integration for CiviCRM2024-02-19T18:33:21ZshaneonabikeWPML URL Integration for CiviCRM## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or oth...## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or other page.
This isn't ideal and confusing for most users as they attempt to navigate to the translated CiviCRM page.
There is already integration for Polylang, but not integration presently for WPML.
WPML handles URLs in three different ways:
+ Attaching a language parameter to the end of the url ```lang=xyz```
+ Attaching a language in the path of the url ```https://test.dev/fr/civicrm/event/info/?reset=1&id=1```
+ Allowing for different domains for each language ```https://fr.test.dev/civicrm/event/info/?reset=1&id=1```
## Before
Viewing the page ```https://test.dev/civicrm/event/info/?reset=1&id=1```, and clicking on the WPML language link will take you to ```https://test.dev/civicrm/```
## After
The new code (I will attach the PR to this ticket shortly) will provide the proper integration for the defined scenarios above.
## Testing
I have tested this in the following scenarios, but maybe others want to test a bit larger?
+ Multiple domains while viewing (Events page)
+ Language placed in the URL (Events page)
+ Language within the proper path
+ Multisite installation with one site using WPML and CiviCRM Events
I don't believe that the path construction is any different for Contribution and other CiviCRM public pages, but I could be wrong.https://lab.civicrm.org/dev/core/-/issues/3948Oauth authentication against MS Exchange IMAP fails since basic authenticatio...2023-03-11T13:16:37ZspalmstromOauth authentication against MS Exchange IMAP fails since basic authentication blockedOverview
----------------------------------------
----------------------------------------
Bounce processing using Oauth to authenticate against MS Exchange fails since Microsoft blocked basic authentication against IMAP.
Reproduction ...Overview
----------------------------------------
----------------------------------------
Bounce processing using Oauth to authenticate against MS Exchange fails since Microsoft blocked basic authentication against IMAP.
Reproduction steps
----------------------------------------
1. Set up an Azure AD application to allow CiviCRM to check bounce processing against MS Exchange
1. Configure Oauth to use it.
1. Create a Mail account for bounce processing.
1. Save and Test fails.
Current behaviour
----------------------------------------
```
An error occured while sending or receiving mail. The IMAP server did not accept the username and/or password: A0001 NO LOGIN failed.. (See log for more details.)
```
Expected behaviour
----------------------------------------
Success.
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. -->
* __Browser:__ _MS Edge_ but probably irrelevant.
* __CiviCRM:__ _5.54.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4__ but probably irrelevant.
* __CMS:__ _Drupal 9.4.8_ but probably not relevant
* __Database:__ _MySQL 8.31_ but probably not relevant
* __Web Server:__ _IIS 10_ but probably not relevant.
Comments
----------------------------------------
Oauth scopes:
```
https://outlook.office.com/IMAP.AccessAsUser.All
https://outlook.office.com/POP.AccessAsUser.All
https://outlook.office.com/SMTP.Send
https://outlook.office.com/User.Read
```
Azure AD App permissions:
```
Microsoft Graph (12)
email Delegated
IMAP.AccessAsUser.All Delegated
Mail.Read Application
Mail.ReadBasi Application
Mail.ReadBasic.All Application
Mail.ReadWrite Application
Mail.Send Application
offline_access Delegated
openid Delegated
POP.AccessAsUser.All Delegated
SMTP.Send Delegated
User.Read Delegated
```
My suspicion is that the extension _never_ worked properly but instead the mail account was using basic authentication so it wasn't an issue. So, when basic authentication was disabled, the application stopped working. Has anyone else seen this issue?https://lab.civicrm.org/dev/core/-/issues/3947FormBuilder: Dropdown does not search exact participant role2022-10-27T16:12:37ZfastermannSGBFormBuilder: Dropdown does not search exact participant roleI built a form using SearchKit and FormBuilder (5.54.0) for a list of participants of an event. Columns are First Name, Last Name, Status, Role and some other.
We have several roles, one is "Mitarbeiter/in" (meaning staff). It has the ID...I built a form using SearchKit and FormBuilder (5.54.0) for a list of participants of an event. Columns are First Name, Last Name, Status, Role and some other.
We have several roles, one is "Mitarbeiter/in" (meaning staff). It has the ID 6. And one is "Ehrengast" (meaning honored guest) with the ID 16.
When I select "Mitarbeiter/in" from the drop down, the results present both - staff and honored guests.
The same problem occurs when I select a role with the ID 3 - it shows participants with ID 3 and 13. And when I select the role with ID 1, it shows also 11, 12, 13, 14 ...
It seems, searchkit is not searching for exact matches but for equals or something like that. Sounds strange, I know...
![Screenshot_2022-10-27](/uploads/1fa2a8661f3f566eac3972a9320fc73b/Screenshot_2022-10-27.png)colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3946Improve default email greeting template2022-11-02T00:38:44ZeileenImprove default email greeting templateThe default greeting template that ships with Core is `Dear {contact.first_name}`
For contacts with no first name it looks like this
![image](/uploads/5484e666daa2e9eabb452b7dfb139704/image.png)
I propose changing it to `Dear {if '{...The default greeting template that ships with Core is `Dear {contact.first_name}`
For contacts with no first name it looks like this
![image](/uploads/5484e666daa2e9eabb452b7dfb139704/image.png)
I propose changing it to `Dear {if '{contact.first_name}'}{contact.first_name}{else}Supporter{/if}`
Which winds up like
![image](/uploads/35017aef6768ebc972b66b003e92bf0c/image.png)
Notes
- this is an English only change - but presumably non-English sites will see no change since there is either a customised version they are getting already or they are already getting the inappropriate 'Dear' & hence not using it
- the choice of word 'Supporter' - could be argued (Donor, Friend etc) - but I think if there is 'something' there then it will allow people to pick their own
- in workflow messages we currently use the field in this way
` {assign var="greeting" value="{contact.email_greeting_display}"}{if $greeting}<p>{$greeting},</p>{/if}` - would would result in the offensive 'Dear,'
- We already parse the greetings through Smarty so no change required there & because we use the `parseOneOffStringThroughSmarty` function smarty runs with higher security https://github.com/civicrm/civicrm-core/blob/95649f7c98ae3c384553f9958ebaf9caa03eb4a6/CRM/Core/Smarty.php#L183-L187
![image](/uploads/0d725992033a68ec25728e0e7e1e8814/image.png)
- The outstanding question is the impact on performance - which is what I will be testing next...https://lab.civicrm.org/dev/core/-/issues/3945SearchKit - make reordering columns easier2022-10-26T18:51:05ZsamuelsovSearchKit - make reordering columns easierIn SearchKit, more and more options are made available for fields. This is a good thing but it becomes more difficult to reorder the fields using drag & drop if the fields definition takes most of the screen :
(totally fake example but ...In SearchKit, more and more options are made available for fields. This is a good thing but it becomes more difficult to reorder the fields using drag & drop if the fields definition takes most of the screen :
(totally fake example but I have some real examples that takes a lot of space)
![Screenshot_2022-10-26_at_09-37-38_Contacts_CRM_de_la_Coop_SymbioTIC](/uploads/7a66a72c0fab195450bd0dd04940331c/Screenshot_2022-10-26_at_09-37-38_Contacts_CRM_de_la_Coop_SymbioTIC.png)
I can imagine 2 options to improve this :
1. have the content of the fields definition be a collapsible and add [collapse all] / [open all] buttons
1. make the ordering separate from the columns definitions, i.e. something like :
![Screenshot_2022-10-26_at_09-24-56_Contacts_CRM_de_la_Coop_SymbioTIC](/uploads/3d1a3692bd7cde1db996bea55fe80554/Screenshot_2022-10-26_at_09-24-56_Contacts_CRM_de_la_Coop_SymbioTIC.png)