Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-09T05:03:24Zhttps://lab.civicrm.org/dev/core/-/issues/3696Should MessageTemplate.send support tplParams with Smarty disabled?2024-03-09T05:03:24ZRichShould MessageTemplate.send support tplParams with Smarty disabled?The api3 MessageTemplate.send action has supported `tplParams` since its inception in 2013, exposed explicitly in the api spec since 2015.
They allow a way to specify content for arbitrary email template parameters: `{$paramname}` - whi...The api3 MessageTemplate.send action has supported `tplParams` since its inception in 2013, exposed explicitly in the api spec since 2015.
They allow a way to specify content for arbitrary email template parameters: `{$paramname}` - which are different to `[entity.tokens]`. It's **super useful** for transactional mail where you want to include extra info as a one-off.
The api has done this by assigning the given key value pairs as Smarty variables.
More recently (2020) the api action added support for disabling Smarty, since it wasn't playing nicely with message template content generated by Mosaico.
Without Smarty, `tplParams` does not work.
## I would like to see support for `tplParams` without Smarty.
I think the concept of a message template is that it is a flexible template for emails. (Adding token support for one-off context-sensitive use-cases is very inefficient and is likely to end up with hackish situations where the data that needs to be in the email does not need to be in the database.)
I mistakenly thought that it used to work this way, and so I wrote a PR to fix what I saw as a regression, adding tests to boot. https://github.com/civicrm/civicrm-core/pull/19062 however this stalled, because it turns out it wasn't a regression, and so was felt to need more discussion. Hence this post.
The PR is a minor change and I can't see that it has any negative consequences/side effects (very few people will disable smarty anyway), but it does mean the tplParams feature is supported with/out Smarty, which I think is valuable.
There could be nicer ways to specify such content, but this isn't a proposal about a whole new way of doing things.
Thoughts?https://lab.civicrm.org/dev/core/-/issues/3718Profile listings fail to show email addresses when their location type Name d...2024-03-09T05:03:24ZspalmstromProfile listings fail to show email addresses when their location type Name differs from its Display NameOverview
----------------------------------------
If you create a location type and have different Names and Display Names, then a profile listing uses it fails to display the data.
Reproduction steps
-----------------------------------...Overview
----------------------------------------
If you create a location type and have different Names and Display Names, then a profile listing uses it fails to display the data.
Reproduction steps
----------------------------------------
1. Create a new location type with Name say TestingTesting and Display Name 'Testing Testing'.
2. Create a listing profile to display that location type.
3. Assign an email address of that type to a user.
4. Use the profile to display that user.
Current behaviour
----------------------------------------
Erik Adams detail viewed:
![image](/uploads/f1cda7c22218f4983bad7b1afadbeec6/image.png)
The email address does not show in the listing:
![image](/uploads/bacb9d89a6156a1504a64b7781be4838/image.png)
Expected behaviour
----------------------------------------
_What should happen._
![image](/uploads/c08545abfca4db63e1e3143ac52698b6/image.png)
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 not relevant
* __CiviCRM:__ _ 5.52.alpha1._ It is the Demo system<!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP__ _Whatever Demo is running_
* __CMS:__ _Drupal 9_ the version Demo is running.
* __Database:__ _Whatever Demo is running_.
* __Web Server:__ _Whatever runs Demo_
Comments
----------------------------------------
I have spent a few hours attempting to debug on a local system, but haven't been able to discover where the SELECT statement is being created. What appears to be happening is that the SELECT statement is has the Name of the Location Type as a column, whilst the Profile is expecting the Display Name, so when they don't match, the latter displays nothing.
You should note that if the Name is say Testing_Testing and the Display Name is 'Testing Testing', that the data are displayed. This is because somewhere in the Profile display spaces are replaced by underscores. It is how I was able to obtain the expected behaviour.
I am flagging this up in the hope that someone with more expertise than I can more easily identify where the solution lies.https://lab.civicrm.org/dev/core/-/issues/4987standalone: agree distribution format(s)2024-03-08T23:55:45ZRichstandalone: agree distribution format(s)Options:
**OPTION 1** Encourage composer-template
**OPTION 2** Encourage tar-ball (with current structure)
**OPTION 3** Encourage tar-ball (with composer-like structure)
(And is it one of those options -- or two of those options)
Mo...Options:
**OPTION 1** Encourage composer-template
**OPTION 2** Encourage tar-ball (with current structure)
**OPTION 3** Encourage tar-ball (with composer-like structure)
(And is it one of those options -- or two of those options)
Moved from [chat](https://chat.civicrm.org/civicrm/pl/4pwoodpzufd4z8x5wqguwhprbw) to save an unwieldy thread therein.
@totten
> i guess in theory # 1+# 3 sounds better than # 1+ # 2. but
>
> 1. even drupal.org appears to be following a structure like # 1+# 2
> 2. the workflow of "download+extract full tarball for composer-project" is a little weird for upgrades. (you need to delete+reset some folders -- but not other folders)
> 3. i'm not entirely sure how to reconcile # 3 with the regular RC workflow. i'm sure it can be sorted; but it's more of a conversation
>
@demerit (sorry, don't know your handle here)
> tarball tarball tarball
...
@wmortada
> For initial installation, having a tarball that a user can just download and install is preferable because it is easier and lowers the barrier to entry. But is this going to make upgrades more tricky for them? What could we do to make upgrades easier in this scenario?
@artfulrobot
> composer rules out hosting where you dont have shell access. Personally I'm cool with that, because you kinda need shell access to do things properly. Ftp for fun, shell for serious. (What a t shirt slogan!).
>
> I dont like messy things like unpack this tarball, replace directories a, b, c swap out file d.
>
> But I also don't love composer esp when it requires scripts to run. I tend to have my php as not owned by www-data, so the scripts won't run as www-data. Also in staging, where the httpd is in a container, I like to be able to manage the codebase from outside the container, but this will probably use a different php version. I'm happy to change my ways, though
>
> Other projects I work with:
>
> Nextcloud: provides a fairly solid upgrade script, even a web ui for upgrades, though they encourage CLI invocation to avoid timeouts. Files owned by www-data so the code writes the code. The CLI call to upgrade handles everything: checks, downloads, checksum checks, backups, moving files, running db migrations. It's solid and reliable, and there's a 'repair' command, in case something goes wrong (eg you tried your luck on the web ui method...)
>
> Roundcube mail: provides an upgrade script as part of the new release. So you download tar, extract to tmp/ run a script from there like install-to.php /path/to/installation/dir/
>
> I sometimes deploy by git too. I guess I could composer offline, commit, push, pull. I sometimes find composer flaky. There's one package that won't download or such. And it's slow (a zillion http requests) and can't be run offline.
>
> But it let's you add bits to your site, e.g. if you have civi as part of a bigger project. Which is nice.
>
> Tarballs are nice. Can be signed. Single download. Works offline.
>
> Barrier to entry: hmmm. Idk tbh. You need CLI access at mo, and as long as there's a reliable few commands to run that can be copy pasted it makes no difference?
>
> I'd quite like to be able to upgrade by git pull! Is that any more realistic in standalone? Probably red herring :blowfish:
>
> Let's not do this though...
> curl https://civicrn.org/gimmestandalone | sudo bash
@clarkac
> Please don't do anything that rules out hosting without shell access. That would discourage people from getting started with Civi, as I did and I've helped around 15 charities to get Civi - all hosted without shell access. I'm sure there are many in amongst the 4,000 D7 sites that don't have shell access.
>
> # 2 on the list is similar to what I do with upgrades with D7 - after backing up, delete the CiviCRM code folder and unpack the tarballs into it. That's so easy, and adding some more to that would be no problemhttps://lab.civicrm.org/dev/core/-/issues/4793Manage Premiums notices2024-03-08T20:20:54ZJoeMurrayManage Premiums noticesOn dmaster just now (5.69.alpha1), navigating to Administer > CiviContribute > Premiums (Thank-you gifts) https://dmaster.demo.civicrm.org/civicrm/admin/contribute/managePremiums?reset=1 titled Manage Premiums, I get notices:
Warning: U...On dmaster just now (5.69.alpha1), navigating to Administer > CiviContribute > Premiums (Thank-you gifts) https://dmaster.demo.civicrm.org/civicrm/admin/contribute/managePremiums?reset=1 titled Manage Premiums, I get notices:
Warning: Undefined array key "cost" in include() (line 38 of /srv/buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/%%3F/3F3/3F34E079%%ManagePremiums.tpl.php).
Warning: Undefined array key "financial_type" in include() (line 38 of /srv/buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/%%3F/3F3/3F34E079%%ManagePremiums.tpl.php).5.69.0https://lab.civicrm.org/dev/core/-/issues/5067Docker image - initial version2024-03-08T09:40:10ZMichael McAndrewDocker image - initial versionFor the initial image, we will focus on CiviCRM Standalone with a simple implementation of layer 3 (see #5066). While we are retaining a narrow focus for the initial release, the Design principles and scope #5066 are an attempt to future...For the initial image, we will focus on CiviCRM Standalone with a simple implementation of layer 3 (see #5066). While we are retaining a narrow focus for the initial release, the Design principles and scope #5066 are an attempt to future proof this work by considering a wider set of use cases.https://lab.civicrm.org/dev/core/-/issues/3089Meta: Create list of items for moving a core component to an extension2024-03-08T05:07:35ZDaveDMeta: Create list of items for moving a core component to an extensionIt's never really been fully done before. Some of the Grant things are likely to come up again if it's not documented. Partial list just quickly compiled from tickets. Doesn't include the things that did work (which would still need doin...It's never really been fully done before. Some of the Grant things are likely to come up again if it's not documented. Partial list just quickly compiled from tickets. Doesn't include the things that did work (which would still need doing), and might be missing some PRs that had no tickets.
* https://lab.civicrm.org/dev/core/-/issues/3069
* https://lab.civicrm.org/dev/core/-/issues/3076
* https://lab.civicrm.org/dev/core/-/issues/3056
* https://lab.civicrm.org/dev/core/-/issues/3057
* https://lab.civicrm.org/dev/core/-/issues/3087
* https://lab.civicrm.org/dev/core/-/issues/3093
* https://lab.civicrm.org/dev/core/-/issues/3100
* https://github.com/civicrm/civicrm-buildkit/pull/677
* https://lab.civicrm.org/dev/core/-/issues/3101
* https://github.com/colemanw/webform_civicrm/pull/719
* extendedreports
* https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/commit/6184de98c5b9f40475ab4164c993b19d68561240
* https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/pull/503
* https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/pull/506
* civicrm_entity
* https://github.com/eileenmcnaughton/civicrm_entity/pull/364
* an unresolved cache(?) issue
* https://github.com/twomice/com.joineryhq.jsumfields/pull/23
* https://github.com/civicrm/civicrm-drupal/pull/653
* https://github.com/civicrm/civicrm-drupal/pull/656
* https://github.com/civicrm/civicrm-core/pull/22905
* https://lab.civicrm.org/dev/core/-/issues/3118
* https://lab.civicrm.org/dev/core/-/issues/3119
* https://lab.civicrm.org/dev/core/-/issues/3159
* https://github.com/civicrm/civicrm-core/pull/23116
* https://github.com/civicrm/civicrm-core/pull/23118
* https://github.com/civicrm/civicrm-core/pull/23115
* https://lab.civicrm.org/dev/core/-/issues/3161
* https://github.com/civicrm/civicrm-core/pull/23336
* https://lab.civicrm.org/dev/core/-/issues/3485
* https://lab.civicrm.org/dev/core/-/issues/3492
* https://lab.civicrm.org/dev/core/-/issues/3503
* https://github.com/civicrm/civicrm-core/pull/24191
* https://github.com/civicrm/civicrm-core/pull/26118
Round 2:
* https://github.com/civicrm/civicrm-core/pull/26497
* https://github.com/civicrm/civicrm-core/pull/26499
Late to the party:
* https://lab.civicrm.org/dev/core/-/issues/5075https://lab.civicrm.org/dev/core/-/issues/3720CiviCRM 5.50.4, New install on WordPress throws fatal error when installation...2024-03-08T05:03:25Zjustinfreeman (Agileware)CiviCRM 5.50.4, New install on WordPress throws fatal error when installation completes - InstallationCanary.php. Error message: Uncaught CRM_Core_Exception: [0: Found installation canary.CiviCRM 5.50.4, New install on WordPress throws fatal error when installation completes - InstallationCanary.php. Error message: Uncaught CRM_Core_Exception: [0: Found installation canary.
Triggers the WordPress email error: Your Site i...CiviCRM 5.50.4, New install on WordPress throws fatal error when installation completes - InstallationCanary.php. Error message: Uncaught CRM_Core_Exception: [0: Found installation canary.
Triggers the WordPress email error: Your Site is Experiencing a Technical Issue
```
WordPress version 6.0
Active theme: Twenty Twenty-Two (version 1.2)
Current plugin: CiviCRM (version 5.50.4)
PHP version 7.4.30
Error Details
=============
An error of type E_ERROR was caused in line 37 of the file /var/www/vhosts/httpdocs/wp-content/plugins/civicrm/civicrm/Civi/Core/InstallationCanary.php. Error message: Uncaught CRM_Core_Exception: [0: Found installation canary. This suggests that something went wrong with tracking installation process. Please post to forum or JIRA.
```
Agileware Ref: CIVICRM-2010https://lab.civicrm.org/dev/core/-/issues/3698Too many custom groups2024-03-08T05:03:22ZkristinecToo many custom groupsTwo years ago, I reported an issue with "too many custom fields" [Issue #1330](https://lab.civicrm.org/dev/core/-/issues/1330). It seems that I have now surpass the limit for the **custom groups** instead of _custom fields_. If I add cus...Two years ago, I reported an issue with "too many custom fields" [Issue #1330](https://lab.civicrm.org/dev/core/-/issues/1330). It seems that I have now surpass the limit for the **custom groups** instead of _custom fields_. If I add custom group number 94, accessing some cases produces an error "case_id is not valid : 1.". Keeping the number of custom groups at 93 removes the error.https://lab.civicrm.org/dev/core/-/issues/5071TypeError when trying to use checkboxes with default non-membership options i...2024-03-08T04:07:50ZFrancis (Agileware)TypeError when trying to use checkboxes with default non-membership options in the Membership section of Contribution PagesOverview
----------------------------------------
If you have a PriceSet with a checkboxes field, that has default options set that **don't** have a membership type associated with them, trying to use it on a Contribution Page causes th...Overview
----------------------------------------
If you have a PriceSet with a checkboxes field, that has default options set that **don't** have a membership type associated with them, trying to use it on a Contribution Page causes that page to crash.
Observed on PHP 8.0, may not be an issue on 7.4 -
Reproduction steps
----------------------------------------
1. Create a membership price set
2. Include in this price set a Checkboxes fields with a default option that does not select a membership type, e.g.
Membership Type
[ ] General - $100
[ ] Student - $50
Be awesome
[ X ] Donate $150 to save the Northern White Rhino
3. Use this price set in the membership context of a Contribution page
4. View the contribution page on the front-end
Current behaviour
----------------------------------------
Contribution page does not load, crashes with TypeError:
```
PHP Fatal error: Uncaught TypeError: strtolower(): Argument #1 ($string) must be of type string, array given in /.../public_html/ontarget/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php:1419
```
Backtrace shows this is called from `CRM_Contribute_Form_Contribution_Main->setDefaultValues()`:
https://github.com/civicrm/civicrm-core/blob/4b75775/CRM/Contribute/Form/Contribution/Main.php#L270
(Ref 4b75775 is master at time of this report)
Expected behaviour
----------------------------------------
Contribution page should load, with defaults for all fields correctly applied
Environment information
----------------------------------------
* __CiviCRM:__ _Master, 5.70.2_
* __PHP:__ _8.0+_
Comments
----------------------------------------
I have a working patch for this, however I'm not sure the approach is entirely correct. The code in question appears to be trying to insinuate a Membership Type ID for, again an option (PriceFieldValue) which doesn't specify a membership type. Perhaps this line could... just be removed?5.72.0https://lab.civicrm.org/dev/core/-/issues/5029sms form missing tokens dropdown and save template section at bottom not hidd...2024-03-08T04:06:42ZDaveDsms form missing tokens dropdown and save template section at bottom not hidden properlyIn a "normal" environment the form isn't borked, but in my environment it seems to come from this change: https://github.com/civicrm/civicrm-core/pull/29429/commits/16b1692e4aebf478f39387ddabc08f1a2c2defae#diff-9a9c24bfd65521aa26fbb9fde3...In a "normal" environment the form isn't borked, but in my environment it seems to come from this change: https://github.com/civicrm/civicrm-core/pull/29429/commits/16b1692e4aebf478f39387ddabc08f1a2c2defae#diff-9a9c24bfd65521aa26fbb9fde3fd54d7a31331abebcb5e8e2a23b1a615bb500eL66
It works again if I put that line back.
The actual error seems to be `Undefined array key "templateSelected" in templates_c\en_US\%%C1\C1C\C1C61753%%InsertTokens.tpl.php on line 34`
This is when you choose the Send Outbound SMS action from the actions dropdown on a contact summary (who has a mobile phone).5.72.0https://lab.civicrm.org/dev/core/-/issues/3069Grant fields are included in exports in the Contact grouping2024-03-08T00:10:30ZDaveDGrant fields are included in exports in the Contact groupingGo to e.g. find contacts or find activities and from the results pick some or all and choose Export from the actions dropdown. Choose select fields for export. In the Contacts grouping, CiviGrant fields are being included there. I don't ...Go to e.g. find contacts or find activities and from the results pick some or all and choose Export from the actions dropdown. Choose select fields for export. In the Contacts grouping, CiviGrant fields are being included there. I don't remember seeing this before but will double-check if that's where they used to show up.5.47.0https://lab.civicrm.org/dev/core/-/issues/3474Afform - display privacy flag icons2024-03-07T23:35:11Zaydunsaidan.saunders@squiffle.ukAfform - display privacy flag iconsOverview
----------------------------------------
Form builder allows an icon to be selected conditionally when displaying a field. However, the icons that we use for the privacy flags 'do not email', 'do not phone' etc are actually mul...Overview
----------------------------------------
Form builder allows an icon to be selected conditionally when displaying a field. However, the icons that we use for the privacy flags 'do not email', 'do not phone' etc are actually multiple stacked icons and cannot be added to the display.
Example use-case
----------------------------------------
It would be useful (probably recommended) that when displaying an email address (or phone etc) for a contact with the 'do not email' privacy flag that the icon is shown next to the email address.
Current behaviour
----------------------------------------
A single icon can be displayed, but not stacked icons.
Proposed behaviour
----------------------------------------
Be able to display the privacy flag icons.
Comments
----------------------------------------
The privacy icons are added by the smarty function `CRM/Core/Smarty/plugins/function.privacyFlag.php`
Form builder allows using smarty in the rewrite field so I tried a rewrite of:
`{privacyFlag field=do_not_email condition=[do_not_email]} `
but 2 problems:
- the generated html is displayed rather than the icons
- conditional does not work because the `[do_not_email]` is passed as 'Yes' or 'No' instead of 1 or 0.
One approach would be to refactor the stacked icons out of the smarty function and make privacy flag icons a specific option in form builder.
Alternatively the form builder support for icons could be expanded to allow arbitrary stacked icons.https://lab.civicrm.org/dev/joomla/-/issues/52Cannot have a CiviCRM-link menu as default (home) page2024-03-07T23:14:49Zthoni56Cannot have a CiviCRM-link menu as default (home) pageIn Joomla you declare one menu item to be the default "front page" i.e. the one that you get to when no menu is selected, only the web sites base path.
In J3 this also worked for a menu entry that was a CiviCRM-entry, such as Event List...In Joomla you declare one menu item to be the default "front page" i.e. the one that you get to when no menu is selected, only the web sites base path.
In J3 this also worked for a menu entry that was a CiviCRM-entry, such as Event Listing or Mailing List Subscription. (check e.g. https://events.responsive.se which is a J3 site with Event Listing as the default menu entry.)
With J4 this no longer works. When going to the "home page" the menu item is highlighted to indicate that it is active, but there is no output in the content area.
I tried this with a clean J4 and CiviCRM and see the same thing. The underlined "Subscription" indicates that it is the menu entry that is active.The J4 default template Cassiopeia displays breadcrumbs which strangely enough shows "Home" and not "Subscription" (which is the menu entry for CiviCRM Mailing List Subscription form).
This is extra strange because the breadcrumb for the Home menu entry is actually "Home/Home" so the default page Subscription is something in between...
![image.png](/uploads/e82c3a451f5ed6010968e4d25c17d6a5/image.png)Explicitly clicking the "Subscription" menu entry correctly shows the form.
I don't really know enough about Joomlas routing to understand where the problem really is, but I'm starting by reporting it here.https://lab.civicrm.org/dev/core/-/issues/4995Standalone - JWT for password resets2024-03-07T22:30:13ZufundoStandalone - JWT for password resetsSwitch Standaloneusers password reset mechanism to use JWT, instead of custom format.
PR from @pfigel is here: https://github.com/civicrm/civicrm-core/pull/28505Switch Standaloneusers password reset mechanism to use JWT, instead of custom format.
PR from @pfigel is here: https://github.com/civicrm/civicrm-core/pull/28505Patrick Figelpfigel@greenpeace.orgPatrick Figelpfigel@greenpeace.orghttps://lab.civicrm.org/dev/core/-/issues/5038Default admin when installing2024-03-07T21:36:59ZErikHommelDefault admin when installingWhen installing standalone a user name and password can be entered. These fields have defaults, which led to confusions by 2 installers. They did not notice this and left the default values, and later on could not log in as they did not ...When installing standalone a user name and password can be entered. These fields have defaults, which led to confusions by 2 installers. They did not notice this and left the default values, and later on could not log in as they did not know user nor passwords. Defaults should be removed and fields mandatory.
Also I need to be able to add an email address. If I now did not notice the user and password and then click on the "forgot password" link an email will be sent to a localdomain e-mail address which is not very helpful.https://lab.civicrm.org/dev/core/-/issues/4988Standalone: doesn't install because of missing session class2024-03-07T21:23:58ZRichStandalone: doesn't install because of missing session classStandalone installer (web based) fails because it tries to start session before it's found the standaloneusers/ session class; presumably, before it's booted extensions(possibly?).
Note it is possible to install from civibuild, but the ...Standalone installer (web based) fails because it tries to start session before it's found the standaloneusers/ session class; presumably, before it's booted extensions(possibly?).
Note it is possible to install from civibuild, but the [other methods](https://docs.civicrm.org/installation/en/latest/standalone/) don't work.
See @clarkac https://chat.civicrm.org/civicrm/pl/neac84z6ztrymendzimmtqa18a
> Fatal error: Uncaught Error:
> Class "Civi\Standalone\SessionHandler" not found in
> .../web/core/CRM/Utils/System/Standalone.php
>
> followed by a stack trace followed by:
> thrown in .../web/core/CRM/Utils/System/Standalone.php on line 556ufundoufundohttps://lab.civicrm.org/dev/core/-/issues/4993Standalone - disable CMS user sync on Standalone2024-03-07T20:40:09ZufundoStandalone - disable CMS user sync on StandaloneThe CMS user sync doesn't make sense when using standaloneusers so should be disabledThe CMS user sync doesn't make sense when using standaloneusers so should be disabledufundoufundohttps://lab.civicrm.org/dev/core/-/issues/5070Contribution pending status wrong2024-03-07T18:16:21Zaydunsaidan.saunders@squiffle.ukContribution pending status wrong## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact...## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact.
2. `Actions` \> `Add Contribution` (or `Contributions` tab \> `Record Contribution`, or API4)
3. Choose any Financial Type and Amount, set Status to `Pending`
4. View the Contributions list
## Current behaviour
The status shows as `Pending (Incomplete Transaction)`
Then `Edit` the contribution, don't make any changes, just hit `Save`
Note that the status is now `Pending (Pay Later)`
## Expected behaviour
Should be `Pending (Pay Later)`
## Environment information
* **CiviCRM:** _Master & 5.70.0 - maybe others_
Reproducible on dmaster.demo.civicrm.org
## Comments
_See_ https://chat.civicrm.org/civicrm/pl/qcmoueddmfbm7bpfq4uauympcwhttps://lab.civicrm.org/dev/financial/-/issues/167Document Support for CiviCRM from payment processors2024-03-07T16:39:04ZJoeMurrayDocument Support for CiviCRM from payment processorsDocument appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partn...Document appropriately the support that CiviCRM receives from a variety of payment processors.
- [ ] Payment processing feature page that cites the sponsoring payment processors
- [ ] Individual payment processor pages similar to partner detail pages
- [ ] Update the extension readme.md on extensions in gitlab
- [ ] Update extension pages on c.o (for as long as these will exist)
Josh has started on first two tasks as of Feb 22, 2021.
----
Original description
Document appropriately (after determining what that means ;) ) the support that CiviCRM receives from a variety of payment processors.
This might mean putting something into the info.xml or README.md of each extension, as well as adding something somewhere on c.o.
See https://github.com/agileware/cf-stripe/issues/1
@mattwire any sense of Stripe's compensation arrangements being different in Australia compared to other countries? I like the policy thrust of @justinfreeman 's comment but don't believe it is industry practice.joshjosh@civicrm.orgjoshjosh@civicrm.orghttps://lab.civicrm.org/dev/core/-/issues/5062APIv4: Cannot set multi-select ContactRef field that is part of a multi-recor...2024-03-07T15:44:13ZmmyriamAPIv4: Cannot set multi-select ContactRef field that is part of a multi-record custom fieldsetOverview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom f...Overview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom field set for all Individuals and check "Does this Custom Field Set allow multiple records?"
2. Add a ContactRef field and check "Multi-Select"
3. Try to set it via the APIv4 Explorer
![image](/uploads/44ecbf788a66150425e55a9de8a6212f/image.png)
Current behaviour
----------------------------------------
Failing with error:
```
{
"error_code": 0,
"error_message": "value: \u00013\u000193\u0001 is not of the right field data type: ContactReference",
"status": 500
}
```
Environment information
----------------------------------------
https://dmaster.demo.civicrm.org running 5.72.alpha1
Comments
---
Not an issue if the multi-select ContactRef field is not part of a multi-record custom fieldset.