CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-12-23T16:28:53Zhttps://lab.civicrm.org/dev/core/-/issues/4046Civi incompatible with composer 2.5 (serialization of closure is not allowed)2022-12-23T16:28:53ZDaveDCivi incompatible with composer 2.5 (serialization of closure is not allowed)In https://github.com/composer/composer/commit/39de9899a70d8351db134027dc24ed35fc629346#diff-2f0f90552ea46ccb1d7d485298d70262be6825e776fa8e35de15f2f6c4e3efedR114 they added a closure to composer's classloader.
In civi, it creates a cach...In https://github.com/composer/composer/commit/39de9899a70d8351db134027dc24ed35fc629346#diff-2f0f90552ea46ccb1d7d485298d70262be6825e776fa8e35de15f2f6c4e3efedR114 they added a closure to composer's classloader.
In civi, it creates a cache of the extension classloader (which extends composer's) by serializing it: https://github.com/civicrm/civicrm-core/blob/04edd1c101b3d4982c727aae083f7f92c8440928/CRM/Extension/ClassLoader.php#L85
You can't serialize closures, so it gives an error.
Note to reproduce this when using `cv`, you'll need to build cv from source using composer 2.5, since when using cv it uses its own vendor's copy of the composer classloader, not the one in the civi install's vendor folder. So the one in cv might be an older one if using a phar, and then you won't see the error.https://lab.civicrm.org/dev/core/-/issues/1242SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) supports2022-12-23T05:03:32ZNeustradamusSCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) supports"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
Can you add support for?
- SCRAM..."When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
Can you add support for?
- SCRAM-SHA-1(-PLUS):
-- https://tools.ietf.org/html/rfc5802
-- https://tools.ietf.org/html/rfc6120
- SCRAM-SHA-256(-PLUS):
-- https://tools.ietf.org/html/rfc7677 since 2015-11-02
-- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA
I add SCRAM-SHA-512(-PLUS): https://xmpp.org/extensions/inbox/hash-recommendations.html
Linked to:
- https://github.com/scram-xmpp/info/issues/1https://lab.civicrm.org/dev/core/-/issues/1298Add Email and Phone as Entities that Custom Fields can be assigned to2022-12-23T05:03:31ZguyiacAdd Email and Phone as Entities that Custom Fields can be assigned toPatrick working on this at BCN SprintPatrick working on this at BCN SprintPatrick Figelpfigel@greenpeace.orgPatrick Figelpfigel@greenpeace.orghttps://lab.civicrm.org/dev/core/-/issues/1299Fix Changelog Reports2022-12-22T05:03:22ZguyiacFix Changelog ReportsCorrect anomalies in the change log reporting (for example the representation when of changes made in batch).
Patrick working on at BCN Sprint.Correct anomalies in the change log reporting (for example the representation when of changes made in batch).
Patrick working on at BCN Sprint.Patrick Figelpfigel@greenpeace.orgPatrick Figelpfigel@greenpeace.orghttps://lab.civicrm.org/dev/core/-/issues/1301Find cases issue - export issue2022-12-22T05:03:21ZgibsonoliverFind cases issue - export issueWhen you do a Find cases search>export>select fields for export you can choose related fields. But they don't export
![Capture](/uploads/6e010d1d48a8d990a07f40896bc5d8a4/Capture.PNG)When you do a Find cases search>export>select fields for export you can choose related fields. But they don't export
![Capture](/uploads/6e010d1d48a8d990a07f40896bc5d8a4/Capture.PNG)https://lab.civicrm.org/dev/core/-/issues/4027Crash when viewing contact's contribution tab and a contribution has no line ...2022-12-21T16:04:38ZJonGoldCrash when viewing contact's contribution tab and a contribution has no line itemsContributions are *supposed* to all have line items, but this isn't universally true - in particular, it seems like imported contributions don't all have them. This caused no issues until Civi 5.53, specifically PR [#24142](https://gith...Contributions are *supposed* to all have line items, but this isn't universally true - in particular, it seems like imported contributions don't all have them. This caused no issues until Civi 5.53, specifically PR [#24142](https://github.com/civicrm/civicrm-core/pull/24142).
### Steps to replicate
* Manually delete (in the db) the line item for the "template" contribution for a recurring contribution. I thought that this would be the first contribution in the series, but apparently it's the most recent.
* Attempt to view the contact's contribution tab containing that contribution
### Expected Result
View the contribution tab normally.
### Actual Result
```
PHP Fatal error: Uncaught TypeError: CRM_Financial_BAO_Order::setPriceSetID(): Argument #1 ($priceSetID) must be of type int, null given, called in /home/jon/local/mysite/web/wp-content/plugins/civicrm/civicrm/CRM/Financial/BAO/Order.php on line 841 and defined in /home/jon/local/mysite/web/wp-content/plugins/civicrm/civicrm/CRM/Financial/BAO/Order.php:472"
```5.56.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3460AuthX breaks Contribution Batch functionality (and more)2022-12-21T16:04:08ZJonGoldAuthX breaks Contribution Batch functionality (and more)A number of core CiviCRM pages call the `civicrm/ajax/rest` endpoint. When AuthX is enabled, these functions fail with an "Invalid Credential" error.
### Steps to replicate
* enable AuthX.
* Create a new Contribution Batch (you don't n...A number of core CiviCRM pages call the `civicrm/ajax/rest` endpoint. When AuthX is enabled, these functions fail with an "Invalid Credential" error.
### Steps to replicate
* enable AuthX.
* Create a new Contribution Batch (you don't need to add anything to it).
* Go to **Contributions » Accounting Batches » Open Batches**.
* Select **more » Delete**.
### Expected Result
Batch is deleted (which is what happens when AuthX is disabled)
### Actual Result
"An error occurred while processing your request.". Dev tools show `FATAL: Invalid credential`.
A search of the codebase shows several references to `civicrm/ajax/rest` - mostly in out-of-the-way areas like Premiums or Accounting Batches.
I'm not sure what the correct approach is - my sense from my reading was that @totten had accounted for this, so I'd appreciate his eyes on this. I assume creating a second endpoint that replicates the original behavior defeats the purpose here. I also see that `CRM_Utils_REST::ajax()` has `self::isWebServiceRequest()` which does its own AuthX checking, but the request never reaches `CRM_Utils_REST::ajax()` because the request is denied when `CRM_Core_Invoke::_invoke()` calls `civi.invoke.auth`.5.56.1https://lab.civicrm.org/dev/core/-/issues/569Advanced Search: DB Error: no such field when the user tries to search by the...2022-12-21T05:03:17ZPradeep Nayakpradpnayak@gmail.comAdvanced Search: DB Error: no such field when the user tries to search by the 'Address Location' fieldTo Replicate:
![SearchViewError](/uploads/79aacb28527281d2c12b77ca16cdf7c2/SearchViewError.gif)To Replicate:
![SearchViewError](/uploads/79aacb28527281d2c12b77ca16cdf7c2/SearchViewError.gif)https://lab.civicrm.org/dev/core/-/issues/1268Setting a disabled value for a checkbox field via API wipes enabled values2022-12-21T05:03:16ZelilisseckSetting a disabled value for a checkbox field via API wipes enabled valuesNot quite sure what the use case would be but this was brought to my attention on mattermost and I replicated on a fresh buildkit install 5.19.alpha1.
**To reproduce:**
- Create a custom checkbox field and set a couple of option values ...Not quite sure what the use case would be but this was brought to my attention on mattermost and I replicated on a fresh buildkit install 5.19.alpha1.
**To reproduce:**
- Create a custom checkbox field and set a couple of option values (say, 'option1','option2','option3')
- Disable 'option3'
- Create values including the disabled one for your custom field via api e.g.
`$result = civicrm_api3('Contact', 'create', [
'id' => 202,
'custom_14' => ['option1','option2','option3'],
]);`
- Now retrieve the values set here and/or view the contact and you'll see it's been set to something like this:
![image](/uploads/3fea4b59ace2bdefafd4b15a1d4f5050/image.png)
and what's stored seems to be keys instead of valid values:
![image](/uploads/299361d0feff8c0bf96311d03bf89b0f/image.png)
Even though two of the values we tried to set are valid.
**Desired Behavior**:
I would expect this to behave instead like the multi-select field does. For a multi-select field an API create including a disabled value will simply accept the disabled value and store it, but it won't display on the contact record. The active values still display as expected.https://lab.civicrm.org/dev/core/-/issues/1273Member userdashboard section is not editable via searchColumns hook2022-12-20T05:03:25ZyashodhaMember userdashboard section is not editable via searchColumns hookMember userdashboard section is not editable via searchColumns hook. I reckon this has got to do with the fact the controller is not called for this section.
Contribution section columns can be edited via searchColumns hook though.Member userdashboard section is not editable via searchColumns hook. I reckon this has got to do with the fact the controller is not called for this section.
Contribution section columns can be edited via searchColumns hook though.https://lab.civicrm.org/dev/core/-/issues/1274Improve interaction between payment processor & cancelling2022-12-20T05:03:24ZeileenImprove interaction between payment processor & cancellingI've just taken a look at why some contributions don't show the full cancel screen but only the disable screen for cancelling recurring ie
![Screen_Shot_2019-09-23_at_7.01.15_PM](/uploads/152d70982f50131b4b02670311f5c19a/Screen_Shot_201...I've just taken a look at why some contributions don't show the full cancel screen but only the disable screen for cancelling recurring ie
![Screen_Shot_2019-09-23_at_7.01.15_PM](/uploads/152d70982f50131b4b02670311f5c19a/Screen_Shot_2019-09-23_at_7.01.15_PM.png)
vs
![Screen_Shot_2019-09-23_at_7.01.39_PM](/uploads/a7b3d23e855585fda481b758fa1dee15/Screen_Shot_2019-09-23_at_7.01.39_PM.png)
And what I see is the former shows if the payment processor supports CancelRecurring - this is set to TRUE - which is the case if the function cancelSubscription exists
However, it's only relevant if 'send_cancel_request' is checked.
```
if (CRM_Utils_Array::value('send_cancel_request', $params) == 1) {
$cancelParams = ['subscriptionId' => $this->_subscriptionDetails->subscription_id];
$cancelSubscription = $this->_paymentProcessorObj->cancelSubscription($message, $cancelParams);
}
```
So we have 2 decision points
1) do we show the cancel form or the disable form
2) do we show the notify payment processor checkbox / call cancelSubscription
**PROPOSAL**
I feel like a better mix would be.
1) always show the cancel screen rather than the if supportsCancelRecurring is TRUE. (I'm about 70% of the way to just saying 'always' - I don't see the advantage of the disable screen)
2) add an additional parameter supportsCancelNotifyProcessor that determines whether the check box shows up - we would need to default to TRUE for grandfathering (probably at the form level) unless supportsCancelRecurring is FALSE
3) always call the cancelRecurring button on submit IF the function cancelRecurring exists. (new preferred behaviour to grandfather in)
4) if cancelRecurring does not exist fall back to cancelSubscription IF exists AND 'send_cancel_request' is true (current behaviour)
5
Changes to documentation would be
1) if your processor allows recurring contributions to be cancelled then implement supportsCancelRecurring and return a boolean (relying on the parent is deprecated)
2) implement supportsCancelNotifyProcessor to determine whether the 'Send cancellation request to xx' radio button will show (default = yes )
3) add the current disabled text in if not showing the 'send to processor' box but use $processor->getText() so it can be overridden & set to null
4) implement cancelRecurring function if your processor needs to take an action on cancelling (it will need to parse the 'send_cancel_request' param in that function as it will be called either way.
5) cancelSubscription is deprectated
Secondary thoughts
1) I'm not a fan of it defaulting to notify the person but OK
2) I'm really not a fan of the backstop implementation of supportsCancelRecurring
```
protected function supportsCancelRecurring() {
return method_exists(CRM_Utils_System::getClassName($this), 'cancelSubscription');
}
```
I'd rather see us expect the payment processor to return TRUE or FALSE
@mattwire @adixon @KarinG @aghhttps://lab.civicrm.org/dev/core/-/issues/2898URL Tokens - CiviMail BAO and FlexMailer disagree over duplicate `http://`2022-12-19T22:45:31ZtottenURL Tokens - CiviMail BAO and FlexMailer disagree over duplicate `http://`Overview
--------
CiviMail BAO and Flexmailer provide two mechanisms to rendering/delivering mail-blasts. To phase out BAO-rendering, we should eventually migrate existing sites to Flexmailer. However, small discrepancies between them c...Overview
--------
CiviMail BAO and Flexmailer provide two mechanisms to rendering/delivering mail-blasts. To phase out BAO-rendering, we should eventually migrate existing sites to Flexmailer. However, small discrepancies between them can be an obstacle. This issue asks how to deal with a discrepancy when handling certain URL tokens.
(The issue is an off-shoot from the review discussion on https://github.com/civicrm/civicrm-core/pull/21522. However, they are somewhat distinct as 21522 applies to new-sites and this problem is more pressing on upgrade-sites.)
Background
-----------
Suppose you have an email token which generates a URL (eg `{action.forward}` or `{action.unsubscribeUrl}`) . The most correct way to use this token in an HTML-email is to place it in a hyperlink (`<a href="{action.forward}>`).
However, if you use CKEditor to compose a message, the hyperlink dialog strongly encourages you to put `http://` at the front of any hyperlink. Thus, you can organically produce expressions like `<a href="http://{action.forward}">`.
![CkeditorHttpToken](/uploads/e2d9bbf4ab6ba12a6cdcd936955277a9/CkeditorHttpToken.mov)
CiviMail BAO has a feature which mitigates this - in effect, both notations give the same output. However, Flexmailer (TokenProcessor) does not have a similar mitigation. Thus:
| HTML Email Expression | BAO Output | Flexmailer Output |
| -- | -- | -- |
| `<a href="{action.forward}>` | `<a href="https://example.com/civicrm/mailing/forward?...` | `<a href="https://example.com/civicrm/mailing/forward?...` |
| `<a href="http://{action.forward}>` | `<a href="https://example.com/civicrm/mailing/forward?...` | `<a href="http://https://example.com/civicrm/mailing/forward?...` |
Note the duplicate URL scheme (`http://http://`).
Scenarios: Good
---------
There are several scenarios wherein this discrepancy does not matter:
* You use CKEditor + BAO-renderer. (*The BAO renderer mitigates extraneous `http://`.*)
* You use Mosaico + Flexmailer. (*Mosaico's UI doesn't create extraneous `http://`.*)
(I suspect these two cohorts are the largest.)
Scenarios: Bad
---------
The potential for difficulty arises when mixing CKEditor with Flexmailer -- you take some HTML that was composed with CKEditor, run it through Flexmailer, and now you have invalid URLs with `http://https://`.
If we flip over more existing sites to Flexmailer, then it is foreseeable that more sites will be in this mixed scenario.
There's a secondary consideration in who may experience problems -- templates. Most users are not in the habit of typing `{action.forward}` or `{action.unsubscribeUrl}` regularly. Anecdotally, the typical practice is to put these kinds of tokens into a template, eg
* (A) Add a "User-Defined Template" (edited w/CKEditor in web; stored in `civicrm_msg_template`), or...
* (B) Reuse/copy a previous "Mailing" (edited w/CKEditor in web; stored in `civicrm_mailing`), or...
* (C) Configure default header/footer (no CKEditor; stored in `civicrm_mailing_component`)
Practical recap: today, if you enable Flexmailer on a site that uses CKEditor for mailings, then either:
* Your mailings and templates will have broken links -- because they use `<a href="http://{action.unsubscribeUrl}">`.
* This seems more likely if you use (A)/(B) - because the web UI uses CKEditor.
* Your mailings and templates will be cleanly interoperable -- because they use `<a href="{action.unsubscribeUrl}">`.
* This seems more likely if you use (C) header/footer because the web UI uses textarea.
Approaches
----------
1. Add a mitigation to Flexmailer or TokenProcessor which removes extraneous schema during the rendering phase.
* _Strength_: Best interoperability
* _Criticism_: Adds quirky bits to rendering.
* _Variations_: Patch Flexmailer vs patch TokenProcessor.
* _Variations_: Apply cleanup before rendering (`http://{action.*}` => `{action.*}`) or after rendering (`http://https?://` => `https?://`).
2. Add an upgrade-task to remove extra `http://` in front of tokens.
* _Strength_: No quirky bits in rendering.
* _Criticism_: CKEditor is still there. Can only upgrade core tables. Rewrites history (`civicrm_mailing.body_html` of past mailings).
3. Do nothing - Downstream users should manually convert their mailings/templates.
* _Strength_: Look, ma, no hands!
* _Criticism_: We cannot measure how many users will be impacted by break. For users with a "Reuse/Copy" workflow, they cannot fix historical mailings in UI.5.57.0https://lab.civicrm.org/dev/core/-/issues/1267Selecting payment method before contribution amount switches payment method a...2022-12-19T05:03:22ZsudomanSelecting payment method before contribution amount switches payment method and hides fieldsThanks for all of your work on CiviCRM. : )
If you select a payment method on a contribution page, then change the contribution amount radio button, the payment method radio button reverts to the first option (in this case "credit card"...Thanks for all of your work on CiviCRM. : )
If you select a payment method on a contribution page, then change the contribution amount radio button, the payment method radio button reverts to the first option (in this case "credit card"), and the fields for credit card details don't appear until you switch to an alternate payment method, and then back to credit card.
The desired behaviour is for selecting the contribution amount radio button to not change the payment method.https://lab.civicrm.org/dev/core/-/issues/1258Document CiviCRM Features (Maryland Sprint 2019)2022-12-19T05:03:21ZjcorlewDocument CiviCRM Features (Maryland Sprint 2019)# Process
* Canonical path
* Description of feature/function
* Category of usefulness
* A) Good as-is
* B) Needs work
* C) Necessarily complex
* D) Confusing / complex
* Recommendations
* Telemetric interest# Process
* Canonical path
* Description of feature/function
* Category of usefulness
* A) Good as-is
* B) Needs work
* C) Necessarily complex
* D) Confusing / complex
* Recommendations
* Telemetric interesthttps://lab.civicrm.org/dev/core/-/issues/4037SearchKit: In place edit for gender incorrect field type2022-12-19T00:52:53ZlarsssandergreenSearchKit: In place edit for gender incorrect field typeThe in place edit field for gender shows as integer field type, instead of the expected select for gender options.
![image](/uploads/e513535286251c13ed021034e16b8d1a/image.png)The in place edit field for gender shows as integer field type, instead of the expected select for gender options.
![image](/uploads/e513535286251c13ed021034e16b8d1a/image.png)https://lab.civicrm.org/dev/core/-/issues/1260Reorganize Misc settings page2022-12-18T05:03:17Zm robimorgan@palantetech.coopReorganize Misc settings pageAs part of a larger effort to make the administrative settings forms more user-friendly, we're proposing some changes to what is currently the Administer > Misc settings page.
Propose changing the form name to: System Options (Undelete...As part of a larger effort to make the administrative settings forms more user-friendly, we're proposing some changes to what is currently the Administer > Misc settings page.
Propose changing the form name to: System Options (Undelete, PDFs, Limits, Logging, captcha, etc.)
Some settings that appear on this page are better classified as "Display Preferences" and should be moved to there:
* Display "empowered by CiviCRM"
* Size of "Recent Items" stack
* Recent Items Providers
* Allow alerts to auto-dismiss?
Some settings on the Display Preferences page are better classified as "System Options" and should be moved from there to here:
* Wysiwig Editor
* Enable popup forms?
Larger structural settings should be in a separate section at the bottom (they are heavier/higher-stakes and less likely to be altered) with a header such as "System Configuration" and maybe a red box. In general, the settings on the form could be ordered by most-to-least lightweight/reversible, with settings that only affect admins at the top.
* PrevNext Cache
* Accept profile submissions from external sites
* Logging (+ add some clarifying text)
* Contact Trash and Undelete
@tommybobohttps://lab.civicrm.org/dev/core/-/issues/1261New Activity Preferences page2022-12-18T05:03:16Zm robimorgan@palantetech.coopNew Activity Preferences pageIn an effort to reorganize the administrative settings forms (see #1260) we propose moving some settings from the Administer > Display Preferences page and the Misc. settings page to a separate preferences page specifically for Activity ...In an effort to reorganize the administrative settings forms (see #1260) we propose moving some settings from the Administer > Display Preferences page and the Misc. settings page to a separate preferences page specifically for Activity settings.
Settings to appear on this page include:
* Notify Activity Assignees
* Do not notify assignees for
* Include Ical Invite to Activity Assignees
* Preserve activity filters as a user preference
* Record generated letters (note: use "Print/merge document" instead of "letter" for clarity)
@tommybobohttps://lab.civicrm.org/dev/core/-/issues/4012Contribution Page credit card expiry months are incorrectly offset when the t...2022-12-17T23:11:48ZbgmContribution Page credit card expiry months are incorrectly offset when the timezone is WhitehorseFound an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster...Found an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster / drupal7:
- login as the demo user
- change the user's timezone to America/Whitehorse
Then go to a contribution page:
https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=2
![image](/uploads/ea61f948003f258501391a3c90e2a6e3/image.png)5.58.0https://lab.civicrm.org/dev/core/-/issues/4036"New Batch" page no longer loads2022-12-17T19:15:25ZJonGold"New Batch" page no longer loadsOverview
----------------------------------------
"New Batch" no longer loads. When you try, you get an error.
Reproduction steps
----------------------------------------
1. Go to http://yoursite/civicrm/batch/add?reset=1&action=add
C...Overview
----------------------------------------
"New Batch" no longer loads. When you try, you get an error.
Reproduction steps
----------------------------------------
1. Go to http://yoursite/civicrm/batch/add?reset=1&action=add
Current behaviour
----------------------------------------
![image001](/uploads/2a7a6b049f0917e4c112cb72616659ba/image001.png)
Expected behaviour
----------------------------------------
No error.
Comments
----------------------------------------
This is a regression in https://github.com/civicrm/civicrm-core/pull/24770. I did some checking to see what other classes might be affected (using `ag -l 'extends CRM_Admin_Form' | xargs ag -L DefaultEntity` as a base) but couldn't find any others.5.56.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1266Save & Next button on Contribution Page Widgets tab does not move user to nex...2022-12-17T05:03:21ZelilisseckSave & Next button on Contribution Page Widgets tab does not move user to next stepWhen configuring a contribution page through the GUI, clicking save and next typically moves a user to the next tab header. Only on the last tab the user will get a "Save & Done" button that brings them back to the "Manage Contribution P...When configuring a contribution page through the GUI, clicking save and next typically moves a user to the next tab header. Only on the last tab the user will get a "Save & Done" button that brings them back to the "Manage Contribution Pages" screen.
Currently the "Save & Next" button on the second-to-last tab (Widgets) boots the user back to "Manage Contribution Pages" instead of moving them to the "Personal Campaigns" tab as expected.
PR: https://github.com/civicrm/civicrm-core/pull/15323