CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-11-23T07:09:32Zhttps://lab.civicrm.org/dev/core/-/issues/2414Deductible value treated as non-deductible if a non-deductible selection made...2023-11-23T07:09:32Zfreeform.stephDeductible value treated as non-deductible if a non-deductible selection made in the same contributionOriginally reported here: https://civicrm.stackexchange.com/questions/35284/non-deductible-value-incorrect-if-you-choose-a-nondeductible-membership-type-and
Possibly related to: https://lab.civicrm.org/dev/core/-/issues/1083
If you add...Originally reported here: https://civicrm.stackexchange.com/questions/35284/non-deductible-value-incorrect-if-you-choose-a-nondeductible-membership-type-and
Possibly related to: https://lab.civicrm.org/dev/core/-/issues/1083
If you add a donation field (financial type 'donation' which is deductible) to a membership price set that includes membership types that are nondeductible, and then use that price set for a membership contribution form, the non-deductible value on the contribution is saved as membership fee + donation amount instead of just the membership fee portion of the contribution. This means the non-deductible value can not be trusted.
We use the CDN Tax Receipts extension so to get around the issue we wiped out the nondeductible value from all relevant contributions and let the extension + a custom extension calculate the correct values.
How to replicate:
- add a test organization and test individual
- create a non-deductible financial type and a deductible financial type
- create 2 new membership types for your test organization with a fee and set one to the deductible type, and one to the non-deductible type
- create a price set with 2 fields:
- radio option with the 2 membership types
- radio option with a couple of donation values to choose from, financial type 'donation'
- create a new contribution form, default financial type your custom deductible financial type, and enable your price set on the memberships tab
- now use your new form to create a membership for your test individual and make sure to select the nondeductible membership type & a donation value.
- go to the individual's profile and pull-up the contribution on the contributions tab
To me, it would make sense if the non-deductible value included the donation amount if the contribution status were anything other than 'complete' (pending check for example, because we wouldn't want to issue a tax receipt for monies not receive), but once that status is set to complete then the nondeductible value should respect the financial types of the individual line items.![3X9oo](/uploads/71f07a5b7390c453e28a7ba9f94c54b6/3X9oo.png)seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/2435Save fields button on export screen is not permissioned2023-05-24T06:21:51ZandyburnsSave fields button on export screen is not permissionedI cannot find in the code where the _Save Fields_ button is and therefore what permission is needed to save export mappings.
![image](/uploads/e9be7ed19215554edc7e6397dde46518/image.png)
Currently there is no core permission on who ca...I cannot find in the code where the _Save Fields_ button is and therefore what permission is needed to save export mappings.
![image](/uploads/e9be7ed19215554edc7e6397dde46518/image.png)
Currently there is no core permission on who can export. There is [this extension](https://github.com/progressivetech/net.ourpowerbase.exportpermission/blob/master/README.md) that hides the seach action of export but does not effect the actual export mappings screen.
Currently, non-admins try to save a field mapping and it just spins causing user confusion. What permission is currently needed to save field mappings? I think the logical solution is to get a permission added on saving field mappings button so users that don't have that permission do not see it.https://lab.civicrm.org/dev/core/-/issues/3218CSV exports does not respect localization configuration2023-10-19T14:38:19ZmarcusmCSV exports does not respect localization configurationWhen creating CSV exports from searches the e. g. money or date fields are not exported with the configured localization formats.
Configure language: German, decimal separator: ",", thousands sep.: "."
The export looks like this:
```...When creating CSV exports from searches the e. g. money or date fields are not exported with the configured localization formats.
Configure language: German, decimal separator: ",", thousands sep.: "."
The export looks like this:
```
| Nettobetrag |
|-------------|
| 135.00 |
| 20.00 |
| 50.00 |
| 1,130.00 |
should be
| Nettobetrag |
|-------------|
| 135,00 |
| 20,00 |
| 50,00 |
| 1.130,00 |
```
and an example for a date field:
```
| Geburtsdatum |
|--------------|
| 1942-05-02 |
| 1983-06-01 |
should be
| Geburtsdatum |
|--------------|
| 02.05.1942 |
| 01.06.1983 |
```
The export was created with a contribution search.https://lab.civicrm.org/dev/core/-/issues/2467[Meta] XLTS Angular JS longer-term-support2022-12-20T18:24:57Zhomotechsual[Meta] XLTS Angular JS longer-term-support@JoeMurray raised in chat that [AngularJS goes EoL in December](https://chat.civicrm.org/civicrm/pl/cm6jqmcex3n39ekf3zzx4tiree) there is a company [XLTS](https://xlts.dev/angularjs) providing extended LTS support through 2026. I've send ...@JoeMurray raised in chat that [AngularJS goes EoL in December](https://chat.civicrm.org/civicrm/pl/cm6jqmcex3n39ekf3zzx4tiree) there is a company [XLTS](https://xlts.dev/angularjs) providing extended LTS support through 2026. I've send them an enquiry asking how much they are likely to look to charge given the open-source nature of CiviCRM to see if, perhaps, they'd be willing to "donate" the XLTS to us.
We lose nothing by asking!JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/2469Export of custom multiple choice options to CSV files limited to 32 characters2023-07-18T16:44:17ZbkeevilExport of custom multiple choice options to CSV files limited to 32 charactersA user is trying to export data from an advanced query on custom fields to a CSV file using the "Export contacts" action. This fails with a backtrace which is attached below. The error message is:
```
#6 /var/www/libertarian/vendor/pear...A user is trying to export data from an advanced query on custom fields to a CSV file using the "Export contacts" action. This fails with a backtrace which is attached below. The error message is:
```
#6 /var/www/libertarian/vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-1, NULL, NULL, "\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...", "1406 ** Data too long for column 'custom_49' at row 13")
```
The `custom_49` field referred to in the error is a select list with a set of multiple choice options, some of which are up to 55 characters long.
The bug is that the temporary table that is being constructed to service the export to CSV is constructing the column as VARCHAR(32) while the text value of the multiple choice options in civicrm_option_value is a VARCHAR(512)
### Details
If I select the schema of the table `civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7` it reports the table structure as:
```
CREATE TABLE `civicrm_tmp_d_export_c3a74c8fb66b720f55e2661dab58716b` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`last_name` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL,
`first_name` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL,
`nick_name` varchar(128) COLLATE utf8_unicode_ci DEFAULT NULL,
`street_address` varchar(96) COLLATE utf8_unicode_ci DEFAULT NULL,
`city` varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL,
`email` varchar(254) COLLATE utf8_unicode_ci DEFAULT NULL,
`phone` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`sort_name` varchar(128) COLLATE utf8_unicode_ci DEFAULT NULL,
`custom_61` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`custom_50` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`custom_51` varchar(16) COLLATE utf8_unicode_ci DEFAULT NULL,
`custom_68` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
`custom_58` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`custom_49` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `index_street_address` (`street_address`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
```
Indeed it is trying to insert the text value of an option into a temporary table and several of those text options are over 32 characters in length.
```
SELECT label,CHAR_LENGTH(label) as length FROM civicrm.civicrm_option_value WHERE (option_group_id=103) AND (CHAR_LENGTH(label) > 32)
```
returns
```
| label | length |
|---------------------------------------------------------|--------|
| 003 - Aurora–Oak Ridges–Richmond Hill | 37 |
| 005 - Barrie–Springwater–Oro-Medonte | 36 |
| 035 - Haliburton–Kawartha Lakes–Brock | 37 |
| 039 - Hamilton West–Ancaster–Dundas | 35 |
| 040 - Hastings–Lennox and Addington | 35 |
| 052 - Leeds–Grenville–Thousand Islands and Rideau Lakes | 55 |
| 061 - Mississauga East–Cooksville | 33 |
| 073 - Northumberland–Peterborough South | 39 |
| 102 - Stormont–Dundas–South Glengarry | 37 |
```
The full backtrace may be relevant:
```
backTrace
#0 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/Error.php(148): CRM_Core_Error::backtrace()
#1 /var/www/libertarian/vendor/pear/pear-core-minimal/src/PEAR.php(944): CRM_Core_Error::handle(Object(DB_Error))
#2 /var/www/libertarian/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...")
#3 /var/www/libertarian/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...")
#4 /var/www/libertarian/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_1d387c75256673080ad64346b3c095c7 (`id`, `l...", "DB_Error", TRUE)
#5 /var/www/libertarian/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#6 /var/www/libertarian/vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-1, NULL, NULL, "\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...", "1406 ** Data too long for column 'custom_49' at row 13")
#7 /var/www/libertarian/vendor/pear/db/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
#8 /var/www/libertarian/vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...")
#9 /var/www/libertarian/vendor/civicrm/civicrm-packages/DB/DataObject.php(2696): DB_common->query("\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...")
#10 /var/www/libertarian/vendor/civicrm/civicrm-packages/DB/DataObject.php(1829): DB_DataObject->_query("\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...")
#11 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(457): DB_DataObject->query("\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...")
#12 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(1563): CRM_Core_DAO->query("\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...", TRUE)
#13 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Export/BAO/Export.php(365): CRM_Core_DAO::executeQuery("\nINSERT INTO civicrm_tmp_d_export_1d387c75256673080ad64346b3c095c7 (`id`, `l...")
#14 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Export/BAO/Export.php(199): CRM_Export_BAO_Export::writeDetailsToTable(Object(CRM_Export_BAO_ExportProcessor), (Array:100), (Array:14))
#15 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Export/Form/Map.php(142): CRM_Export_BAO_Export::exportComponents(TRUE, (Array:118), (Array:8), "`sort_name` asc", (Array:14), NULL, 1, " contact_a.id IN ( 1546,1415,641,27,1688,1504,1701,42,650,626,56,1509,1537,15...", "civicrm_contact", 0, 0, (Array:11), "AND")
#16 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/Form.php(513): CRM_Export_Form_Map->postProcess()
#17 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/StateMachine.php(144): CRM_Core_Form->mainProcess()
#18 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Next.php(43): CRM_Core_StateMachine->perform(Object(CRM_Contact_Export_Form_Map), "next", "Next")
#19 /var/www/libertarian/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Contact_Export_Form_Map), "next")
#20 /var/www/libertarian/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Export_Form_Map), "next")
#21 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(347): HTML_QuickForm_Page->handle("next")
#22 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(312): CRM_Core_Controller->run((Array:4), (Array:0))
#23 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:13))
#24 /var/www/libertarian/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:4))
#25 /var/www/libertarian/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke((Array:4))
#26 /var/www/libertarian/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke((Array:4))
#27 [internal function](): Drupal\civicrm\Controller\CivicrmController->main((Array:4), "")
#28 /var/www/libertarian/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array((Array:2), (Array:2))
#29 /var/www/libertarian/web/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#30 /var/www/libertarian/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#31 /var/www/libertarian/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext((Array:2), (Array:2))
#32 /var/www/libertarian/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#33 /var/www/libertarian/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#34 /var/www/libertarian/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#35 /var/www/libertarian/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#36 /var/www/libertarian/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#37 /var/www/libertarian/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#38 /var/www/libertarian/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#39 /var/www/libertarian/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#40 /var/www/libertarian/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#41 /var/www/libertarian/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#42 /var/www/libertarian/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#43 {main}
```https://lab.civicrm.org/dev/core/-/issues/2481Discussion drop support for php 7.2 and mysql 5.62023-01-04T18:01:36ZeileenDiscussion drop support for php 7.2 and mysql 5.6We have been dropping support for EOL php & mysql on ESR releases because that gives sites the option of delaying for another 6 months for just $120. So far we are not aware of any sites opting for the ESR for that reason but we are crea...We have been dropping support for EOL php & mysql on ESR releases because that gives sites the option of delaying for another 6 months for just $120. So far we are not aware of any sites opting for the ESR for that reason but we are creating the option.
With 5.39 coming up we should consider whether we want to drop support for
php 7.2 (EOL Dec 2020)
mysql 5.6 (EOL Feb 2021)
Note that historically supporting older versions of mysql has been low effort although some features are not supported. However, it might be holding us back from using new features
Supporting older versions of php has historically been more problematic as it has been at the expense of supporting newer versions. In particular we often find packages don't support latest and EOL versions.
So dropping support for older php versions is more helpful than older mysql versions.
Last ESR we considered dropping support for php 7.1 and mysql 5.6. We did the former and not the latter. At the time the stats were:
mysql 5.6 : 805
php 7.1 : 658.
Maria DB 10.1 : 943
Currently they are
mysql 5.6 : 603
php 7.2 : 2846
Maria DB 10.1 : 526
Based on those numbers I think it's clearly too early for php 7.2 and I would be OK targetting both for the NEXT ESR (5.45)https://lab.civicrm.org/dev/core/-/issues/2484Create apiv4 payment api2023-07-13T08:07:37ZeileenCreate apiv4 payment apiIn order to be able to search for payments we need to be able to search for payment rows (rows with is_payment = TRUE) in the financial_trxn table and for the entity bridge to be able to find it's way from there to the contribution table...In order to be able to search for payments we need to be able to search for payment rows (rows with is_payment = TRUE) in the financial_trxn table and for the entity bridge to be able to find it's way from there to the contribution table.
This gives us the ability to say find all contributions with a payment with a payment instrument of 'Check' or find the contribution where the payment's trxn value is y
The scope I would be looking for is
1) can use any of the fields in financial_trxn as a filter
2) can logically link to the contribution (probably through bridge entities)
3) forces 'is_payment' as a filter (only gets payments)
4) the create action calls Payment.create
5) the update & delete actions are blocked
This effectively gives us parity with the v3 api albeit with more options provided through the apiv4 layer itself.
Note that I think this is likely blocked on other feature requests which @mattwire will add notes onhttps://lab.civicrm.org/dev/core/-/issues/2486Apiv4 entity parity2023-10-13T21:11:08ZeileenApiv4 entity parity## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civ...## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civicrm-core/pull/27379) but `create` is still missing
- [ ] Extension.php - various install, uninstall etc functions (support for some actions already implemented)
# Partially done - lets resolve
- [ ] MembershipLog.php https://github.com/civicrm/civicrm-core/pull/21106
# Standard crud - note that doing these involves checking all pseudoconstants are correctly defined
- [ ] SmsProvider.php
- [ ] Premium.php
- [ ] RecurringEntity.php
# Mailing related - in scope
- [ ] MailingAB.php
- [ ] MailingComponent.php
- [ ] MailingContact.php
- [ ] MailingEventResubscribe.php
- [ ] MailingRecipients.php
# From here on down we are out of scope for 'entity parity'
## Order related - needed when we get to afform payment forms - out of scope for entity parity
- [ ] Order.php
- [ ] Payment.php
## Varied utils - out of scope for 'entity parity' - ad hoc
- [ ] SystemLog.php
- [ ] User.php
- [ ] Logging.php
## Migration doubtful - to be done ad hoc if we decide to
- [ ] ReportTemplate.php
- [ ] ParticipantPayment.php - likely should not be brought over
- [ ] CxnApp.php
- [ ] Cxn.php
- [ ] Profile.php
## Do not migrate
- ~~ActivityType.php (by design)~~
- ~~CustomSearch.php (by design)~~
- ~~Constant.php (by design)~~
- ~~SurveyRespondant.php(by design)~~
- ~~MembershipPayment.php (by design - use Line Item)~~
## Done
- [x] ~~AclRole.php~~ ACLEntityRole https://github.com/civicrm/civicrm-core/pull/20474
- [x] Batch.php https://github.com/civicrm/civicrm-core/pull/19931
- [x] CaseContact.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] Case.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] CaseType.php
- [x] ContributionProduct.php https://lab.civicrm.org/dev/core/-/issues/2683
- [x] Dedupe.php
- [x] EntityBatch.php https://lab.civicrm.org/dev/core/-/issues/2682
- [x] EntityFinancialAccount.php - https://github.com/civicrm/civicrm-core/pull/19927
- [x] EntityFinancialTrxn.php - https://github.com/civicrm/civicrm-core/pull/19932
- [x] ~~Exception.php~~ DedupeException.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] File.php (part of attachment) https://github.com/civicrm/civicrm-core/pull/21158
- [x] FinancialItem.php - https://github.com/civicrm/civicrm-core/pull/20433
- [x] Job.php (crud portion)
- [x] Job.php
- [x] JobLog.php
- [x] Mailing.php - there are a bunch of related entities - see further down)
- [x] MailingEventConfirm.php
- [x] MailingEventQueue.php
- [x] MailingEventSubscribe.php
- [x] MailingEventUnsubscribe.php
- [x] MailingGroup.php
- [x] MailingJob.php
- [x] Membership.php - see https://lab.civicrm.org/dev/core/-/issues/2634 https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipBlock.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipStatus.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] ParticipantStatusType.php
- [x] PaymentToken.php
- [x] Pcp.php
- [x] PrintLabel.php https://github.com/civicrm/civicrm-core/pull/21500
- [x] Product.php - since 5.41
- [x] ReportInstance.php
- [x] ~~Rule.php~~ DedupeRule.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] ~~RuleGroup.php~~ DedupeRuleGroup.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] Survey.php https://github.com/civicrm/civicrm-core/pull/21355
- [x] WordReplacement.php https://github.com/civicrm/civicrm-core/pull/20559https://lab.civicrm.org/dev/core/-/issues/2494Search-kit wishlist - exposed join filters2022-11-07T04:17:02ZeileenSearch-kit wishlist - exposed join filtersSo on my effort to get a workable lybunt I find that what I really want is to be able to expose the join filter in the afform -ie
```
SELECT Contacts
WITH contributions > {{{total_amount}}} IN DATE RANGE {{select_date}}
WITHOUT contribu...So on my effort to get a workable lybunt I find that what I really want is to be able to expose the join filter in the afform -ie
```
SELECT Contacts
WITH contributions > {{{total_amount}}} IN DATE RANGE {{select_date}}
WITHOUT contributions IN DATE RANGE {{select_date}}
```
Obviously the other filter issue (https://lab.civicrm.org/dev/core/-/issues/2405) is a prerequisite on thishttps://lab.civicrm.org/dev/core/-/issues/2509Search kit: Links to case (and other) activities go to the wrong form2023-08-01T01:50:48ZDaveDSearch kit: Links to case (and other) activities go to the wrong formIf you do a search either purely on activities and the results happen to include case activities, or a search on cases and include the related contact activities, the links to the activities in the results list go to the regular activity...If you do a search either purely on activities and the results happen to include case activities, or a search on cases and include the related contact activities, the links to the activities in the results list go to the regular activity form not the case activity form. This matters because:
1. It's not all the right fields on the form.
2. Form hooks won't work properly.
3. You get errors on save.
@colemanwhttps://lab.civicrm.org/dev/core/-/issues/2510Search kit: Case search with related contact activities includes deleted acti...2023-07-19T13:26:07ZDaveDSearch kit: Case search with related contact activities includes deleted activities by defaultI don't know if it's so much of a bug as unintuitive since typically deleted things are left out by default and e.g. a plain activity search just on activities alone leaves out deleted ones. So it's something about the join maybe.I don't know if it's so much of a bug as unintuitive since typically deleted things are left out by default and e.g. a plain activity search just on activities alone leaves out deleted ones. So it's something about the join maybe.https://lab.civicrm.org/dev/core/-/issues/2515CiviCRM Membership, inherited membership remains active even when the primary...2022-10-10T11:36:56Zjustinfreeman (Agileware)CiviCRM Membership, inherited membership remains active even when the primary member has been marked as deletedCiviCRM Membership, inherited membership remains active even when the primary member has been marked as deleted. Reproduced on **CiviCRM 5.37.alpha1**. Observed since CiviCRM 5.33.2 and earlier.
Steps to reproduce:
1. Set up a Membershi...CiviCRM Membership, inherited membership remains active even when the primary member has been marked as deleted. Reproduced on **CiviCRM 5.37.alpha1**. Observed since CiviCRM 5.33.2 and earlier.
Steps to reproduce:
1. Set up a Membership Type which can be inherited using the Employer Of relationship, Membership A
2. Create Organisation contact, Org B
3. Assign Membership A to Org B
4. Create Organisation contact, Org C
5. Assign Membership A to Org C
6. Create Employer Of relationship for Individual D, E, F with Org B
7. Note that Individual D, E, F have inherited Membership A from Org B
8. Merge Org B (Duplicate) and Org C (Original)
9. During the Merge action, keep the merge Relationship option enabled. This problem can be replicated with either enable or disable of the Move Related Memberships.
10. The merge action will mark Org B (Duplicate) as deleted
11. Post merge, check Individual D, E, F
12. Note that the Employer Of relationship for Individual D, E, F has been changed to Org C, this is correct.
13. Note that Individual D, E, F still have inherited Membership A from Org B (the deleted contact) - this is incorrect, see below.
The desired result is that Individual D, E, F will have inherited Membership A from Org C. The Relationship has been transferred to Org C which should trigger then membership to be inherited from Org C, not Org B.
Workaround is to restore the deleted Org C from trash and delete the Membership record. Then for each of the Individual contacts, disable and re-enable the Relationship with Org B. This should restore the correct inherited relationship.
Agileware Ref: CIVICRM-906 CIVICRM-1922
Screenshots below of reproduced issue.
* Green Action School DUPLICATE (Org B)
* Green Action School ORIGINAL (Org C)
* The two Individual Contacts show the incorrect inherited membership, associated with the Green Action School DUPLICATE (Org B).
![screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_39_07](/uploads/461820778757e6c6c542d85f8a84d447/screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_39_07.png)
![screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_38_57](/uploads/d852c509295ef4a39c47d879bf2de006/screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_38_57.png)
![screencapture-dmaster-demo-civicrm-org-civicrm-contact-merge-2021-04-07-10_38_49](/uploads/0820651ba28063017d00d58573e33f18/screencapture-dmaster-demo-civicrm-org-civicrm-contact-merge-2021-04-07-10_38_49.png)
![screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_39_34](/uploads/4e5b57757b8982c324fb17a54a286dec/screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_39_34.png)
![screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_39_25](/uploads/d6e7e3074f38b70107188a41d2b7e41b/screencapture-dmaster-demo-civicrm-org-civicrm-contact-view-2021-04-07-10_39_25.png)https://lab.civicrm.org/dev/core/-/issues/2546Add Settings, Disable, Delete buttons to group contacts listing page2023-09-14T15:09:10ZlarsssandergreenAdd Settings, Disable, Delete buttons to group contacts listing pageCurrently, you can only change settings, disable or delete a group from the Manage Groups page. It would make sense to be able to change the settings at least on the page that lists all the contacts in a group (disable and delete are les...Currently, you can only change settings, disable or delete a group from the Manage Groups page. It would make sense to be able to change the settings at least on the page that lists all the contacts in a group (disable and delete are less important, but I think they might as well be added as well). I often find I click into a group when I want to make it a mailing list and then realize I have to go back to the Manage Groups page and click settings.
I think this would make the most sense at the top of the page, maybe right below the "Add Contacts to this group" button or alternately, just above select records. Relatedly, I would also propose to put the "Edit Smart Group Criteria for this group" and "Add Contacts to this group" buttons on the same line, as they are currently on two.
For reference:
![image](/uploads/b7ed25111565401ddf2ae295795f3b8c/image.png)
I'll give this a go if it is supported.https://lab.civicrm.org/dev/core/-/issues/2559Cannot get Auth Code in Oauth2 from Microsoft Azure Application2023-01-10T14:28:11ZspalmstromCannot get Auth Code in Oauth2 from Microsoft Azure ApplicationOverview
----------------------------------------
You cannot get an Auth Code in Oath2 from a single-tenant Microsoft Azure Application because the access token string is
```
https://login.microsoftonline.com/common/oauth2/v2.0/token
``...Overview
----------------------------------------
You cannot get an Auth Code in Oath2 from a single-tenant Microsoft Azure Application because the access token string is
```
https://login.microsoftonline.com/common/oauth2/v2.0/token
```
when it should be:
```
https://login.microsoftonline.com/<tenant ID>/oauth2/v2.0/token
```
Reproduction steps
----------------------------------------
1. Click on Admin -> Oauth2 Administration
1. Select Microsoft Exchange Online
1. Click on Add token and enter an MS account
Current behaviour
----------------------------------------
```
AADSTS50194: Application '226037fb-d13a-4f81-ba32-561601248bea'(MissionAssist Mail) is not configured as a multi-tenant application. Usage of the /common endpoint is not supported for such applications created after '10/15/2018'. Use a tenant-specific endpoint or configure the application to be multi-tenant.
```
Expected behaviour
----------------------------------------
A token should be added.
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:__ _Edge_ but probably not relevant
* __CiviCRM:__ _5.36.1_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4.16__ but probably not relevant
* __CMS:__ _Drupal 9.1.7_ but probably not relevant.
* __Database:__ _MySQL 8.0.24_ but probably not relevant
* __Web Server:__ _IIS_ but probably not relevant.
Comments
----------------------------------------
It would be good if the setup could prompt for the tenant ID>5.59.0https://lab.civicrm.org/dev/core/-/issues/2562Simplify when scheduled reminders are sent or not sent for events2023-08-07T15:14:25ZlarsssandergreenSimplify when scheduled reminders are sent or not sent for eventsFor event scheduled reminders, you can set emails to be sent on specific days or N hours or days before or after an event (or before or after registration ends or starts). For emails sent on a specific day, this is straightforward. They ...For event scheduled reminders, you can set emails to be sent on specific days or N hours or days before or after an event (or before or after registration ends or starts). For emails sent on a specific day, this is straightforward. They are sent on that day and anyone who registers after that day does not receive the email.
But for emails scheduled N hours or days before or after an event, the behaviour is less clear. My testing indicates contacts registered soon after an event has ended can still receive emails scheduled to go out 24 hours before the event start or 30 hours before the event end (but contacts registered somewhat later won't receive these emails). Similarly, contacts registered a day after an event ends will receive an email scheduled to go out an hour after the event start. I can't find any documentation that tells users what will happen when they schedule these reminders, though there are a few questions on Stack Exchange wondering about what actually does happen (opinions vary, which is a bad sign).
I think the clearest and best option would be to simply send scheduled reminders at the time they are scheduled and not afterwards. For one, this is simple and probably what users assume happens. It's certainly what our users think. Secondly, let's say you have an event with a confirmation email, one scheduled reminder a day before the event and one 2 hours before the event: with the current system a person who registers at the last minute will receive three emails in short order, which doesn't make sense. Thirdly, if a user registers someone in the backend for an event after the event has ended, just to record their attendance, they probably don't want that person to automatically receive emails previously scheduled to go out right after the event start or similar (this could be avoided by using a different status for the post-event registration and the scheduled reminder, but that's a pretty fine point that users won't think about).
In short, I think there are so many potential pitfalls with a system that sends scheduled reminders after the time set on the reminder has passed, especially when none of this behaviour is apparent to users when they set up the reminders. To me, this outweighs the potential convenience of having reminders sent to late registrants, so we should simply not send scheduled reminders whose time has passed.
I haven't dug into the code yet to see how this all works, but I'll do that and submit a PR as long as this is supported.
EDIT: removed aside on timing of scheduled reminders.https://lab.civicrm.org/dev/core/-/issues/2565HTML editor for additional event confirmation email text2023-08-02T21:16:19ZlarsssandergreenHTML editor for additional event confirmation email textIt would be nice to be able to have an HTML editor for the additional event confirmation text entered on the Manage Event Page that gets inserted into the System Template email template. The benefit would be to be able to easily add link...It would be nice to be able to have an HTML editor for the additional event confirmation text entered on the Manage Event Page that gets inserted into the System Template email template. The benefit would be to be able to easily add links, etc. I understand this will be a complicated one, but it does seem worthwhile as almost every other similar field is HTML, so this one really stands out. [See previous issue.](https://lab.civicrm.org/dev/core/-/issues/852#note_58464)
How it works now: Text from the event confirmation email text is added into the event confirmation message template with some minimal tags added. I see a <p> wrapper around the text and <br /> inserted for newlines, at a cursory glance.
Here's my guess at what needs to happen:
1. Add HTML editor to Event Configuration
2. Add HTML editor on the New Event Registration page (which is also Add Participant from events or Add Event Registration for a contact), so that the message can be edited before sending.
3. Inject content as HTML into Message Templates, i.e. remove code that adds tags, wrap code in div or something.
4. Convert all existing content in the DB with the same process now taken to inject the text into the Message Template or handle the content injection into the Message Template with two cases based on text/HTML.
The first three should be relatively simple, but the last one there seems like the tricky part. How has this has been handled in the past?https://lab.civicrm.org/dev/core/-/issues/2571Move reCAPTCHA to core extension2022-12-02T09:28:56Zmattwiremjw@mjwconsult.co.ukMove reCAPTCHA to core extensionThis is a tracking issue to track progress.
* https://github.com/civicrm/civicrm-core/pull/19967 - initial extension merged.
* https://github.com/civicrm/civicrm-core/pull/19999 - add recaptcha to distmaker - merged.
* https://github.co...This is a tracking issue to track progress.
* https://github.com/civicrm/civicrm-core/pull/19967 - initial extension merged.
* https://github.com/civicrm/civicrm-core/pull/19999 - add recaptcha to distmaker - merged.
* https://github.com/civicrm/civicrm-core/pull/20011 - move recaptcha library to extension - merged.
* https://github.com/civicrm/civicrm-core/pull/20019 - Use standard function to add reCAPTCHA to PCPAccount form - merged.
Need to cleanup and move all calls to add reCAPTCHA to forms to the extension.https://lab.civicrm.org/dev/core/-/issues/2572Prevent unintentional removal from group for anonymous users filing out profiles2023-09-01T19:44:06ZlarsssandergreenPrevent unintentional removal from group for anonymous users filing out profilesCurrently, if an anonymous contact submits a profile that contains a groups field and the profile submission is deduped on submission with an existing contact, the group selections in the profile overwrite the contact's previous groups, ...Currently, if an anonymous contact submits a profile that contains a groups field and the profile submission is deduped on submission with an existing contact, the group selections in the profile overwrite the contact's previous groups, for the groups that are included in the profile (i.e. the public groups). The result is that if someone is subscribed to a mailing list and fills in a profile anonymously and doesn't check the same group name, they will be unsubscribed from the group. This is definitely not what users expect! I think it's clear that checking the box will add you to the group, but I doubt many expect that they will be removed from a group if they don't check the box that they've checked in the past.
This is also not what happens with other profile fields that are left blank, nor is it what happens if two contacts are merged manually.
I propose to ignore group checkboxes that are not checked in a profile submitted anonymously. No change for profiles submitted with known cids (as these will have the appropriate checkboxes already checked, allowing the contact to unsubscribe by unchecking them if desired). Currently, all group ids in the profile are being [passed here](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Contact/BAO/GroupContact.php#L534), removing the contact from groups that were unchecked. Will submit PR if supported.
EDIT: Here is some discussion on StackExchange: [Unwanted unsubscribe in profile](https://civicrm.stackexchange.com/questions/39403/unwanted-unsubscribe-in-profile/39406), [Anonymous user filing out a profile unintentionally remove themselves from groups](https://civicrm.stackexchange.com/questions/29337/anonymous-user-filing-out-a-profile-unintentionally-remove-themselves-from-group)https://lab.civicrm.org/dev/core/-/issues/3204Add recurring contributions to contribution reports2022-09-16T21:11:08ZlarsssandergreenAdd recurring contributions to contribution reportsIt would be very convenient to be able to do filter by recurring contributions for reports, add recurring contributions as a column or even group by.
[Here's a PR that adds this for the Contribution Summary report.](https://github.com/c...It would be very convenient to be able to do filter by recurring contributions for reports, add recurring contributions as a column or even group by.
[Here's a PR that adds this for the Contribution Summary report.](https://github.com/civicrm/civicrm-core/pull/20168) I will also implement in other relevant reports once this has been reviewed.https://lab.civicrm.org/dev/core/-/issues/2581Cannot add case type in multilingual installation with MariaDB 10.2 strict mode2023-09-02T01:52:37ZhansrosselCannot add case type in multilingual installation with MariaDB 10.2 strict modeWhen adding a new case type via the UI at /en/civicrm/a/#/caseType/new in a multilingual site there is an error
```
"error_message": "DB Error: unknown error",
"mode": 16,
"debug_info": "INSERT INTO `civicrm_case_type_en_US` (`n...When adding a new case type via the UI at /en/civicrm/a/#/caseType/new in a multilingual site there is an error
```
"error_message": "DB Error: unknown error",
"mode": 16,
"debug_info": "INSERT INTO `civicrm_case_type_en_US` (`name` , `is_active` ) VALUES ('ExampleNew' , 1 ) [nativecode=1423 ** Field of view 'sitex.civicrm_case_type_en_US' underlying table doesn't have a default value]",
"type": "DB_Error",
"user_info": "INSERT INTO `civicrm_case_type_en_US` (`name` , `is_active` ) VALUES ('ExampleNew' , 1 ) [nativecode=1423 ** Field of view 'sitex.civicrm_case_type_en_US' underlying table doesn't have a default value]",
"to_string": "[db_error: message=\"DB Error: unknown error\" code=-1 mode=callback callback=CRM_Utils_REST::fatal prefix=\"\" info=\"INSERT INTO `civicrm_case_type_en_US` (`name` , `is_active` ) VALUES ('ExampleNew' , 1 ) [nativecode=1423 ** Field of view 'sitex.civicrm_case_type_en_US' underlying table doesn't have a default value]\"]",
```
Environment information
----------------------------------------
Drupal 7.80 / CiviCRM 5.36.1
MariaDB 10.2 with strict mode
Cause
----------------------------------------
MySQL having a strict mode set which won’t allow INSERT or UPDATE commands with empty fields where the schema doesn’t have a default value set.
Solution
----------------------------------------
I solved it with disabling strict mode by adding sql_mode=NO_ENGINE_SUBSTITUTION to /etc/my.cnf (and restarting mysql). Because the new Case Type was made from /en/civicrm/a/#/caseType/new I got first an empty label, but could after saving change the label to the desired case type human name.
I suppose there could also be a default value defined for these multilingual tables.5.66.0