Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-03-08T17:14:15Zhttps://lab.civicrm.org/dev/translation/-/issues/24On New Event, allow translations to be entered before first save2019-03-08T17:14:15ZJoeMurrayOn New Event, allow translations to be entered before first saveCurrently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered...Currently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered for any translatable field on any tab.
Proposed enhancement: allow translations to be entered for the text fields on the first form as well, prior to first save.
This enhancement idea is currently unfunded.https://lab.civicrm.org/dev/drupal/-/issues/52Drupal8: getUrlPath: avoid relying on the deprecated 'q' variable2020-05-27T12:49:03ZbgmDrupal8: getUrlPath: avoid relying on the deprecated 'q' variableContext: Symbiotic has an extension for theming that uses this trick to detect whether it's running in a frontend or backend form (to avoid loading our CSS on the frontend):
```
function adminimore_civicrm_config(&$config) {
$path = C...Context: Symbiotic has an extension for theming that uses this trick to detect whether it's running in a frontend or backend form (to avoid loading our CSS on the frontend):
```
function adminimore_civicrm_config(&$config) {
$path = CRM_Utils_System::getUrlPath();
$item = CRM_Core_Menu::get($path);
$resources = CRM_Core_Resources::singleton();
// if item is not known, assume it's public (e.g. wordpress shortcode)
if ($item && !CRM_Utils_Array::value('is_public', $item)) {
$resources->addStyleFile(ADMINIMORE_RESOURCE, 'css/civicrm-admin.css', 15, 'html-header');
$resources->addStyleFile(ADMINIMORE_RESOURCE, 'css/civicrm-buttons.css', 15, 'html-header');
}
$resources->addStyleFile(ADMINIMORE_RESOURCE, 'css/civicrm-menu.css', 15, 'html-header');
_adminimore_civix_civicrm_config($config);
}
```
In Drupal8, we were having weird problems where the CSS would sometimes not load. If we refreshed, it loaded, but after some time, the bug would appear again and we would stumble on a screen using the default CiviCRM CSS.
After some poking around, it seems that Drupal8 deprecated the 'q' variable, which CiviCRM is still using in `CRM_Utils_System::getUrlPath()`.
I did a quick patch to test a workaround, which so far seems to be working:
```
public static function getUrlPath() {
if (CRM_Core_Config::singleton()->userFramework == 'Drupal8') {
if (class_exists('Drupal') && \Drupal::hasContainer()) {
$path = \Drupal::service('path.current')->getPath();
// Remove '/' prefix. Ex: '/civicrm/contribute' becomes 'civicrm/contribute'.
if ($path) {
$path = substr($path, 1);
// Remove the language prefix, if present
// The URL returned by Drupal randomly includes the language prefix, sometimes not.
if (preg_match('/^\w\w\//', $path)) {
$path = substr($path, 3);
}
return $path;
}
}
}
if (isset($_GET[CRM_Core_Config::singleton()->userFrameworkURLVar])) {
return $_GET[CRM_Core_Config::singleton()->userFrameworkURLVar];
}
return NULL;
}
```
A cleaner solution might be to check if the `$config->userSystem->getUrlPath()` function exists, and if it does, call it?https://lab.civicrm.org/dev/translation/-/issues/23Angular asset cache and multi-lingual2024-01-29T10:06:18ZbgmAngular asset cache and multi-lingualAngular extensions, such as CiviMail (classic) or Mosaico, will not always be displayed in the correct language when the Angular asset cache is enabled/auto (Admin > System Settings > Debugging). Tested on Drupal 7 (in case that makes a ...Angular extensions, such as CiviMail (classic) or Mosaico, will not always be displayed in the correct language when the Angular asset cache is enabled/auto (Admin > System Settings > Debugging). Tested on Drupal 7 (in case that makes a different with the "auto" setting of that cache).
How to reproduce on dmaster:
* Make sure you have the civicrm-l10n.tar.gz translation files (it's the case on dmaster.demo.civicrm.org)
* Go to Administer > Localisation, and enable another language, such as French (you don't need to enable multi-lingual).
* Use the CiviCRM Language Switch to set the language to French
* Go to Mailing > New Mailing (classic or mosaico, same bug)
* Now go back to the dashboard, set the language to English
* Go to Mailing > New Mailing, and notice that the UI is still in French.https://lab.civicrm.org/dev/core/-/issues/719can't delete profile pre- post- field help on multilinguage sites2022-08-26T00:20:44ZJoeMurraycan't delete profile pre- post- field help on multilinguage sitesIf you add field pre and post help to profiles on a single language site, you can then delete it and save successfully. On a site with more than 1 language, trying to delete the help leads to it being resaved (I believe from the alternat...If you add field pre and post help to profiles on a single language site, you can then delete it and save successfully. On a site with more than 1 language, trying to delete the help leads to it being resaved (I believe from the alternative language's copy of the help).
Verified on dmaster 5.12.alpha1.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/712Submiting a form to join multiple groups should send one email, not one per g...2022-09-30T18:34:42ZIan KellingSubmiting a form to join multiple groups should send one email, not one per grouphttps://docs.civicrm.org/user/en/latest/email/set-up/ says: "When users
subscribe to multiple groups at once, a confirmation email is sent for
each group separately."
This should be changed to send a single email. They entered their ema...https://docs.civicrm.org/user/en/latest/email/set-up/ says: "When users
subscribe to multiple groups at once, a confirmation email is sent for
each group separately."
This should be changed to send a single email. They entered their email
address 1 time into 1 form, then get multiple emails that ask to confirm
their email address. Some will think that it's unnecessary to click each
link since their email address is confirmed by just clicking one. Some
will think there is a bug in the system. It really just doesn't make
sense to users.https://lab.civicrm.org/dev/financial/-/issues/45Custom fields ignored when searching in "Accounting Batch" mode2019-02-11T21:15:55ZJonGoldCustom fields ignored when searching in "Accounting Batch" modeSteps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
...Steps to replicate on a sandbox server:
* Go into Custom Fields, set **How long have you been a donor?** to be searchable.
* In **Find Contributions**, use **How long have you been a donor?** as a search criteria. Note correct results.
* Go to **Contributions » Accounting Batches » New Batch**. Perform the same search. The custom field criterium is ignored.https://lab.civicrm.org/dev/financial/-/issues/44Modifying contribution amount records a fake payment for difference2019-06-20T19:11:11ZAndie HuntModifying contribution amount records a fake payment for difference1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has be...1. Create a contribution for $50 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new $20 payment by check has been recorded.
There's no way to remove the $20 payment, though you can edit the payment method and so forth.
I suspect this is a consequence of partial payments not being fully implemented for contributions, but the effect is unexpected and undocumented.
Another, more troubling outcome:
1. Create a contribution for $100 on the back end, setting the status as `Pending` and leaving the payment method as `Check`.
2. Record a $90 payment with cash.
3. Edit the contribution amount to be $150.
4. Go back to view the contribution and see that there is now a $50 payment by check with the status "partially paid".
5. Go to record a payment and see that the balance owed is $60. Record that payment with EFT as the payment method.
6. See that the contribution now has three payments, for $90 (Cash), $50 (Check), and $60 (EFT) despite only being for a $150 contribution. A "Record refund" link appears, but clicking it causes an error:
> Sorry but we are not able to provide this at the moment.
Finally, fake negative payments can be recorded:
1. Create a contribution for $100 on the back end, leaving the status as `Completed` and the payment method as `Check`.
2. Edit the contribution to be $70.
3. Go back to view the contribution and see that a new -$30 payment by check has been recorded.https://lab.civicrm.org/dev/financial/-/issues/43Find Contributions searches on inaccurate, redundant payment fields2020-07-09T00:48:18ZAndie HuntFind Contributions searches on inaccurate, redundant payment fieldsThis problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to re...This problem is somewhat related to dev/financial#37 in that there are redundant payment-related fields on the contribution record. That issue covers a record updating problem--when the contribution record isn't updated accurately to reflect the payment information. This issue is that the Find Contributions search looks only for the value in the contribution record.
When there are multiple payments by check, the check number field on the contribution is updated to have both numbers, separated by a comma. So, the check number is `111,222` if the first check is `111` and the second is `222`. Searching for a contribution with check numbers `111` or `222` will yield nothing, but searching for `111,222` finds it. Obviously this is a bug, but it might properly be considered a bug in search--the search should look among the payments, not the value on the contribution.
Again, like dev/financial#37, the real solution is to ditch the redundant fields. However, in the meantime we should stop relying upon them.
It appears that card number works properly:
* Record contribution, pending pay later (setting payment method to be `Credit Card` to sidestep the problem in dev/financial#37)
* Record payment for part of the amount, payment method `Credit Card` with the card ending in `1234`
* Record payment for the remainder of the amount, payment method `Credit Card` with the card ending in `6789`
* Find contributions, payment method `Credit Card`, card number `1234`, retrieves the contribution.
* Find contributions, payment method `Credit Card`, card number `6789`, retrieves the contribution.
Since there is no card number on the contribution, the search is forced to work the right way.https://lab.civicrm.org/dev/financial/-/issues/41PSD2 support needed for PayPal by Sept 20192019-07-22T22:24:16ZAndrew WestPSD2 support needed for PayPal by Sept 2019PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other p...PayPal will require PSD2 support by September 2019 - in Europe, anyway (https://www.paypal.com/uk/webapps/mpp/psd2). So Civi will need to support SCA via 3-D Secure when using PayPal - Website Payments Pro (and presumably for any other payment methods where Civi hosts the payment fields). In practice I think this'll mean an intermediary page after payment, where people can verify their card details.
We are happy to chip in on development of this, but we can't fund it entirely.https://lab.civicrm.org/dev/backdrop/-/issues/37Warnings when using Webform CiviCRM with "Checkboxes (live)" widget2022-10-24T21:33:01ZbgmWarnings when using Webform CiviCRM with "Checkboxes (live)" widget*Created by: laryn*
Follow-up issue from https://github.com/civicrm/civicrm-backdrop/issues/55
When testing `webform_registration`, I see these in the log (the pair of warnings is in there twice, actually):
`Warning: array_keys() expe...*Created by: laryn*
Follow-up issue from https://github.com/civicrm/civicrm-backdrop/issues/55
When testing `webform_registration`, I see these in the log (the pair of warnings is in there twice, actually):
`Warning: array_keys() expects parameter 1 to be array, string given in CRM_Core_BAO_CustomGroup::postProcess() (line 1539 of /path/modules/civicrm/CRM/Core/BAO/CustomGroup.php).`
`Warning: implode(): Invalid arguments passed in CRM_Core_BAO_CustomGroup::postProcess() (line 1541 of /path/modules/civicrm/CRM/Core/BAO/CustomGroup.php).`https://lab.civicrm.org/dev/financial/-/issues/39Authorize.net doesn't support MD5 hashing at the end of the month2019-07-02T14:40:29ZJonGoldAuthorize.net doesn't support MD5 hashing at the end of the monthI just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Ex...I just saw this on [Stack Exchange](https://civicrm.stackexchange.com/q/28025/12). It seems rather urgent, since it will be a breaking change for users. I'm guessing that February 1st we'll see a lot of questions about this on Stack Exchange.
> Authorize.Net is phasing out the MD5 based transHash element in favor
> of the SHA-256 based transHashSHA2. The setting in the Merchant
> Interface which controls the MD5 Hash option will be removed by the
> end of January 2019, and the transHash element will stop returning
> values at a later date to be determined.
>
> Merchants utilizing this feature will need to work with their web
> developer or solutions provider to verify if they are still utilizing
> MD5 based hash and if still needed to move to SHA-256 hash via
> Signature Key.https://lab.civicrm.org/dev/core/-/issues/661Membership receipts do not display Credit Card information2023-11-23T07:09:32ZcommonpikeMembership receipts do not display Credit Card informationFrom https://issues.civicrm.org/jira/browse/CRM-18027
(also https://civicrm.stackexchange.com/questions/15150)
Most of the issues mentioned there seem to be solved in 5.8.1, however, Credit Card information is still not showing up (and ...From https://issues.civicrm.org/jira/browse/CRM-18027
(also https://civicrm.stackexchange.com/questions/15150)
Most of the issues mentioned there seem to be solved in 5.8.1, however, Credit Card information is still not showing up (and leaving strange blanks in the email).
**To reproduce issue:**
1. Register as a new, paying, member, using Credit Card
2. Read the e-mail sent as 'Receipt - Membership signup'
**Details**
In the system template "Memberships - Receipt (on-line)",
in the latest default,
where the source, in the text version, says
```
===========================================================
{ts}Credit Card Information{/ts}
===========================================================
{$credit_card_type}
{$credit_card_number}
{ts}Expires{/ts}: {$credit_card_exp_date|truncate:7:''|crmDate}
{/if}
```
the generated output is
```
===========================================================
Credit Card Information
===========================================================
Expires:
```
The HTML version and the PDF have the same problem.
![Screen_Shot_2019-01-11_at_14.25.50](/uploads/95b1c84df44d3003a81cb93b8b2d79ee/Screen_Shot_2019-01-11_at_14.25.50.png)https://lab.civicrm.org/dev/financial/-/issues/38Support paying refunds2020-12-05T20:23:27ZJoeMurraySupport paying refundsSee https://lab.civicrm.org/dev/financial/wikis/Refunds-via-payment-processorsSee https://lab.civicrm.org/dev/financial/wikis/Refunds-via-payment-processorsJoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/37Can't search by check number for checks entered with "Record Payment"2021-10-19T05:02:37ZJonGoldCan't search by check number for checks entered with "Record Payment"Someone reported this [on Stack Exchange](https://civicrm.stackexchange.com/q/27989/12), and it's pretty easy to replicate with their steps: "when you edit a pending pay later contribution, add a check number, change status to complete a...Someone reported this [on Stack Exchange](https://civicrm.stackexchange.com/q/27989/12), and it's pretty easy to replicate with their steps: "when you edit a pending pay later contribution, add a check number, change status to complete and then i go to search contributions, enter the payment method and search by check number i get no result."
`check_number` is a field both in `civicrm_contribution` and `civicrm_financial_trxn`. I suspect this is for historical reasons rather than anything anyone considers correct in 2019.
* To solve the immediate issue, "Find Contributions" should search the check number field of related financial transactions rather than the contribution itself.
* I think there's a strong argument that `civicrm_contribution.check_number` should be deprecated altogether, but that's a much larger issue.https://lab.civicrm.org/dev/core/-/issues/600Word Replacements: entering a string with HTML will reset all replacements2023-04-12T20:56:13ZbgmWord Replacements: entering a string with HTML will reset all replacementsHow to reproduce:
* On a single language site, go to Administer > Customize data and screen > Word Replacements
* Enter a few replacements, it doesn't matter if they are valid.
* Save, so far so good.
Then add a new replacement with ht...How to reproduce:
* On a single language site, go to Administer > Customize data and screen > Word Replacements
* Enter a few replacements, it doesn't matter if they are valid.
* Save, so far so good.
Then add a new replacement with html: `<p>test</p>`, and click save.
Result: word replacements table will be completely empty.
I debugged a bit and this is because `CRM_Core_BAO_WordReplacement.php::getConfigArraysAsAPIParams()` uses `unserialize` on the strings that are stored in `civicrm_domain` (ugh). The unserialize fails because of the HTML, so it returns FALSE, and the function ends up returning an empty array, which is then used to re-populate the `civicrm_word_replacement` table.https://lab.civicrm.org/dev/core/-/issues/3301Contrast ratios2024-02-28T11:51:33ZJoeMurrayContrast ratiosWCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.h...WCAG 2.0 specifies various minimum contrast ratios between foreground and background for different sizes of fonts, and for bolded and non-bolded fonts [https://www.w3.org/TR/WCAG20-TECHS/G18.html](https://www.w3.org/TR/WCAG20-TECHS/G18.html).
> ...Priority 2 (AA), and Priority 3 (AAA). Whether or not you need to reach an AAA conformance depends on your target audience. Read more about this [on the w3 site](http://www.w3.org/TR/2005/WD-WCAG20-20051123/intro.html#conformance). For large text (over 18 points) the contrast ratio for AA is 3:1 and for AAA 5:1. For small text it's 5:1 for AA and 7:1 for AAA. ([http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer](http://www.colorsontheweb.com/Color-Tools/Color-Contrast-Analyzer))
More exact ratios and translations of font sizes to px directly from the WCAG first mentioned for bold and non-bold text are:
* **BOLD and < 14pt (18.5px):** 7:1 contrast ratio
* Not bold and < 18pt (24px): 7:1 contrast ratio
*
* **BOLD and >= 14pt (18.5px):** 4.5:1 contrast ratio
* Not bold and >= 18pt (24px): 4.5:1 contrast ratio
Using the contrast analyzer provided on the page above, the current Shoreditch contrast ratios are not sufficient in some contexts.
For example, on pages like New Contact and New Activity we get the following ratios:
Blue font #2786c2 on tan #efefe5 in 13px: 3.44:1 (below 5:1)
Dimmed grey #999999 on offwhite #fff in 13px: 2.85:1 (below 5:1)
![2018-12-04_09-16-41](/uploads/efe32b9def1089f434b0cf1c11ef1b6e/2018-12-04_09-16-41.png)
![2018-12-04_09-33-52](/uploads/171119a46775a677bd44664497507def/2018-12-04_09-33-52.png)
![2018-12-04_09-51-12](/uploads/1a9006ebddb3d210f2b326d41d29f8cc/2018-12-04_09-51-12.png)
We should meet a 5:1 ratio for all text < 18pt.https://lab.civicrm.org/dev/core/-/issues/470Current employer dissapears when disabling expired relationships2024-03-15T18:12:06ZfrancescbassasCurrent employer dissapears when disabling expired relationshipsOriginal issue: https://issues.civicrm.org/jira/browse/CRM-21851
Affected versions: at least from 5.0.0
---
How to reproduce:
1) Create a current relationship on individual A as *employee of* organization B and mark as *current emplo...Original issue: https://issues.civicrm.org/jira/browse/CRM-21851
Affected versions: at least from 5.0.0
---
How to reproduce:
1) Create a current relationship on individual A as *employee of* organization B and mark as *current employer*
2) Create a past relationship on individual A as *employee of* organization B without marking as current employer
At this point on summary tab of individual A appears organization B as his Employer.
3) Run *Disable expired relationships* cron job
At this point on summary tab there is no organization at Employer field although there is one active employee relationship and past relationship was disabled.5.17.0https://lab.civicrm.org/dev/core/-/issues/464Disabling "Search Primary Details Only" breaks export of primary address2023-06-16T21:12:50ZmfbDisabling "Search Primary Details Only" breaks export of primary addressMigrated from https://issues.civicrm.org/jira/browse/CRM-21423
Disabling the "Search Primary Details Only"* setting switch leads to wrong export of contact primary address.
Reason is that a requested location_type is not set and Export...Migrated from https://issues.civicrm.org/jira/browse/CRM-21423
Disabling the "Search Primary Details Only"* setting switch leads to wrong export of contact primary address.
Reason is that a requested location_type is not set and Export.php's call to CRM_Contact_BAO_Query does not set the default search to use primary location.
A fix was proposed at https://github.com/civicrm/civicrm-core/pull/11274 but has been closed as more tests would need to be written.
\* My anecdotal experience is that, if the user has been merging contacts w/ multiple email addresses such that secondary email addresses are fairly common, then there's a frequent need to search across all email addresses, so this setting does need to be disabled.https://lab.civicrm.org/dev/financial/-/issues/32Authorize.net Fees Not Reflected In Civi2019-01-12T19:07:11ZguyiacAuthorize.net Fees Not Reflected In CiviWhen credit card payments are made using the Authorize.net payment processor packaged natively in Civi, the credit card fees are not fed back from Authorize to Civi, and as a result do not show up in Civi. This was brought forward by one...When credit card payments are made using the Authorize.net payment processor packaged natively in Civi, the credit card fees are not fed back from Authorize to Civi, and as a result do not show up in Civi. This was brought forward by one of my clients (Helena Carvalho of AHCC) during the accounting integration presentation at CiviCamp Hartford, and confirmed by Brian Shaughnessy right after the presentation.https://lab.civicrm.org/dev/core/-/issues/411Default currency shown on forms if payment is made with different currency2023-11-23T07:47:00ZjitendraDefault currency shown on forms if payment is made with different currencyDefault currency shown on View participant and contribution page if payment is made with different currency
Steps to reproduce -
- Create a priceset with some price fields.
- Create a contribution page with currency = EUR or any other ...Default currency shown on View participant and contribution page if payment is made with different currency
Steps to reproduce -
- Create a priceset with some price fields.
- Create a contribution page with currency = EUR or any other currency other than the default USD.
- Create a payment by submitting the contribution page.
- The payment shown on the contact summary page stated in USD even though it should have been taken in EUR.
Similarly, default currency is shown for participants registered for the event using EUR.
---
There are still 102 matches found where similar formatting is done.
```
$ grep -irn "crmMoney}" templates/ | wc -l
102
```
We need to fix all instances in core.
Ref https://github.com/civicrm/civicrm-core/pull/12875 for the first fixjitendrajitendra