Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-11-29T05:03:26Zhttps://lab.civicrm.org/dev/core/-/issues/3092Batch search form/results incorrect vis-a-vis status2023-11-29T05:03:26ZlcarterBatch search form/results incorrect vis-a-vis statusThe batch search form searches based on contribution status, but has a results column displaying transaction/payment status. This is confusing and undesirable.
Even when the search is specifically limited to contributions with complete...The batch search form searches based on contribution status, but has a results column displaying transaction/payment status. This is confusing and undesirable.
Even when the search is specifically limited to contributions with completed status, some results may show pending status; this is confusing to the user. See https://www.screencast.com/t/XgNTPieRXz - the box is indicating two transaction records for the same dues payment.
Proposal:
1. Expose a search filter field for civicrm_financial_trxn.status_id as well as contribution status.
2. In Search Results, change the column title from Status to something more clear, like Financial Transaction Status or (slightly inaccurate but generally true and more understandable) Payment Status.
3. In Search Results, add a column title Contribution Status that displays the civicrm_contribution.status_id field.
Discussion:
This functionality has been around for a long time and not used much. Perhaps that because it has a confusing UX. The proposal would not break anything for existing users.
However, for many years there was a desire to get rid of Contribution Status, partly for reasons that @lcarter is raising here: a field on contribution record can't do the job of representing all of the statuses of multiple steps in multiple payments, for example, perhaps followed by refunds or cancellation or some failure attempts in the middle.https://lab.civicrm.org/dev/core/-/issues/3091Pending financial transaction records remain in civicrm_financial_trxn and ap...2022-02-28T22:47:43ZlcarterPending financial transaction records remain in civicrm_financial_trxn and appear in batch searchReproduced on dmaster.demo.civicrm.org as of 2/28/2022 and also occurring in CiviCRM 5.39.5. Steps to replicate:
* Create a membership with a pending payment.
* View the membership and record the payment.
* View the batch search result...Reproduced on dmaster.demo.civicrm.org as of 2/28/2022 and also occurring in CiviCRM 5.39.5. Steps to replicate:
* Create a membership with a pending payment.
* View the membership and record the payment.
* View the batch search results - both the completed payment record and the pending financial transaction are listed: https://www.screencast.com/t/XgNTPieRXz However, only the completed payment record shows up on the contribution record itself: https://www.screencast.com/t/MQToafE2V
Notes:
* This occurs whether or not the payment method of the original pending payment and the (later) recorded payment match - I've tested it both ways.
* Although I can't access the database for dmaster, I'm attaching a screenshot of what these records look like in civicrm_financial_trxn.
* The site in question has the option for always recording A/R transactions disabled.
Because this isn't, strictly speaking, a payment record or even an update of the transaction that would be exported to an accounting system, it does not seem to me that this should be included in the batch results. (Whether or not this entry should be left as pending is another question.)
![2022-02-18_16-51-37](/uploads/55d83146c89047469faac8909847a27b/2022-02-18_16-51-37.png)https://lab.civicrm.org/dev/core/-/issues/3090Changelog fails when viewing an update with relationship type ID change2022-02-28T20:24:00ZJonGoldChangelog fails when viewing an update with relationship type ID changeOverview
----------------------------------------
This is a regression, but it goes back to 5.42 and isn't high priority so I don't think it needs to go in the RC (especially with a release about to be cut).
Reproduction steps
---------...Overview
----------------------------------------
This is a regression, but it goes back to 5.42 and isn't high priority so I don't think it needs to go in the RC (especially with a release about to be cut).
Reproduction steps
----------------------------------------
1. Enable advanced logging.
1. Make a change to a relationship type ID.
1. Go into the contact's Change Log tab, select **Update** for the relevant change.
Current behaviour
----------------------------------------
`DB Error: Syntax Error`.
Expected behaviour
----------------------------------------
Well, not that.
Comments
----------------------------------------
There was a change to return the label for a field where applicable, but done in such a way that any DAO that has the default `$_fieldLabel` property of `NULL` will get a syntax error. The `$_fieldLabel` is used to generate the fields in a SQL `SELECT` statement and can't be `NULL`.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3088Notice error on dmaster2022-04-13T23:35:48ZJoeMurrayNotice error on dmasterOn dmaster 5.48.alpha1. Administer > CiviContribute Component Settings. Check Always post to Accounts Receivable? and submit, then one sees:
Notice: Trying to get property 'info' of non-object in CRM_Admin_Page_Admin->run() (line 43 of ...On dmaster 5.48.alpha1. Administer > CiviContribute Component Settings. Check Always post to Accounts Receivable? and submit, then one sees:
Notice: Trying to get property 'info' of non-object in CRM_Admin_Page_Admin->run() (line 43 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Page/Admin.php).
Notice: Trying to get property 'info' of non-object in CRM_Admin_Page_Admin->run() (line 43 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Page/Admin.php).
I marked as regression but don't know when this appeared. If I had to guess it is related to PHP version rather than a code change.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3087CiviGrant appears in admin menu twice2022-03-01T01:07:07ZDaveDCiviGrant appears in admin menu twiceI think it's maybe some leftovers in xml/templates/civicrm_navigation.tpl that need to be moved over/removed.I think it's maybe some leftovers in xml/templates/civicrm_navigation.tpl that need to be moved over/removed.5.47.0https://lab.civicrm.org/dev/core/-/issues/3086Paypal declines recurring payments with wrong decimal delimiter2023-11-30T05:03:15ZMatthiasKPaypal declines recurring payments with wrong decimal delimiterOverview
----------------------------------------
Recurring paypal payments wont work if the "Decimal Delimiter" is not set to "." which is the usual the case in germany. This happend when using the payment processor "PayPal - Website Pa...Overview
----------------------------------------
Recurring paypal payments wont work if the "Decimal Delimiter" is not set to "." which is the usual the case in germany. This happend when using the payment processor "PayPal - Website Payments Standard".
Example use-case
----------------------------------------
1. Click on **Administer -> Localisation -> Languages, Currency, Locations **.
2. Set "Decimal Delimiter" to "," (common decimal delimiter in germany)
3. Configure Paypal as payment processor with payment processor type "PayPal - Website Payments Standard"
4. Configure an event that requires recurring payments and allow payments via paypal
Current behaviour
----------------------------------------
At the moment recurring payments are only possible if the "Decimal Delimiter" is set to ".". This results in problems and misunderstandings for accounting and when paying contributions.
Proposed behaviour
----------------------------------------
The paypal implementation is done in ** Core/Payment/PayPalImpl.php **. Maybe it could be checked if the "Decimal Delimiter" is set to "." before sending the request to paypal and change it if its not the case.https://lab.civicrm.org/dev/core/-/issues/3085Checkbox fields on profile admin page can't be unchecked2022-03-09T20:27:07ZspalmstromCheckbox fields on profile admin page can't be uncheckedOverview
----------------------------------------
Once mapping is enabled for a profile, you cannot disable it.
Reproduction steps
----------------------------------------
1. Click on **Administer -> Custom Data and Screens -> Profiles...Overview
----------------------------------------
Once mapping is enabled for a profile, you cannot disable it.
Reproduction steps
----------------------------------------
1. Click on **Administer -> Custom Data and Screens -> Profiles **.
1. Select **Name and Address -> Settings**.
1. Click on **Advanced Settings**.
1. Click the _Enable Mapping for this profile?_ box.
1. Click on **Save**.
1. Repeat steps 2 to 4, thus clearing the _Enable Mapping_ checkbox.
1. Click on **Save**.
1. Repeat steps 2 and 3.
1. You will see that the mapping box remains ticked.
Current behaviour
----------------------------------------
The mapping box remains ticked.
`
Expected behaviour
----------------------------------------
The mapping box should remain clear when it has been cleared before saving.
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 necessary. -->
* __MS Edge__ but probably not relevant.
* __CiviCRM:__ _5.48.alpha1/5.46.2_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ 7.3.33-1+0\~20211119.91+debian10~1.gbp618351/7.4__ but probably not relevant.
* __CMS:__ _Whatever the Sandbox runs under/Drupal 9.3.6_ but probably not relevant.
* __Database:__ _Whatever the Sandbox runs under/MySQL 8.x_ but probably not relevant.
* __Web Server:__ _Whatever the Sandbox runs under/IIS 10_ but probably not relevant.
Comments
----------------------------------------
This makes it impossible to turn off mapping. Note that I reproduced this on the Sandbox.5.49.0https://lab.civicrm.org/dev/core/-/issues/3084Backend membership with a price set will ignore the price field financial typ...2022-05-05T06:27:07ZherbdoolBackend membership with a price set will ignore the price field financial type, uses price set insteadOverview
----------------------------------------
Backend membership with a price set will ignore the price field financial type, uses price set instead. (This is a different problem from https://lab.civicrm.org/dev/core/-/issues/3083 t...Overview
----------------------------------------
Backend membership with a price set will ignore the price field financial type, uses price set instead. (This is a different problem from https://lab.civicrm.org/dev/core/-/issues/3083 though they should be consistent).
Related to https://lab.civicrm.org/dev/core/-/issues/3084, https://lab.civicrm.org/dev/core/-/issues/2414
Reproduction steps
----------------------------------------
1. Set up a price set to include memberships.
2. One price field should be membership of financial type Member Dues. The other Donation.
![2022-02-25_14.17.49_dev-cycleto.pantheonsite.io_edb775bf4afb](/uploads/baab97de74fc3910e4a016138db06c98/2022-02-25_14.17.49_dev-cycleto.pantheonsite.io_edb775bf4afb.png)
3. Make a backend membership purchase.
Current behaviour
----------------------------------------
The contribution will show that each line item gets the financial type from the price set and not from the price set field:
![2022-02-25_14.16.03_dev-cycleto.pantheonsite.io_372ee7ffbad1](/uploads/1f8a227ce02fb8c0d1b28a707ada8af0/2022-02-25_14.16.03_dev-cycleto.pantheonsite.io_372ee7ffbad1.png)
And it doesn't set the non-deductible amount properly. In fact, I don't think it's set either way. If I change the price set financial type to be Merchandise then it still doesn't set the non-deductible.
![2022-02-25_14.25.54_dev-cycleto.pantheonsite.io_ad7e30a61562](/uploads/4b22eafeeca74ee89f60918102bed234/2022-02-25_14.25.54_dev-cycleto.pantheonsite.io_ad7e30a61562.png)
Expected behaviour
----------------------------------------
Should use the financial type of the price set *field/option*. And it should set the non-deductible based on that. This is how it's working for a non-member price set: it will use the price field financial type and non-deductible amount regardless of what the price set is using.5.49.0https://lab.civicrm.org/dev/core/-/issues/3082Enhance EntityRef to widget to show create new option when contacts are restr...2022-03-09T13:47:08ZKurund JalmiEnhance EntityRef to widget to show create new option when contacts are restricted by multiple contact type## Current behavior
Below code works fine and shows `create new` option when contacts are restricted by single contact type.
```php
$this->addEntityRef('my_field', ts('Select Contact'), [
'api' => [
'params' => ['contact_type' =>...## Current behavior
Below code works fine and shows `create new` option when contacts are restricted by single contact type.
```php
$this->addEntityRef('my_field', ts('Select Contact'), [
'api' => [
'params' => ['contact_type' => 'Organization'],
],
'create' => TRUE,
]);
```
However, when contacts are restricted by multiple contacts `create new` option is not available
```php
$this->addEntityRef('my_field', ts('Select Contact'), [
'api' => [
'params' => ['contact_type' => ['IN' => ["Individual", "Organization"]]]
],
'create' => TRUE,
]);
```
## Expected behavior
- It should show create new options for Individual and Organization.5.49.0https://lab.civicrm.org/dev/core/-/issues/3081CiviContribute Dashboard #chart_Layout does not respect Financial Type ACL2023-11-28T05:03:27Zchris_bluejacCiviContribute Dashboard #chart_Layout does not respect Financial Type ACLOverview
----------------------------------------
When a user is assigned financial type ACL, the **chart** (#chart_layout) on the CiviContribute Dashboard totals all financial types, not just the financial type/s the user has add/view p...Overview
----------------------------------------
When a user is assigned financial type ACL, the **chart** (#chart_layout) on the CiviContribute Dashboard totals all financial types, not just the financial type/s the user has add/view permissions.
The **table** (#table_layout) does respect the financial type ACL when determining the totals.
Reproduction steps
----------------------------------------
1. User is assigned permissions:
- CiviCRM: add contributions of type XXX
- CiviCRM: view contributions of type XXX
2. Go to CiviContribute Dashboard
Current behaviour
----------------------------------------
/civicrm/contribute?reset=1#chart_layout
- Chart contribution totals all financial types, regardless of ACL
- ![CiviContribute-chart-layout](/uploads/9290a635ba5c59d34e89fa5a37901ed6/CiviContribute-chart-layout.png)
/civicrm/contribute?reset=1#table_layout
- Table contribution totals financial type XXX, respecting the ACL
- ![CiviContribute-Table-Layout](/uploads/f8de42bb72e3ef4e395fe97f3bb1bf70/CiviContribute-Table-Layout.png)
Expected behaviour
----------------------------------------
Chart totals should be total of financial types the user has view access to
Environment information
----------------------------------------
* CiviCRM: 5.46.2
* PHP: 7.3.27
* CMS: Drupal 7.88
* Database: MySQL 5.7.33
* Web Server: Apache 2.4.46
* reCAPTCHA: Version 5.40.2
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/3080Duplicate Billing location checkbox for a contact is allowed during inline ad...2022-04-07T20:59:16ZVangelisPDuplicate Billing location checkbox for a contact is allowed during inline address editingOverview
----------------------------------------
In the case that someone has 2 addresses registered, they can flag both of them as billing location via the inline address editing checkbox which I believe is wrong. This behaviour does n...Overview
----------------------------------------
In the case that someone has 2 addresses registered, they can flag both of them as billing location via the inline address editing checkbox which I believe is wrong. This behaviour does not replicate when you edit the contact.
I am assuming that this is not an intended behaviour.
Reproduction steps
----------------------------------------
1. On the [CiviCRM demo site](https://dmaster.demo.civicrm.org) go to the default `demo@example.com` contact.
1. Do an inline edit and add an address. Check the checkbox "Billing location for this contact".
1. Add a 2nd address via inline editing and check again the checkbox "Billing location for this contact" on the 2nd address.
1. Review both addresses, both got the "Billing location for this contact".
1. Try to edit the contact using the edit button, check both checkboxes and save the form. Only one address gets the checkbox "Billing location for this contact".
Expected behaviour
----------------------------------------
There should be a validation while saving the inline address form to check if the checkbox is already being used in another address ID and if yes, it should not store the checkbox (or unset it).5.49.0https://lab.civicrm.org/dev/core/-/issues/3079"Manage Extensions" - Allow deleting unused extensions2023-11-27T05:03:22Ztotten"Manage Extensions" - Allow deleting unused extensionsOverview
----------------------------------------
The "Manage Extensions" UI allows you to download extensions. It does not allow you delete extensions... ever.
Example use-case
----------------------------------------
The web-user go...Overview
----------------------------------------
The "Manage Extensions" UI allows you to download extensions. It does not allow you delete extensions... ever.
Example use-case
----------------------------------------
The web-user goes through this process...
1. Download and enable the "Ice Cream" extension
2. Download and enable the "Cherry Pie" extension
3. Download and enable the "Gulab Jamun" extension
4. Disable and uninstall the "Ice Cream" extension
5. Disable and uninstall the "Cherry Pie" extension
6. Disable and uninstall the "Gulab Jamun" extension
Current behaviour
----------------------------------------
The inactive extensions add noise to the "Manage Extensions" UI.
The web user is stuck with inactive extensions "Ice Cream", "Cherry Pie", and "Gulab Jamun".
Proposed behaviour
----------------------------------------
Add a "Delete" button. "Delete" is only supported if these conditions are met:
* Ext status is "Uninstalled" (no db content)
* Ext lives in the "default container" (`[civicrm.files]/ext`)
* Ext is writable by current POSIX user
* Ext does not have any other ext's underneath it
* Web-user has permission to manage exts
* (*Undecided: If there are multiple copies of an ext, do we still allow deleting the copy in `[civicrm.files]/ext`? I think probably so...*)
Comments
----------------------------------------
The pre-conditions above should ensure that we don't (eg) delete extensions that live in `vendor/` or `civicrm/ext/`. Those extensions usually aren't managed via web UI (eg they're managed by `composer install` or `tar xvzf civicrm-XYZ.tar.gz`), and they may be shared in multitenant deployments.
The "Delete" button is not necessarily something to take too lightly. Perhaps it goes in expanded/drill-down section? Maybe next to the "Local Path"?
If a user gets into a situation where they want to delete an extension but cannot, then (1) there should be an indication of why "Delete" is unsupported, and (2) we may want to suggest manual/CLI-based deletion as an alternative.https://lab.civicrm.org/dev/core/-/issues/3078Support for HEIC/HEIF Images2023-11-26T05:03:23ZpbarmakSupport for HEIC/HEIF ImagesPer a stackexchange question I posed here (https://civicrm.stackexchange.com/questions/41314/handling-heic-heif-photos), it would be beneficial to add support for heic/heif images, both when adding a photo for a contact and displaying th...Per a stackexchange question I posed here (https://civicrm.stackexchange.com/questions/41314/handling-heic-heif-photos), it would be beneficial to add support for heic/heif images, both when adding a photo for a contact and displaying that same photo.https://lab.civicrm.org/dev/core/-/issues/3077case xml processor skips pre hook when creating roles/relationships2022-02-26T15:18:41Zlcdwebcase xml processor skips pre hook when creating roles/relationshipsWhile trying to implement some custom modifications to case roles when a case is created, I found that the relationship creation is not passed through the pre/post hooks. This is because the XML Processor does a direct DAO insertion, rat...While trying to implement some custom modifications to case roles when a case is created, I found that the relationship creation is not passed through the pre/post hooks. This is because the XML Processor does a direct DAO insertion, rather than using the BAO add() method.
See:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/XMLProcessor/Process.php#L248
I think this can be safely swapped for CRM_Contact_BAO_Relationship::add(). But looking for others to provide input.5.48.0lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/3076API v4 Grant.get fails for non-Admin users2022-02-28T17:00:42ZjhungerfordAPI v4 Grant.get fails for non-Admin usersOverview
----------------------------------------
When calling Grant.get using API v4, non-admin users always fail the authorization check, even if they have the permission "CiviGrant: access CiviGrant". Calling Grant.get using API v3 wo...Overview
----------------------------------------
When calling Grant.get using API v4, non-admin users always fail the authorization check, even if they have the permission "CiviGrant: access CiviGrant". Calling Grant.get using API v3 works as expected for the same user.
Reproduction steps
----------------------------------------
1. Install this extension: https://github.com/AsylumSeekersCentre/au.org.asylumseekerscentre.testapigrantget (not for use on production sites!)
1. Navigate to any CiviCRM page as a non-admin user
1. View the CMS log as an admin and see the non-admin's authorization failure following the api3 success
1. Optionally remove the try...except wrapping in the testapigrantget_civicrm_alterContent function to see the backtrace and detailed error message
Current behaviour
----------------------------------------
When calling Grant.get with API v4 for a non-admin user, it encounters an UnauthorizedException, even when the user has permission to view Grants.
This affects SearchKit searches involving Grants.
This is the backtrace when the try...except block is removed from the demo extension linked above:
```
$backTrace = #0 /var/www/basepath/sites/all/modules/civicrm/CRM/Core/Error.php(433):
CRM_Core_Error::backtrace("backTrace", TRUE) #1 /var/www/basepath/sites/all/modules/civicrm/CRM/Core/Invoke.php(39):
CRM_Core_Error::handleUnhandledException(Object(Civi\API\Exception\UnauthorizedException)) #2 /var/www/basepath/sites/all/modules/civicrm/drupal/civicrm.module(471):
CRM_Core_Invoke::invoke((Array:1)) #3 /var/www/basepath/includes/menu.inc(527):
civicrm_invoke() #4 /var/www/basepath/index.php(21):
menu_execute_active_handler() #5 {main}
```
This is the detailed error message (with some extra newline characters added for readability):
```
$Fatal Error Details = array:3 [ "message" => "Authorization failed" "code" => null "exception" => Civi\API\Exception\UnauthorizedException {#3808 -extraParams: array:1 [ "error_code" => "unauthorized" ]
#message: "Authorization failed" #code: 0 #file: "/var/www/basepath/sites/all/modules/civicrm/Civi/API/Kernel.php" #line: 223 trace: { /var/www/basepath/sites/all/modules/civicrm/Civi/API/Kernel.php:223 { › if (!$event->isAuthorized()) { › throw new \Civi\API\Exception\UnauthorizedException("Authorization failed"); › }
}
/var/www/basepath/sites/all/modules/civicrm/Civi/API/Kernel.php:147 { …}
/var/www/basepath/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php:234 { …}
/var/www/basepath/CRM/extensions/au.org.asylumseekerscentre.testapigrantget/testapigrantget.php:153 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Utils/Hook.php:283 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Utils/Hook/DrupalBase.php:73 { …}
/var/www/basepath/sites/all/modules/civicrm/Civi/Core/CiviEventDispatcher.php:249 { …}
/var/www/basepath/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php:214 { …}
/var/www/basepath/sites/all/modules/civicrm/vendor/symfony/event-dispatcher/EventDispatcher.php:44 { …}
/var/www/basepath/sites/all/modules/civicrm/Civi/Core/CiviEventDispatcher.php:198 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Utils/Hook.php:167 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Utils/Hook.php:1736 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Core/Page.php:253 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Contact/Page/DashBoard.php:57 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Core/Invoke.php:319 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Core/Invoke.php:69 { …}
/var/www/basepath/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/var/www/basepath/sites/all/modules/civicrm/drupal/civicrm.module:471 { …}
/var/www/basepath/includes/menu.inc:527 { …}
/var/www/basepath/index.php:21 { …}
}
}
]
```
Expected behaviour
----------------------------------------
As I understand it, non-admin users with the permission "CiviGrant: access CiviGrant" should be able to view results from SearchKit searches involving Grants. They should also be able to view other pages relying on Grant.get using API v4.
The extension linked above turns every Civi page into a page relying on Grant.get using api4, and when it's installed, the CMS log should show a number of grants returned by the call instead of an error when a Civi page is loaded.
Environment information
----------------------------------------
* __Browser:__ Chromium 90.0.4430.212 and Firefox 78.12.0esr, Debian versions
* __CiviCRM:__ 5.46.2
* __PHP:__ 7.3.31-2+0~20211022.89+debian10~1.gbp745ac7
* __CMS:__ Drupal 7.88
* __Database:__ mysql Ver 15.1 Distrib 10.3.31-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
* __Web Server:__ Apache 2.4.38-3+deb10u7
Comments
--------
I haven't been able to determine the cause of the authorization failure, only that $event->authorized contains "null" after the auth check for API v4, whereas during the equivalent Grant.get call for API v3, $event-authorized contains "1" for the same non-admin user (on line 222 of /Civi/API/Kernel.php in both cases).https://lab.civicrm.org/dev/wordpress/-/issues/119Autocomplete dropdowns inaccessible behind lightbox2023-12-06T17:16:48ZbakkboneAutocomplete dropdowns inaccessible behind lightbox![Screen_Shot_2022-02-17_at_6.41.52_pm](/uploads/996c28afe8f7457cc6f41c2d22a53799/Screen_Shot_2022-02-17_at_6.41.52_pm.png)
When trying to add a membership type in CiviMember, the dropdowns all appear behind the lightbox and can't be cli...![Screen_Shot_2022-02-17_at_6.41.52_pm](/uploads/996c28afe8f7457cc6f41c2d22a53799/Screen_Shot_2022-02-17_at_6.41.52_pm.png)
When trying to add a membership type in CiviMember, the dropdowns all appear behind the lightbox and can't be clicked on. Example in screencap is the Organisation, but the issue is occurring on all dropdowns on this screenhttps://lab.civicrm.org/dev/core/-/issues/3075Possible regression - ContributionRecur.getoptionschanged2023-12-05T05:03:21ZeileenPossible regression - ContributionRecur.getoptionschangedIn 5.47 we have changed the pseudoconstant on ContributionRecur.payment_processor_id to get the title rather than the name. This caused breakage on our site as we have not filled in payment_processor.title so we got an array like
`[1 =...In 5.47 we have changed the pseudoconstant on ContributionRecur.payment_processor_id to get the title rather than the name. This caused breakage on our site as we have not filled in payment_processor.title so we got an array like
`[1 => NULL, 2 => NULL]`
When this was array-flipped it fatalled.
On reflection I'm going to re-write the relevant bit of our code but could it affect others?
payment_processor.title was added to core recently-ish and was optional. It's possible some sites would leave it blank in order to have 'nothing' show on the front end. In which case correctly the pseudoconstant could 'look like' a regression. Or perhaps other sites do what we did.
**The right answer**
I think the 'correct' structure would be to have
name = unique machine name
master_id = way to link test processor to the master
title = display value
frontend_title = as shown on front end pages
The use of frontend_title is consistent with elsewhere (I think Justin pushed for that on other entities) and would get away from the need to use a title like 'Credit card' when you really want 'Eway'.
I suspect switching to using 'master_id' would be a transition rather than a quick change but the use of 'name' for this seems to keep biting us.
**The immediate question**
- does it make sense to add an upgrade to Five Forty Seven `UPDATE civicrm_payment_processor SET title = name WHERE title IS NULL` and / or `UPDATE civicrm_payment_processor SET title = name WHERE title = ''` - or do we think it might break more than it fixes.
@colemanw @seamuslee @mattwire @KarinGhttps://lab.civicrm.org/dev/core/-/issues/3074Unexpected behaviour when trying to skip pledge payment2023-11-25T05:03:17ZBradley TaylorUnexpected behaviour when trying to skip pledge paymentI am currently working with an organisation looking to use CiviPledge. One requirement is that occasionally payments get missed, in which case the client would like the subsequent payment amount to be doubled. Currently the behaviour to ...I am currently working with an organisation looking to use CiviPledge. One requirement is that occasionally payments get missed, in which case the client would like the subsequent payment amount to be doubled. Currently the behaviour to allow this is non-intuative and lacks the flexibility to do exactly what the user wants.
I made a couple of non-successful attempts to try this initially:
**Attempt 1**
My initial assumption was that the table of pledge payments would have a cancel button next to each payment. This does not appear to be the case.
I would have expected such a link, which when clicked I would have expected to ask what I wanted to do with the subsequent payments. Either:
- No change (reduce total pledge payment).
- Add extra payment to extra schedule
- Adjust next payment with rolled amount.
**Attempt 2**
Next I tried to record a payment with an amount of 0. The actual payment was recorded correctly with an amount of 0, but when there is no amount the radio buttons "adjust payment amount" and "Adjust Total Pledge Amount?" appear to have no effect.
**Attempt 3**
Next I tried to record a cancelled payment.
1. Click "record payment" next to a pledge.
2. Set the "Contribution Status" to "Failed"
3. Click save
We now end up in a situation where it is impossible to reach the pledged amount because the price of the cancelled payment is not taken off the pledged amount, and no changes are made to the other pledged payments. Therefore the pledge will never reach the "Completed" status, unless edited via the API.
---
I'm not sure exactly what the solution is here, espcially in terms of the ideal UX, but its clear that as it stands pledges are lacking flexibility to correctly handle missed payments.https://lab.civicrm.org/dev/core/-/issues/3073PledgePayment statuses used doesn't correspond to reported options available.2024-02-25T05:03:21ZBradley TaylorPledgePayment statuses used doesn't correspond to reported options available.When using the API (v3 or v4) a pledgepayment status accepts either "Completed", "Pending", "Cancelled" or "Overdue":
![Screenshot_2022-02-16_at_16.42.18](/uploads/caba9893c1ce8cc706b8285d78050bf4/Screenshot_2022-02-16_at_16.42.18.png)
...When using the API (v3 or v4) a pledgepayment status accepts either "Completed", "Pending", "Cancelled" or "Overdue":
![Screenshot_2022-02-16_at_16.42.18](/uploads/caba9893c1ce8cc706b8285d78050bf4/Screenshot_2022-02-16_at_16.42.18.png)
However, in practice a wider set of values are supported. To demonstrate this:
1. Create a new pledge
2. Mark a payment against the first pledge
3. View the created pledge payment. Click edit and set the payment contribution status to "Refunded". Save the payment.
4. The pledge payment now has a status of "Refunded" which was not one of the statuses shown by the API explorer.
Looking at the config for a pledgepayment I can see that the status field uses the `contribution_status` pseudoconstant. However, in `CRM_Pledge_BAO_PledgePayment::buildOptions` the options are retrieved from `CRM_Pledge_BAO_Pledge::buildOptions` which uses the `pledge_status` pseudoconstant.
I highly suspect `CRM_Pledge_BAO_PledgePayment::buildOptions` should just return the `contribution_status` options, maybe with some of the less relevant options filtered out. It seems mad that internal Civi logic would put a pledgepayment into a state which isn't shown as valid through the API.
It appears the available options are not validated, so if you hand-build the API query it does seem to be possible to use a pledgepayment/contribution_status which does not correspond to one of "Completed", "Pending", "Cancelled" or "Overdue".https://lab.civicrm.org/dev/core/-/issues/3072Proposal: Remove time component from the {contribution.receive_date} token2022-03-31T22:47:07ZDaveDProposal: Remove time component from the {contribution.receive_date} tokenOr provide an alternate token, or at least handle it with smarty in the stock workflow templates. It used to do the latter prior to 5.47: https://github.com/civicrm/civicrm-core/pull/22560/files#diff-fd5668d5492e5f0ec55b7f8a10eccfa4ea9de...Or provide an alternate token, or at least handle it with smarty in the stock workflow templates. It used to do the latter prior to 5.47: https://github.com/civicrm/civicrm-core/pull/22560/files#diff-fd5668d5492e5f0ec55b7f8a10eccfa4ea9de249e4cf2383a2e0d36dbd92ebe0R154
Not marking regression because the token itself isn't a regression and the use in the template is for new installs.5.48.0