Development issueshttps://lab.civicrm.org/groups/dev/-/issues2018-06-19T00:54:38Zhttps://lab.civicrm.org/dev/core/-/issues/191Export Fails when Gender Label is over 16 characters2018-06-19T00:54:38ZDavid HayesExport Fails when Gender Label is over 16 charactersWe use a longer gender labels/desc. Some of these are over 16 characters. When CiviCRM creates the temporary export table it create the gender_id column as a varchar(16). This causes the export to crash. Looks like this may have been an ...We use a longer gender labels/desc. Some of these are over 16 characters. When CiviCRM creates the temporary export table it create the gender_id column as a varchar(16). This causes the export to crash. Looks like this may have been an issue with suffix_id and prefix_id at one point as they are accounted for in CRM/Export/BAO/Export.php.
Going to submit a pull request to fix this issue.https://lab.civicrm.org/dev/core/-/issues/192Search builder fails for != smart group filter2018-12-17T20:07:12ZjitendraSearch builder fails for != smart group filter- Create a smart group.
- Open Search Builder and add this filter - Contacts -> Group -> !- -> Smart group
The != operator is ignored and the result will list all contacts belonging to the above smart group instead of excluding them.- Create a smart group.
- Open Search Builder and add this filter - Contacts -> Group -> !- -> Smart group
The != operator is ignored and the result will list all contacts belonging to the above smart group instead of excluding them.5.10Monish DebMonish Debhttps://lab.civicrm.org/dev/financial/-/issues/21Invoice Address blocks is missing country2018-07-10T11:09:34ZmvuInvoice Address blocks is missing countryWhen downloading invoice in the latest version, it is missing the country in the from-address block, see attached sample
[INV_16.pdf](/uploads/27ba68f60955365957a907c3fe342a2a/INV_16.pdf).
I have checked the following:
* Country field...When downloading invoice in the latest version, it is missing the country in the from-address block, see attached sample
[INV_16.pdf](/uploads/27ba68f60955365957a907c3fe342a2a/INV_16.pdf).
I have checked the following:
* Country field filled in contact record - yes
* Address block is set to billing - yes
* Message template - there is no $country added, but when I try to add it, it still doesn't render the country of the contact.
Have checked on latest 5.x and traced back up to 4.6.x and the issue is there, can you let us know how to proceed?https://lab.civicrm.org/dev/core/-/issues/193Order API Throw an error when adding tax amount on line items2018-11-15T08:11:29Zomar_compucorpOrder API Throw an error when adding tax amount on line itemsOrder API not factoring in tax amounts when comparing against contribution total.
*Overview:*
When creating an Order using Order API a check is done to compare Contribution's total_amount against the sum of line item's line_total's. If ...Order API not factoring in tax amounts when comparing against contribution total.
*Overview:*
When creating an Order using Order API a check is done to compare Contribution's total_amount against the sum of line item's line_total's. If Contribution total amount and Line Items' total are not equal, Order creation will fail.
As we know:
1. The line item line_total *do not* include any tax. Tax will be recorded separately in line item tax_amount field.
2. The contribution total_amount *do* include tax. A separate contribution tax_amount field also records the amount of tax.
Since the validation only compares the sum of line_totals with contribution total_amount, whenever there is tax, the validation will fail.
For illustration consider following data set that should create 1 contribution with 2 line items for memberships.
```
order_data =
{
'is_pay_later': True,
'contact_id': 240L,
'payment_instrument_id': 6,
'line_items': [{
'line_item': {
'42': {
'price_field_value_id': 60L,
'price_field_id': 36L,
'entity_id': 1249L,
'tax_amount': 2.0,
'line_total': 10.0,
'financial_type_id': 2,
'label': 'General',
'entity_table': 'civicrm_membership',
'unit_price': 10,
'qty': '1'}}}, {
'line_item': {
'43': {
'price_field_value_id': 61L,
'price_field_id': 37L,
'entity_id': 1248L,
'tax_amount': 1.67,
'line_total': 8.33,
'financial_type_id': 2,
'label': 'Concession',
'entity_table': 'civicrm_membership',
'unit_price': '8.33',
'qty': '1'}}}],
'tax_amount': 3.67,
'total_amount': 22.0,
'contribution_recur_id': 605L,
'financial_type_id': 2,
'fee_amount': 0,
'payment_processor_id': 5L,
'receive_date': u'2019-08-01',
'contribution_status_id': 2}
```
*Current situation:*
Calling the Order API to create Order with given data results with "Line item total doesn't match with total amount". This is because total_amount (22.0) <> sum of line_totals (18.33)
*How should it be:*
The Line Items check should consider tax_amounts of line_items and order creation should succeed.https://lab.civicrm.org/dev/core/-/issues/194Search Builder greater than and lesser than operators for contribution total ...2018-12-09T21:15:34ZMatthias BärnthalerSearch Builder greater than and lesser than operators for contribution total amount omittedTo reproduce:
* Go to Search -> Search generator
* Choose Contribution -> Total Amount
* No greater than, lesser than, greater than equal, lesser than equal operators are present.
My guess is that the field gets treated as a String, th...To reproduce:
* Go to Search -> Search generator
* Choose Contribution -> Total Amount
* No greater than, lesser than, greater than equal, lesser than equal operators are present.
My guess is that the field gets treated as a String, therefore the operator is omitted in Builder.js
`// based on data type remove invalid operators e.g. IS EMPTY doesn't work with Boolean type column
if ((field in CRM.searchBuilder.fieldTypes) === true) {
if (CRM.searchBuilder.fieldTypes[field] == 'Boolean') {
CRM.searchBuilder.generalOperators = _.omit(CRM.searchBuilder.generalOperators, ['IS NOT EMPTY', 'IS EMPTY']);
}
else if (CRM.searchBuilder.fieldTypes[field] == 'String') {
CRM.searchBuilder.generalOperators = _.omit(CRM.searchBuilder.generalOperators, ['>', '<', '>=', '<=']);
}
}
buildOperator(operator, CRM.searchBuilder.generalOperators);`5.4.0https://lab.civicrm.org/dev/core/-/issues/195Add Contribution Counts to Sub-tabs2022-08-17T05:03:37ZCamilo RodríguezAdd Contribution Counts to Sub-tabs## Overview
It would be helpful to be able to see on each sub-tab a count of Contributions / Recurring Contributions, keeping the UX consistent with how the rest of tabs work on Contact's Detail View.
## How it Works Currently
1. Go to ...## Overview
It would be helpful to be able to see on each sub-tab a count of Contributions / Recurring Contributions, keeping the UX consistent with how the rest of tabs work on Contact's Detail View.
## How it Works Currently
1. Go to a Contact's detail view.
2. The **Contributions** tab shows also the count of contributions associated to the contact.
3. Clicking on the tab displays two sub-tabs, one for Contributions, the second one for Recurring Contributions.
4. Sub-tabs don't show number of contributions on each.
## How it Should Work
1. Go to a Contact's detail view.
2. The **Contributions** tab shows also the count of contributions associated to the contact.
3. Clicking on the tab displays two sub-tabs, one for Contributions, the second one for Recurring Contributions.
4. Sub-tabs show number of contributions on each. Count done for **Recurring Contributions** is done on active recurring contributions.https://lab.civicrm.org/dev/core/-/issues/196email signature not included in activity email2018-11-05T12:22:00Zlcdwebemail signature not included in activity emailto reproduce:
* go into your contact record and click the edit button
* below the email address click to expand the signature panel. enter a value and save the form.
* on the summary view you will now see "(signature)" in parens and can...to reproduce:
* go into your contact record and click the edit button
* below the email address click to expand the signature panel. enter a value and save the form.
* on the summary view you will now see "(signature)" in parens and can click to view the value
* click the actions button and select "send an email"
the signature should prepopulate in the email body field but does not.
this is a regression. the behavior works as expected in 4.6 but was lost somewhere in the 4.7/5.x cycle.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/198Allow permission to "From Email Addresses"2022-08-16T05:03:36ZfrancescbassasAllow permission to "From Email Addresses"In order to solve this SE question [How to disable “From email address” for unauthorized users?](https://civicrm.stackexchange.com/questions/7236/how-to-disable-from-email-address-for-unauthorized-users) we have been using this extension...In order to solve this SE question [How to disable “From email address” for unauthorized users?](https://civicrm.stackexchange.com/questions/7236/how-to-disable-from-email-address-for-unauthorized-users) we have been using this extension [From Email Address Permission](https://civicrm.org/extensions/from-email-address-permission). The extension is very simple but hard to mantain because we were forced to overwrite a couple of core files.
Recently we see some core changes in the direction to [enhance "From Email Adresses"](https://github.com/civicrm/civicrm-core/pull/11047) and we would like to see also the possibility to add a From Email Address permission system.
We imagine something like ACL at report configuration level but in this case at from email address configuration level:
![from-email-adresses-permissions](/uploads/c509cdf596722aae401c51486476ddec/from-email-adresses-permissions.png)
To ensure that nothing breaks *Permission* configuration for the default From Email Address must be always *CiviMail: Access CiviMail* and *ACL Group/Role* must be empty.https://lab.civicrm.org/dev/core/-/issues/3630Fix accessible mailings when users don't have view all contacts permission2024-02-19T05:03:29ZMichael McAndrewFix accessible mailings when users don't have view all contacts permissionCRM_Mailing_BAO_Mailing::mailingACLIDs is responsible for limiting the mailings that are visible to users when they do not have either view or edit all contacts (at the BAO layer at least)
It works by returning a list of Ids of mailings...CRM_Mailing_BAO_Mailing::mailingACLIDs is responsible for limiting the mailings that are visible to users when they do not have either view or edit all contacts (at the BAO layer at least)
It works by returning a list of Ids of mailings that should be visible.
One of the queries that is used to construct this list looks like this:
```sql
SELECT DISTINCT(m.id) AS id
FROM civicrm_mailing m
LEFT JOIN civicrm_mailing_group g ON g.mailing_id = m.id
WHERE ((g.entity_table LIKE 'civicrm_group%'
AND g.entity_id IN (3))
OR (g.entity_table IS NULL
AND g.entity_id IS NULL
AND m.domain_id = 1))
```
The logic behind the `OR (g.entity_table IS NULL AND g.entity_id IS NULL AND m.domain_id = 1) where clause looks wrong to me.
My assumption is that it is there because if you created a mailing (added lots of content, etc.) but didn't then assign it a group, it would suddenly disappear from view when you went back to look for it because it didn't contain a group that you have access to.
The problem with this condition is that the user also gets to see mailings by other contacts who have similarly not defined any groups yet.
Provided the above assumption is correct, a better condition would be `OR m.created_id = $user_id` (where user id is the contact ID of the current logged in user.
@JonGold, I wonder what you think about this given that your issue https://issues.civicrm.org/jira/browse/CRM-16981 was similar in nature. @seamuslee - I'm guessing you might have some thoughts on this as well.
Also related is https://issues.civicrm.org/jira/browse/CRM-18181 (though I have not yet got my head around how :)
Aaalso related, in my experimentation, the Mailing api does not respect these permissions, so people get to see all mailings in the recipients field in the Angular powered new CiviMail UI. Are you experiencing that @JonGold?
I've running the above suggestion with a client at the moment. If we get some consensus on how it should work, I would be happy to Shepard this into core.https://lab.civicrm.org/dev/core/-/issues/199Fix ACL on Group.get API2021-03-29T13:53:28ZMichael McAndrewFix ACL on Group.get APIBefore
------
ACL filtering was done after results were retrieved from the database, which in the majority of cases would lead to incorrect results being returned.
Consider the following scenario. 100 groups exist in the DB. A user has...Before
------
ACL filtering was done after results were retrieved from the database, which in the majority of cases would lead to incorrect results being returned.
Consider the following scenario. 100 groups exist in the DB. A user has access to the 100th group.
Group.get will return 'the first' 25 groups, filter them all, and return that no groups are available.
Aside from this being a problem in itself, it also causes paged API calls (e.g. the API call that populates the CiviMail recipients list of groups) to fail as they assume that there are no more records to return.
After
-----
If check permissions is checked and we do not have view all contacts, we add an extra where clause to `_civicrm_api3_basic_get`, ensuring that only visible groups are returned.https://lab.civicrm.org/dev/core/-/issues/200View (display) of files uploaded to Custom data Field that allows Multiple Re...2022-08-18T05:03:48ZKarinGView (display) of files uploaded to Custom data Field that allows Multiple Records is showing first file for all Records on View - but is ok on EditView (on the left) -> Edit (on the right);
This is a regression as it worked/displayed properly in 4.6; it may (or may not) be a recent regression. If not many sites/projects are using file uploads in custom fields containing multiple r...View (on the left) -> Edit (on the right);
This is a regression as it worked/displayed properly in 4.6; it may (or may not) be a recent regression. If not many sites/projects are using file uploads in custom fields containing multiple records then it's possible this regression has gone undetected until now.
This is not a critical issue to us - and not asking anyone to jump in and fix this for us - but filing this as a bug; creating a space to add some more notes here in case someone else comes across this issue.
![image](/uploads/7b375cb6688d4afe70be852f5cd1fe77/image.png)https://lab.civicrm.org/dev/core/-/issues/201"Partially Paid" status problem with financial transactions2022-10-06T05:03:21Zguanhuan"Partially Paid" status problem with financial transactions**How it currently works**
A. If a partial amount has been paid to a "Pending" contribution, a new payment financial transaction with the partial amount will be created and the contribution is updated to "Partially Paid". Then if the co...**How it currently works**
A. If a partial amount has been paid to a "Pending" contribution, a new payment financial transaction with the partial amount will be created and the contribution is updated to "Partially Paid". Then if the contribution's status is edited to "Completed", no new financial transaction will be created.
B. When editing the status of a "Pending" contribution to "Partially Paid", no new financial transaction will be created. Then if the contribution's status is edited to "Completed", again, no new financial transaction will be created.
**How it should work**
A. If a partial amount has been paid to a "Pending" contribution, a new payment financial transaction with the partial amount will be created and the contribution is updated to "Partially Paid". Then if the contribution's status is edited to "Completed", a new payment financial transaction with the remaining amount should be created.
B. A "Pending" contribution's status probably should not be allowed to be directly edited to "Partially Paid". If there is a reason that it has to be available, when the "Partially Paid" contribution is edited to "Completed" status, a payment financial transaction with full amount should be created.
**Solution**
1. When a "Partially Paid" contribution is being edited to "Completed" status (not via recording payment), CiviCRM should automatically generate a payment financial transaction with the remaining amount with correct credit and debit accounts.
2. Remove "Partially Paid" option from contribution status dropdown.
Even if we decide to not do anything about point 2, the fix for point 1 should generate a full amount payment financial transaction in scenario B which is more correct than it is at the moment.
**Further discussion**
I started an email thread 2 month back about various of issues around contribution status transition and financial transactions. This is for addressing one of the issues. Maybe for longer term, we can start to consider downgrading "Contribution Status" field from a physical field to a soft field which displays invoice fulfilment information based on order amount and amount paid calculation. We might not be able to avoid an "Is cancelled/ refunded" field under the current structure in order to indicate the intention to cancel a posted contribution.
Just to mention this here since it's related. I will start new ticket/ thread if there is enough interest in discussing this further.https://lab.civicrm.org/dev/core/-/issues/3605"Tracking Click-Throughs" option in mailings generates 404 links when using m...2024-02-17T05:03:31Zjensschuppe"Tracking Click-Throughs" option in mailings generates 404 links when using multi-language with path prefixThis occurred in a Drupal environment with multiple languages and the following configuration:
- Languages in Drupal:
- English (activated)
- German (activated, default)
- Languages in CiviCRM:
- Default language: English
- avai...This occurred in a Drupal environment with multiple languages and the following configuration:
- Languages in Drupal:
- English (activated)
- German (activated, default)
- Languages in CiviCRM:
- Default language: English
- available: German, English
- Inherit CMS language: yes
Conditions under which the erroneous behavior can be reproduced:
- Mailing language: English
- UI language: German
- language prefix in the URL: none or "de"
or:
- Mailing language: German
- UI language: English
- language prefix in the URL: none or "en"
ergo: Using a UI language different from the mailing language and having path prefixes for language detection.
The result is links to the tracking script being prefixed with the language code of the UI language, like so:
https://example.org/de/sites/all/modules/civicrm/extern/url.php?u=123&qid=12345
which is producing a 404 as obviously the path to the script file is not valid due to the language prefix.
Apparently, this code in CRM/Mailing/BAO/TrackableURL.php:93 is where the URL is constructed, but with `userFrameworkResourceURL` being prefixed with the language code:
```
$redirect = $config->userFrameworkResourceURL . "extern/url.php?u=$id";
```https://lab.civicrm.org/dev/core/-/issues/202Empty row under currency drop down2018-08-20T15:21:29ZPradeep Nayakpradpnayak@gmail.comEmpty row under currency drop downThis is something i noticed on drupal7, CiviCRM 5.2.1 fresh install where i don't have default currency set under(Settings - Localization). The currency field on New Contribution and elsewhere shows an empty option as attached in screens...This is something i noticed on drupal7, CiviCRM 5.2.1 fresh install where i don't have default currency set under(Settings - Localization). The currency field on New Contribution and elsewhere shows an empty option as attached in screenshot
![Before](/uploads/672ac199ab60d3763a20d1c5968616b9/Before.png)
PR at https://github.com/civicrm/civicrm-core/pull/123565.4.0https://lab.civicrm.org/dev/core/-/issues/203Cruft code in CRM_Core_BAO_OptionGroup::add()2018-06-23T02:30:00ZPradeep Nayakpradpnayak@gmail.comCruft code in CRM_Core_BAO_OptionGroup::add()PR at https://github.com/civicrm/civicrm-core/pull/12357/filesPR at https://github.com/civicrm/civicrm-core/pull/12357/files5.4.0https://lab.civicrm.org/dev/financial/-/issues/22Flag to indicate separate membership payment2018-10-12T16:07:27Zmattwiremjw@mjwconsult.co.ukFlag to indicate separate membership paymentWhen the "Separate Membership Payment" option is enabled on a contribution page `doPayment()` is called twice with different amounts and descriptions. However, there is no way to identify that they are part of the same form submission o...When the "Separate Membership Payment" option is enabled on a contribution page `doPayment()` is called twice with different amounts and descriptions. However, there is no way to identify that they are part of the same form submission once doPayment is called.
This is a problem for token based processors which generate a "token" via javascript and then submit that token instead of the credit card details. In the case of Stripe (probably similar for others) that token is assigned to a customer and the customer can be charged multiple times, but the token CANNOT be re-used.
In order to process the second payment for the same submission we need to know that it is a second payment so we can handle the token differently.
My proposal is to add an additional flag to the `$params` array that is passed to doPayment: `is_secondary_financial_transaction=1`
PR that implements this: https://github.com/civicrm/civicrm-core/pull/12358
This allows the following code to be implemented in the payment processor: https://github.com/mattwire/com.drastikbydesign.stripe/commit/b648603c0dc1a2aef569537f95ceb46612df3204#diff-8dcbf2bfe3fcb3899e049399543df444R559
Note that the code being removed in that commit did not work as both params were always set.https://lab.civicrm.org/dev/financial/-/issues/23Submitting a contribution page with 0 amount triggers PHP notices2018-11-17T02:39:45Zmattwiremjw@mjwconsult.co.ukSubmitting a contribution page with 0 amount triggers PHP noticesWhen submitting a contribution page with 0 amount the payment processor is not set. However, the submission still tries to lookup a payment processor by ID and hits the following e-notice in `CRM/Contribute/BAO/Contribution.php`:
`$CRM1...When submitting a contribution page with 0 amount the payment processor is not set. However, the submission still tries to lookup a payment processor by ID and hits the following e-notice in `CRM/Contribute/BAO/Contribution.php`:
`$CRM16923AnUnreliableMethodHasBeenUserToDeterminePaymentProcessorFromContributionPage`.5.9https://lab.civicrm.org/dev/core/-/issues/204Add testcases to civicrm-core PR #112912021-09-13T00:08:27ZvarshithAdd testcases to civicrm-core PR #11291Ref. https://github.com/civicrm/civicrm-core/pull/11291
The above PR adds case tokens support to email activities.
We need test cases for the above PR to complete it.Ref. https://github.com/civicrm/civicrm-core/pull/11291
The above PR adds case tokens support to email activities.
We need test cases for the above PR to complete it.https://lab.civicrm.org/dev/core/-/issues/3573Unsubscribe fails but appears to have worked for resending to previous mailin...2024-02-14T05:03:29ZRichUnsubscribe fails but appears to have worked for resending to previous mailing to search resultsRecreate with 5.2.2 (on Dupal 7)
1. create mailing group A
2. create other group B
4. add contact into group: B
5. do mailing to contacts in group B, using group A as unsubscribe. (i.e. Find » In Group B » Action: create CiviMail mailin...Recreate with 5.2.2 (on Dupal 7)
1. create mailing group A
2. create other group B
4. add contact into group: B
5. do mailing to contacts in group B, using group A as unsubscribe. (i.e. Find » In Group B » Action: create CiviMail mailing)
7. Create and send mailing: sent to recipients of mlg1
8. click unsubscribe.
## Expect
to see confirm form saying "you will be unsubscribed from A" because A was the base group used for the original mailing. (When sending to previous mailing recipients there is no option to select an unsubscribe group)
## Actual
User sees "yes you've been unsubscribed from the mailing group/list" [code ref](https://lab.civicrm.org/dev/core/blob/master/CRM/Mailing/Form/Unsubscribe.php#L71) but nothing has actually happened!https://lab.civicrm.org/dev/core/-/issues/205ContributionPage.submit API action does not provide useful feedback2022-08-19T05:03:33ZjamieContributionPage.submit API action does not provide useful feedbackThe ContributionPage submit API action returns the results of:
`CRM_Contribute_Form_Contribution_Confirm::submit($params);`
However, `CRM_Contribute_Form_Contribution_Confirm::submit($params);` doesn't return anything, so no matter wha...The ContributionPage submit API action returns the results of:
`CRM_Contribute_Form_Contribution_Confirm::submit($params);`
However, `CRM_Contribute_Form_Contribution_Confirm::submit($params);` doesn't return anything, so no matter what happens, we always get a success API result with no information in it.
It would be nice to get helpful info like whether the transaction was denied, etc.
Furthermore, as far as I can tell, the submit method of CRM_Contribute_Form_Contribution_Confirm is not called anywhere else besides in the API. When I submit an online contribution I seem to progress through `CRM_Contribute_Form_Contribution_Main->postProcess`, `CRM_Contribute_Form_Contribution_Main->submit` and even `CRM_Contribute_Form_Contribution_Confirm->postProcess` but never `CRM_Contribute_Form_Contribution_Confirm->submit`.
I also note that the test suite seems to run a lot of tests via `CRM_Contribute_Form_Contribution_Main->testSubmit` - although that doesn't seem to return useful information either.
I'd like to help fix this but am not sure what the best strategy is. I think we should change the ContributionPage.submit API action to use `CRM_Contribute_Form_Contribution_Main->submit` (or testSubmit) and we should fix that core code to return more useful results (and possible tear out the unused `CRM_Contribute_Form_Contribution_Confirm::submit()` method).
Does that sound reasonable? Or am I missing something about the `CRM_Contribute_Form_Contribution_Confirm::submit()` method and should focus instead on fixing it?