Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-08-21T14:30:02Zhttps://lab.civicrm.org/dev/user-interface/-/issues/29Rewording of the "state" selector?2020-08-21T14:30:02ZsudomanRewording of the "state" selector?Some people not living in the US are confused or annoyed that it is required to select the "state" that they live in, since the listed options are municipalities in their country / state, and they might only recognized them as being near...Some people not living in the US are confused or annoyed that it is required to select the "state" that they live in, since the listed options are municipalities in their country / state, and they might only recognized them as being nearby cities. To them, the language seems American-centric.
One possible change could be:
````
- State/Province
+ State/Province/Region/Municipality
````
Thanks! : )https://lab.civicrm.org/dev/financial/-/issues/142Order api proposal - require less line item parameters2020-12-03T10:37:27ZeileenOrder api proposal - require less line item parametersI'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technica...I'd like to propose that we add sensible defaults for line items when using the order api
1) price_field_id - if NONE of the rows have a price_field_id then use the default pricefield id for all of them (I don't want to open up technical analysis of dealing with multiple price sets, more complex config) - so this is just for that common use case
2) qty - if not set, default to 1
This would make the minimum required params for a 'quick config' (I hate that usage but I think we know what it means) order
```
$this->callAPISuccess('Order', 'create', [
'financial_type_id' => 'Donation',
'contact_id' => $contact1,
'line_items' => [
['line_item' => [
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Donation'),
'line_total' => 40,
],
[
'financial_type_id' => CRM_Core_PseudoConstant::getKey('CRM_Contribute_BAO_Contribution', 'financial_type_id', 'Member Dues'),
'line_total' => 50,
],
]],
]
]);
```
Ideally we would also accept
```
'financial_type_id' =>'Donation',
```https://lab.civicrm.org/dev/core/-/issues/1984Sometimes Custom fields missing on profile2023-06-05T20:22:11ZPradeep Nayakpradpnayak@gmail.comSometimes Custom fields missing on profileCustom fields are not rendered on profile front end pages like contribution or event pages. As soon as civi cache is cleared they start appearing.
```
Php - 7.3
opcahe disabled
Clean-up Temporary Data and Files schedule job executed hou...Custom fields are not rendered on profile front end pages like contribution or event pages. As soon as civi cache is cleared they start appearing.
```
Php - 7.3
opcahe disabled
Clean-up Temporary Data and Files schedule job executed hourly by cron job
```https://lab.civicrm.org/dev/wordpress/-/issues/74IPN/webhook URLs should not be localized2020-09-04T10:33:07Zmattwiremjw@mjwconsult.co.ukIPN/webhook URLs should not be localizedOn a site with polylang enabled Stripe displays an error that the webhook path is not setup correctly because it returns the first, default locale URL.
Example: https://sitename.org/en/civicrm/payment/ipn/1/
But the non-localized https...On a site with polylang enabled Stripe displays an error that the webhook path is not setup correctly because it returns the first, default locale URL.
Example: https://sitename.org/en/civicrm/payment/ipn/1/
But the non-localized https://sitename.org/civicrm/payment/ipn/1/ also works as well as other locales.
Calls to `CRM_Utils_System::url()` generate a localized URL and there doesn't seem to be a way to ask for a specific locale (or default) - see https://lab.civicrm.org/extensions/mjwshared/-/blob/master/CRM/Mjwshared/WebhookTrait.php#L27
Not sure what the solution is here - @haystack @kcristiano - it causes Stripe to display errors about webhook configuration when it doesn't need to. Updating the webhook works too but is not actually necessary.https://lab.civicrm.org/dev/financial/-/issues/143Convert core processors to use Guzzle and bring them under CI2020-09-05T01:27:07ZeileenConvert core processors to use Guzzle and bring them under CISubtask of https://lab.civicrm.org/dev/financial/-/issues/132Subtask of https://lab.civicrm.org/dev/financial/-/issues/132https://lab.civicrm.org/dev/financial/-/issues/144Figure out if core processors actually work.....2022-05-19T22:31:00ZeileenFigure out if core processors actually work.....The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by...The processors we currently ship with core are
| Processor | status|
| ------ | ------ |
| Authorize.net | works/tested |
| Elavon| broken? |
| Eway| works/tested/ converted to an extension |
| FirstData| broken? (Reported as working by Brian Civi Version not mentioned) |
| PayflowPro| broken? (Reported as working as of 5.19 by Nicholas) (As of 5.38 Migrated to a core extension with unit tests) |
| PaymentExpress| definitely broken / removed|
| PayJunction| broken? |
| Paypal| works/tested |
| Realex| likely works, have seen gitlabs |
I think we should try to find out about the ones that might be broken with a view to either
1) bring them under CI & move to an extension (per Eway) OR
2) remove them from core
Other than pinging people like @lcdweb to see if they use any my other idea is to add a check or preUpgrade message to try to get people to let us know.
@seamusleehttps://lab.civicrm.org/dev/drupal/-/issues/139Drupal8: ckeditor, unable to upload images to event info2020-09-30T17:43:55ZAlanDixonDrupal8: ckeditor, unable to upload images to event infoSimilar to https://lab.civicrm.org/dev/drupal/-/issues/77
I can fix it the same way (add a .htaccess the undoes Drupal's inherited rewrite), but curious whether there's a nicer solution similar to 77's solution, or whether these ckedito...Similar to https://lab.civicrm.org/dev/drupal/-/issues/77
I can fix it the same way (add a .htaccess the undoes Drupal's inherited rewrite), but curious whether there's a nicer solution similar to 77's solution, or whether these ckeditor direct access issues should be addressed in a different way altogether?https://lab.civicrm.org/dev/drupal/-/issues/140Improvement in member role sync to avoid unnecessary role remove and role rea...2020-09-15T18:42:04ZsadashivImprovement in member role sync to avoid unnecessary role remove and role reassignIf we turn on civicrm member role sync module and configure the membership to sync to a role then system removes the role and reassigns it when the sync function is invoked.
Steps to replicate:
1) Create a Membership type
2) Create a ro...If we turn on civicrm member role sync module and configure the membership to sync to a role then system removes the role and reassigns it when the sync function is invoked.
Steps to replicate:
1) Create a Membership type
2) Create a role in drupal
3) Enable civicrm_member_roles module
4) Configure the member role rule to add the new role on proper status of the membership
5) Configure the membership role to sync on user login or logout
6) Create a new membership for any user (note that the user now doesn't have the new role)
7) Login as the user (note that the user now has the role assigned)
8) Logout
If we see the code in the module it has a db_delete to delete the role assignment and then more code to reassign the role back, and these actions are performed on login or logout. This can be improved by not deleting the role and not saving the user again if there is no change required. This can be a improvement and will save few overhead on queries and on login/logout.
Thanks,
Sadashiv.https://lab.civicrm.org/dev/financial/-/issues/145Adding "standard" params to propertyBag2020-09-16T00:42:12Zmattwiremjw@mjwconsult.co.ukAdding "standard" params to propertyBagThis came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor th...This came out of https://github.com/civicrm/civicrm-core/pull/18425 and https://github.com/civicrm/civicrm-core/pull/17595.
Specifically, adding "standard" parameters to propertyBag when they are already in use by a payment processor that has been converted to use propertyBag is likely to break existing implementations.
Accessing params that are later added as "standard" params to propertyBag when a payment processor is already converted internally to propertyBag (eg. most of the ones written by me Stripe, authnetecheck, Smartdebit).
Example Issues:
- authnetecheck accesses `$params['credit_card_number']` which disappears once mapped to a propertyBag because only the standardised `cardNumber` field is available.
- If authnetecheck was using `$propertyBag->getCustomProperty('credit_card_number')` it would throw an "InvalidArgumentException" because you are not allowed to use `getCustomProperty` for a "standard" property.
Similar issues will apply to any other properties that are already in use by a payment processor.
@eileen @artfulrobot @seamuslee @tottenhttps://lab.civicrm.org/dev/financial/-/issues/146alterPaymentProcessorParams hook and propertyBag2020-09-15T15:35:00Zmattwiremjw@mjwconsult.co.ukalterPaymentProcessorParams hook and propertyBagSee https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all t...See https://github.com/civicrm/civicrm-core/pull/17507#issuecomment-690213686:
> 1. pass property bag to alterPaymentProcessorParams
>
> - ✔ the hook gets to deal with sensible, known data and does not have to (re-)implement all the quirks of checking different array keys for one thing.
> - ✔ any setting the hook does in a prop bag ensures forward consistency for the next process in the chain (another hook or the main process)
> - ✖ It's possible that the reason for a hook is something pretty darn weird needs doing; in which case the raw array may be more useful.
>
> 2. pass the original array to the hook
>
> - ✖ hook has to do all work arounds
> - ✖ hook is free to implement bad practise in altering the array
> - ✔ hook can do whatever it likes.
>
> I think (1).
And example from Stripe where we're currently passing an array for compatibility (but this should not be used as a model as Stripe ignores the return values from the hook anyway).
https://lab.civicrm.org/extensions/stripe/-/blob/master/CRM/Core/Payment/Stripe.php#L484-489
// @fixme DO NOT SET ANYTHING ON $propertyBag or $params BELOW THIS LINE (we are reading from both)
$params = $this->getPropertyBagAsArray($propertyBag);
// We don't actually use this hook with Stripe, but useful to trigger so listeners can see raw params
$newParams = [];
CRM_Utils_Hook::alterPaymentProcessorParams($this, $params, $newParams);https://lab.civicrm.org/dev/translation/-/issues/50Locale-aware recaptcha2020-12-14T04:07:55Zmattwiremjw@mjwconsult.co.ukLocale-aware recaptchaThe library in use by CiviCRM is a *very* old version and is not locale-aware. See https://civicrm.stackexchange.com/questions/11533/recaptcha-update-language/37503 for more info.
We should update the library and make recaptcha in CiviC...The library in use by CiviCRM is a *very* old version and is not locale-aware. See https://civicrm.stackexchange.com/questions/11533/recaptcha-update-language/37503 for more info.
We should update the library and make recaptcha in CiviCRM respect the locale of the form.https://lab.civicrm.org/dev/core/-/issues/2021Contribution receipt has donor's name printed twice, once with non-printable ...2023-11-23T07:22:03ZBobSContribution receipt has donor's name printed twice, once with non-printable charactersOverview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
...Overview
----------------------------------------
Contribution receipts, notably those created with the Stripe extension, display the donor's information as follows:
```
Jane�Mary�Smith <$first . \x01 . $middle . \x01 . $last>
Jane Mary Smith <$first . \x20 . $middle . \x20 . $last>
123 Main St
...
```
The two \x01 characters (ASCII SOH, CRM_Core_DAO::VALUE_SEPARATOR) are displayed as boxes in some email clients, although they aren't displayable in this bug report.
The message template "Contributions - Receipt (on-line)" includes:
```
{if $billingName}
<tr>
<th {$headerStyle}>
{ts}Billing Name and Address{/ts}
</th>
</tr>
<tr>
<td colspan="2" {$valueStyle}>
{$billingName}<br />
{$address|nl2br}<br />
{$email}
</td>
</tr>
{elseif $email}
```
For Stripe contributions, $billingName contains the first/middle/last names separated by SOH characters, as found in civicrm_address.name. The {if $billingName} block therefore gets printed, including both $billingName and the $address variable which contains the second instance of the donor's name, followed by their address.
The SOH characters in the first line of $address (the donor's name) are replaced with spaces in CRM_Core_BAO_Address::addDisplay().
Contributions via Paypal standard, in contrast, do not display the $billingName block as addresses created that way store NULL in civicrm_address.name.
Reproduction steps
----------------------------------------
1. Create a contribution with CiviCRM Stripe extension v. 6.4.2.
1. Observe the Billing Name and Address section of the emailed receipt.
Current behaviour
----------------------------------------
The donor's name is printed twice. Once with SOH separators, and again with spaces. If the middle name is blank, the second instance contains two spaces between first and last name.
Expected behaviour
----------------------------------------
The name should be printed once, with a single space between non-blank name components.
Additional comments
----------------------------------------
1. Perhaps the fix is to simply remove "$billingName\<br \/\>" from the template(s). Ideally, the double spaces in the case of a null middle name should be corrected also.
2. Event and Membership templates seem to have the same structure as the template shown above.
3. The Thank You page displays the donor's name as expected -- only once, with a single \x20 character between first and last name.
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. -->
* __CiviCRM:__ 5.28.2
* __CiviCRM Stripe extension__ v. 6.4.2
* __mjwshared extension__ v. 0.8.1
* __PHP:__ 7.3
* __CMS:__ Drupal 7.72https://lab.civicrm.org/dev/core/-/issues/2048Rename crmStripAlternatives function and its friend CRM_Utils_String::stripAl...2023-05-05T14:13:30ZDaveDRename crmStripAlternatives function and its friend CRM_Utils_String::stripAlternativesIt's not used much at least in core, and it's not clear from the name what it does, and there's potential for it to be mistaken as a security function.
I'd suggest something like getFirstEmailMultipart or stripAlternativeEmailMultiparts.It's not used much at least in core, and it's not clear from the name what it does, and there's potential for it to be mistaken as a security function.
I'd suggest something like getFirstEmailMultipart or stripAlternativeEmailMultiparts.https://lab.civicrm.org/dev/financial/-/issues/150civicrm/payment/form url got empty currency argument in backoffice live CC form2021-07-07T08:47:08ZMonish Debcivicrm/payment/form url got empty currency argument in backoffice live CC formThis affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayme...This affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayments.civicrm)
2. Add and configure an iATS Payments ACH/EFT payment type payment processor.
3. Enable USD and CAD currencies
4. Go to 'Submit Credit Card Contribution' backoffice form
5. Choose payment processor created at step 2
Issue:
1. Payment block renders payment block with check template
2. Switching currency doesn't update the payment block.
For more detail discussion on MM - https://chat.civicrm.org/civicrm/pl/ixxrxhxs43r4mfyjpnf6tnwnnc
ping @KarinG @eileen @JoeMurray @seamuslee5.31.0Monish DebMonish Debhttps://lab.civicrm.org/dev/translation/-/issues/53Frequency units frequently fail to be translated properly2023-11-23T07:20:57ZStéphane Lussierstephane@symbiotic.coopFrequency units frequently fail to be translated properlyOn numerous occasions, the internal value of frequency units (eg: year, month) are sent for display to a template without being translated first.
One such issue may be found in [CRM/Contribute/Form/Contribution/Main.php](https://lab.ci...On numerous occasions, the internal value of frequency units (eg: year, month) are sent for display to a template without being translated first.
One such issue may be found in [CRM/Contribute/Form/Contribution/Main.php](https://lab.civicrm.org/dev/core/-/blob/master/CRM/Contribute/Form/Contribution/Main.php#L550). In this case, a simple fix would usually suffice:
```patch
--- a/civicrm/CRM/Contribute/Form/Contribution/Main.php
+++ b/civicrm/CRM/Contribute/Form/Contribution/Main.php
@@ -548,7 +548,7 @@ class CRM_Contribute_Form_Contribution_Main extends CRM_Contribute_Form_Contribu
if (!empty($form->_values['is_recur_interval']) || $className == 'CRM_Contribute_Form_Contribution') {
$unit .= "(s)";
}
- $form->assign('frequency_unit', $unit);
+ $form->assign('frequency_unit', ts($unit));
}
else {
$form->assign('one_frequency_unit', FALSE);
```
However, this patch in incomplete. There are multiple cases where a similar fix would need to be applied.
It's also not uncommon to find singular/plural tests in existing templates. The following example comes from [templates/CRM/Contribute/Form/Contribution/ThankYou.tpl](https://lab.civicrm.org/dev/core/-/blob/master/templates/CRM/Contribute/Form/Contribution/ThankYou.tpl#L123):
```smarty
{if $frequency_interval > 1}
<strong>{ts 1=$frequency_interval 2=$frequency_unit}This membership will be renewed automatically every %1 %2(s).{/ts}</strong>
{else}
<strong>{ts 1=$frequency_unit}This membership will be renewed automatically every %1.{/ts}</strong>
{/if}
```
This solution looks a bit strange to me... It assumes that adding an `(s)` to an internal keyword will make it plural. That may work in most situations, but it would prevent the already translated keyword to be altered upon the phrase translation.
Shouldn't the keyword be fully translated _and_ pluralized (if necessary) _before_ being sent to the translation string?
Could the `ts` function take care of translating and pluralizing substrings?
I don't mean to make a huge issue out of a small one, but I wonder: Is there a pattern that we can agree on for these sorts of situations?https://lab.civicrm.org/dev/core/-/issues/2072Why does composer.json contain `"include-path": ["vendor/tecnickcom"]`2023-05-10T12:51:31ZDaveDWhy does composer.json contain `"include-path": ["vendor/tecnickcom"]`As per https://lab.civicrm.org/extensions/cdntaxreceipts/-/issues/110#note_47514 it seems to cause issues with extensions that try to use TCPDF in drupal 8 since composer creates a vendor/composer/include_paths.php file that then makes t...As per https://lab.civicrm.org/extensions/cdntaxreceipts/-/issues/110#note_47514 it seems to cause issues with extensions that try to use TCPDF in drupal 8 since composer creates a vendor/composer/include_paths.php file that then makes the path relative to /vendor/civicrm/civicrm-core, instead of relative to just /vendor.
Maybe the line was from an early iteration of autoloading and using composer?https://lab.civicrm.org/dev/drupal/-/issues/142D8/D9 - Define composer upgrade test protocol2020-10-22T04:39:49ZtottenD8/D9 - Define composer upgrade test protocolWith composer-based distribution, there's an extra dimension/risk that you don't see in D7/WP/BD distribution -- Civi and Drupal build on some of the same packages (eg `symfony/*`), and they pull in various plugins, and the different tem...With composer-based distribution, there's an extra dimension/risk that you don't see in D7/WP/BD distribution -- Civi and Drupal build on some of the same packages (eg `symfony/*`), and they pull in various plugins, and the different templates have different conventions. It is entirely plausible for problems to sneak into the dependency-graph that are then awkward for system-implementers to resolve.
During the test/review/RC processes, we currently run [upgrade tests to check the DB-update procedure](https://github.com/civicrm/civicrm-upgrade-test/) against a range of older DB versions. This would be a sort of parallel for checking the composer-code-update procedure.
Ideally, as part of the release-cycle, one might run an upgrade-matrix. Example:
| Drupal Template | Drupal Version | CiviCRM Old Version | CiviCRM New Version |
| -- | -- | -- | -- |
| `drupal-composer/drupal-project` | `8.7.0` | `5.27.0` | `5.31.0` |
| `drupal/legacy-project` | `8.8.0` | `5.29.0` | `5.31.0` |
| `drupal/recommended-project` | `8.9.0` | `5.28.0` | `5.31.0` |
| `drupal/recommended-project` | `9.0.0` | `5.29.0` | `5.31.0` |
Of course, there are a huge number of permutations, and we're not gonna test all of them, but it would be appropriate to ensure that several distinct (in each column) do get tested.https://lab.civicrm.org/dev/core/-/issues/2074Case activity assignees receive an email copy every time activity is edited2023-05-16T12:45:13ZDaveDCase activity assignees receive an email copy every time activity is editedNot sure yet when this changed. It used to only send newly added assignees an email. Investigating...Not sure yet when this changed. It used to only send newly added assignees an email. Investigating...https://lab.civicrm.org/dev/user-interface/-/issues/31Clicking the browser's back button on Profile search results page removes sel...2020-10-01T13:24:02Zdarren.woodsClicking the browser's back button on Profile search results page removes selected Option from Select listCiviCRM 5.29.0 Wordpress 5.5.1
Steps to recreate:-
1) Open a Profile Page in "Search" mode (The Profile should contain a Select type field).
2) Select an Option from the list and click Search button.
3) Click browser's back button when ...CiviCRM 5.29.0 Wordpress 5.5.1
Steps to recreate:-
1) Open a Profile Page in "Search" mode (The Profile should contain a Select type field).
2) Select an Option from the list and click Search button.
3) Click browser's back button when results shown.
Expected result: All the Select list Options should be in the drop down list.
Actual result: The selected Option is not shown in the list.
Workaround: Rather than clicking the browsers' back button, users can click the "Edit search criteria" from the Profile search results page. This will show all the drop down list options as expected.
Appreciate this is a low priority bug, with a logical workaround, but would be nice to fix if it's not too much effort.https://lab.civicrm.org/dev/core/-/issues/2081Proposal: Extension upgrades should reconcile managed entities2023-01-19T22:49:26ZJonGoldProposal: Extension upgrades should reconcile managed entitiesWhen you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension up...When you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension upgrade, we run this code.
Recently, I've had two different extensions fail to work on deployment because the upgrade process doesn't reconcile managed entities. I imagine I'm not alone.