Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-12-10T00:07:08Zhttps://lab.civicrm.org/dev/core/-/issues/2024Membership renewal with 0 tax creating extra line item2020-12-10T00:07:08Zvakeesan26Membership renewal with 0 tax creating extra line itemWhen we renewing a membership which is having 0 tax financial type creating a extra line item in contribution
![image](/uploads/e3e81457f94951f77f7922b82ed025f9/image.png)
![image](/uploads/41d18c2fda344f922361f66d5130d7eb/image.png)
...When we renewing a membership which is having 0 tax financial type creating a extra line item in contribution
![image](/uploads/e3e81457f94951f77f7922b82ed025f9/image.png)
![image](/uploads/41d18c2fda344f922361f66d5130d7eb/image.png)
![image](/uploads/4b69cd8deaad3cbfbef86062f8a45322/image.png)
![image](/uploads/8f3999d9705ee6922d29a4fbaab3d6e4/image.png)
![image](/uploads/3b968cb573efb40c331496ffae17dd68/image.png)
**CiviCRM - 5.29.0**5.34.0https://lab.civicrm.org/dev/core/-/issues/2019Civicase: Wrong Details in Change Custom Data Activity when filling an empty ...2021-03-11T12:47:44ZAndreasandreas.howiller@civiservice.deCivicase: Wrong Details in Change Custom Data Activity when filling an empty fieldOverview
----------------------------------------
When custom case data is changed in CiviCase a Custom Data Activity is created logging the change in the activity details. This is working well in most circumstances but in some circumsta...Overview
----------------------------------------
When custom case data is changed in CiviCase a Custom Data Activity is created logging the change in the activity details. This is working well in most circumstances but in some circumstances the change log contains misleading content.
Reproduction steps
----------------------------------------
1. Create custom case field eg. of type text called "Custom text".
2. Go to any case and change the data of this field from empty to "short text" (save changes), and then again from "short text" to "short text" (same text, save again).
3. View the details of the two Custom Data Activity created.
Current behaviour
----------------------------------------
When changing the data of a custom text field called "Custom text" from "short text" to "a second short text" it will log: "Custom text: short text => a second short text".
**However under the following two conditions this produces misleading logging:**
1. When the text field above is empty in the beginning what you get is "Custom text: short text => short text". In practice this behavior may produce misunderstandings as it suggests that "short text" was already there and in use cases like application processes this may make a huge difference.
2. When the text field contains the same string a Custom Data Activity is created with Details empty.
Expected behaviour
----------------------------------------
1. In the first case one would expect something like "Custom text: [ ] => short text".
2. In the second case probably the best behaviour would be not to create an activity at all and showing an appropriate message instead.
Environment information
----------------------------------------
* __Browser:__ Firefox 80.0.1
* __CiviCRM:__ 5.28.1 on drupal 7 and 5.28.2 on WordPess 5.5.15.37.0https://lab.civicrm.org/dev/financial/-/issues/148Deprecate BaseIPN functions validateData & LoadObject2021-01-22T20:28:33ZeileenDeprecate BaseIPN functions validateData & LoadObjectWe've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it...We've just done a round of clean up around interacting with completeOrder and I'm putting this here as what I think would be a good starting point next time.
The function in the BaseIPN class validateData does a bit more than that - it
1) loads a couple of things - one of which is needed - contribution
2) it checks a couple of things
3) it calls loadObjects which in turn does very little over & above calling
```
$contribution->loadRelatedObjects($input, $ids)
```
Most of the things thus-loaded are unused - except in some specific ways within the processor classes & the stuff around $ids['paymentProcessor'] = $paymentProcessorID; could go if we just passed that as an input to the other functions.
In the past sometimes we have duplicated functions in order to unravel them. On a number of occasions this has worked out well. On others I think we are still paying the price. In particular I think it works when you duplicate code & then keep actively cleaning it up. The mess in the batch update task feels like a case where the code was probably duplicated but then left for a looooonnnnggg time.
In this case I think we can duplicate the contents back with a 'light clean' - since we've already gotten it down to fairly minimal code chunk.5.35.0https://lab.civicrm.org/dev/core/-/issues/2006Token Processor refactoring (make core token classes accessible outside sched...2021-10-02T05:30:43ZseamusleeToken Processor refactoring (make core token classes accessible outside scheduled reminder context)Gitlab for pR https://github.com/civicrm/civicrm-core/pull/16983Gitlab for pR https://github.com/civicrm/civicrm-core/pull/169835.43.0https://lab.civicrm.org/dev/drupal/-/issues/138Drupal 9 deprecations2020-09-15T21:10:00ZDaveDDrupal 9 deprecationsSee also https://lab.civicrm.org/dev/drupal/-/issues/122 which is about the civicrm-drupal-8 repo, whereas this is more about core files.
entity_create() is gone.
entity_load() is gone.
url() is gone.
getUsername() is gone.
I have a...See also https://lab.civicrm.org/dev/drupal/-/issues/122 which is about the civicrm-drupal-8 repo, whereas this is more about core files.
entity_create() is gone.
entity_load() is gone.
url() is gone.
getUsername() is gone.
I have a patch ready but haven't fully tested it yet. WIP: https://github.com/civicrm/civicrm-core/compare/master...demeritcowboy:entity-drupal-9?expand=15.31.0https://lab.civicrm.org/dev/core/-/issues/1994LineItem pre Hook non-standard on edit2020-09-06T19:44:12ZeileenLineItem pre Hook non-standard on editThe pre hook passes $params['entity_id'] for 'id' when it should pass null
```
$id = $params['id'] ?? NULL;
if ($id) {
CRM_Utils_Hook::pre('edit', 'LineItem', $id, $params);
}
else {
CRM_Utils_Hook::pre('crea...The pre hook passes $params['entity_id'] for 'id' when it should pass null
```
$id = $params['id'] ?? NULL;
if ($id) {
CRM_Utils_Hook::pre('edit', 'LineItem', $id, $params);
}
else {
CRM_Utils_Hook::pre('create', 'LineItem', $params['entity_id'], $params);
}
```
@lcdweb @JoeMurray @seamuslee @pradeep @monish.deb - can we fix this?5.30.0https://lab.civicrm.org/dev/drupal/-/issues/137D8 Install checks run via Drupal Status Report - give misleading warnings.2020-10-14T13:50:13Zluke.stewartD8 Install checks run via Drupal Status Report - give misleading warnings.**Problem:**
If the civicrm.settings.php file is not writable, a warning is showing on Drupal Status Report indicating that the civicrm.settings.php file should be writable by the webserver user. This also shows on the command line when...**Problem:**
If the civicrm.settings.php file is not writable, a warning is showing on Drupal Status Report indicating that the civicrm.settings.php file should be writable by the webserver user. This also shows on the command line when running some drush commands.
**Ideal solution:**
The reverse behaviour should be present. Ideally we should warn if civicrm.settings.php is writable by the web server user.
The drupal hook requirements is what is generating this error message.
**Details:**
There is an argument passed to this hook `$phase` that would allow us to target this behaviour.
Currently the behaviour is to use \Civi\Setup checkRequirements() which runs Civicrm Core's install requirements checks.
There is possibly some use in some of these requirements being checked and warnings displayed on the Drupal Status Report page - however there is currently no easy way to differentiate between checks that should only run at install time like the writability of civicrm.settings.php and those that make sense to run post install as well.
Currently the check to see if the user is authorised to run the install only runs when phase is set to install.
An initial solution is potentially to only run the check requirements on install. Then if additional metadata can be returned by `$setup->checkRequirements()->getMessages()` as to whether the warning should run on install or runtime, or checks performed inside civicrm core requirements checks to test for if civi is installed the change could be reverted.5.32.0https://lab.civicrm.org/dev/core/-/issues/1989E_WARNING when editing custom field with trigger-based logging turned on2020-09-06T20:47:11ZDaveDE_WARNING when editing custom field with trigger-based logging turned on1. Turn on logging (admin - system settings - misc).
2. Turn off popups so you can see the warning (admin - customize - display prefs) (or install the loudnotices extension).
3. Edit an existing custom field, e.g. just change the label, ...1. Turn on logging (admin - system settings - misc).
2. Turn off popups so you can see the warning (admin - customize - display prefs) (or install the loudnotices extension).
3. Edit an existing custom field, e.g. just change the label, or don't even do anything and just click save.
`Notice: Undefined index: ADD in CRM_Logging_Schema->fixSchemaDifferencesFor() (line 444 of .../CRM/Logging/Schema.php).`
`Warning: Invalid argument supplied for foreach() in CRM_Logging_Schema->fixSchemaDifferencesFor() (line 444 of .../CRM/Logging/Schema.php).`
This might be sort of recent just not sure yet when it started.5.31.0https://lab.civicrm.org/dev/core/-/issues/1988api attachment.get gives fatal error for custom file fields on cases2020-09-21T21:45:54ZDaveDapi attachment.get gives fatal error for custom file fields on casesI don't really believe in custom fields on cases, but if you happen to have one of type file, api attachment get fails on it with a fatal error "Failed to match record to related entity".
1. Create a custom field of type file for case...I don't really believe in custom fields on cases, but if you happen to have one of type file, api attachment get fails on it with a fatal error "Failed to match record to related entity".
1. Create a custom field of type file for cases.
2. Create a case and upload a file in the custom field.
3. Run something like `cv ev "var_dump(civicrm_api3('attachment', 'get', ['id' => 1]));"` where 1 is the corresponding id from civicrm_file. You'll get a fatal error.
4. You can also see it by:
1. Going to Find Cases.
1. Select the case you created.
1. Choose export from the actions dropdown.
1. Choose selected fields (ignore the E_WARNINGs).
1. Pick your custom field.
1. Click Download File.
1. Aside: I don't know why you would do this csv export because if it were working the column output is a time-limited url, so maybe is useful as input to another process, but I'm not sure what else.
It happens because the api goes through a couple central functions including Civi\API\Subscriber\DynamicFKAuthorization which tries to do a lookup by calling CRM_Core_BAO_CustomGroup::getTableNameByEntityName() to find out what table the custom field "extends", but it doesn't know about cases.
This appears to be a quick fix, but I'm not sure what weirdness this might introduce elsewhere, or whether the cases omission is on purpose.
```diff
diff --git a/CRM/Core/BAO/CustomGroup.php b/CRM/Core/BAO/CustomGroup.php
index 3a0dac33f1..435982d336 100644
--- a/CRM/Core/BAO/CustomGroup.php
+++ b/CRM/Core/BAO/CustomGroup.php
@@ -1164,6 +1164,10 @@ ORDER BY civicrm_custom_group.weight,
$tableName = 'civicrm_grant';
break;
+ case 'Case':
+ $tableName = 'civicrm_case';
+ break;
+
```5.31.0https://lab.civicrm.org/dev/core/-/issues/1987Fix theme configuration section on Display preference and improve `isFrontend...2020-10-14T01:27:41Zswastik-compucorpFix theme configuration section on Display preference and improve `isFrontendPage` function for Drupal CMSProblem Motivation
----------------------------------------
While working on the Drupal web-forms, when we are using CiviCRM fields (like payment processors) on the Drupal webform pages, the CiviCRM current theme JS and CSS files were le...Problem Motivation
----------------------------------------
While working on the Drupal web-forms, when we are using CiviCRM fields (like payment processors) on the Drupal webform pages, the CiviCRM current theme JS and CSS files were leaking (rendering) on the Drupal webform page. This was making the page styling more difficult as one has to first reset the leaking CSS and then style on top of them. Also, there were some bootstrap JS libraries (when Shoreditch is the CiviCRM) file which was loading on the page. So, if a developer wants to develop a bootstrap based Drupal 7 themes and try to style the CiviCRM components, the Shoreditch bootstrap JS files conflicts with Drupal 7 bootstrap theme JS files.
To fix this we had to find a way to stop CiviCRM to apply its theme assets. The best way of it is to find a way in CiviCRM which will contextually select/deselect a CiviCRM theme on Drupal CMS pages. And apparently, the CiviCRM core provides such a feature under the display preference page to select different Front-end and Back-end theme. Unfortunately, this feature was not for Drupal CMS and hence the issue.
Problem Overview
----------------------------------------
For the Drupal CMS, the CiviCRM doesn't provide separate configurations for setting the frontend theme (FE) and the backend theme (BE). This is however present for other CMS integrations
For Drupal, on the Display Preference page, we only have one option for setting the global theme and it sets the BE only and the user can only set the BE.
![3ffa703e-9774-4224-abb0-c967b809dbef](/uploads/821e12db022a5accb4c5d8f7d8063ae3/3ffa703e-9774-4224-abb0-c967b809dbef.png)
The problem with this is that the Drupal User couldn't set the front end theme and the backend theme separately. So, to fix this we remove [the extra if logic](https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Admin/Form/Preferences/Display.tpl#L210-L225) just for Drupal CMS which hides the configuration for the FE-theme and BE-theme and loads the configuration for drupal as well. This will print both the configuration fields.
![3403e6d0-6a80-4e20-ac50-bd24190cc858](/uploads/d9efbd1d109e2bb15b0938debda8e32e/3403e6d0-6a80-4e20-ac50-bd24190cc858.png)
Also, the CiviCRM theme CSS was leaking on drupal pages too which uses the CiviCRM fields (and in turn called `civicrm_initialise()` function). This is because `$config->userSystem->isFrontEndPage()` function is buggy for Drupal CMS as it return `false` if the user opens a drupal public page. This is because [`isFrontEndPage()` function ](https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/System/DrupalBase.php#L658-L664))doesn't take care of the corner case of page URLs which are not CiviCRM's one. As it only checks if the URLs is a CiviCRM public URL
```
$item = CRM_Core_Menu::get($path);
// What if `$item` is empty?
return !empty($item['is_public']);
```
If `$item` is empty (that means it's a non-CiviCRM page) even then it returns `false` because the logic is incomplete. It doesn't check if the `$item` is empty.
This [fix](https://github.com/civicrm/civicrm-core/pull/18322) addresses both these issues.
Example use-case
----------------------------------------
1. Click on **Administration -> Customise data and screens -> Display preference**.
2. Go to `Theme` section
Current behaviour
----------------------------------------
![3ffa703e-9774-4224-abb0-c967b809dbef](/uploads/821e12db022a5accb4c5d8f7d8063ae3/3ffa703e-9774-4224-abb0-c967b809dbef.png)
Proposed behaviour
----------------------------------------
![3403e6d0-6a80-4e20-ac50-bd24190cc858](/uploads/d9efbd1d109e2bb15b0938debda8e32e/3403e6d0-6a80-4e20-ac50-bd24190cc858.png)5.31.0https://lab.civicrm.org/dev/core/-/issues/1986Propose altering the default of send notification to contributor checkbox on...2020-09-21T10:54:22ZeileenPropose altering the default of send notification to contributor checkbox on cancel or edit recurring to offWhen cancelling or updating a recurring contribution there is a checkbox to notify the contributor - this is checked by default.
I use this form a bit as a 'user' and often forget to uncheck it - which results in a pretty mindless commu...When cancelling or updating a recurring contribution there is a checkbox to notify the contributor - this is checked by default.
I use this form a bit as a 'user' and often forget to uncheck it - which results in a pretty mindless communication going out for what is usually either being done as part of a chain of communication with the donor (it's redundant) or an administrative change (the next scheduled date needs updating due to some oddity).
Because it's a rare-ish flow and 9 times out of 10 I mean to uncheck it I have never bothered to edit / maintain the message template.
I realise that I could add an extension to change the default - but my gut is that given I've seen it be problematic on 2 out of 2 sites it would probably be better that people actively choose to check the button rather than have to remember to uncheck it. If you forget to check it it's easy to send a quick email but impossible to recall if it you forget to uncheck it.5.31.0https://lab.civicrm.org/dev/user-interface/-/issues/30Ability to Send Invoice with modified subject and CC it2020-09-22T02:41:28ZsunilAbility to Send Invoice with modified subject and CC itOverview
----------------------------------------
Ability to Send Invoice with CC email and with option to alter subject line.
Current behaviour
----------------------------------------
When Invoice Setting is Enabled at `CiviContribute...Overview
----------------------------------------
Ability to Send Invoice with CC email and with option to alter subject line.
Current behaviour
----------------------------------------
When Invoice Setting is Enabled at `CiviContribute Component Settings`, We get option to `Print Invoice` Or `Email Invoice`.
When we click on `Email Invoice`, we can choose From Address and Add additional Comment.
When Email Send:
For online payment form:
- Subject:`Contribution Invoice: Help Support CiviCRM!- Test User`
- BCC and CC emailed copied from Online page and used to send email.
For Offline Submission:
- Subject:`Invoice- Test User`
- BCC and CC : No possible
You can modify the subject, for that we need to alter the subject line in invoice template.
New behaviour
----------------------------------------
You can override Email Subject from UI, its optional, if you don't provide subject, default subject form invoice template get used.
CC Field is available. that will override online page CC email, and for offline payment its new option to send CC email.
![Screenshot_2020-08-29_at_7.54.52_AM](/uploads/0bcccfd49bc7a72697cdd97f604e12f3/Screenshot_2020-08-29_at_7.54.52_AM.png)
----------------------------------------
https://github.com/civicrm/civicrm-core/pull/182865.31.0https://lab.civicrm.org/dev/core/-/issues/1979Incorrect comparison of status_id when changing status of linked cases2020-09-07T14:31:35ZDaveDIncorrect comparison of status_id when changing status of linked casesIt ends up working anyway because it will just change the status of the other case to the same thing it already was so you don't see any problem, but it's comparing wrong and you get an E_NOTICE: `Undefined index: status_id in CRM_Case_F...It ends up working anyway because it will just change the status of the other case to the same thing it already was so you don't see any problem, but it's comparing wrong and you get an E_NOTICE: `Undefined index: status_id in CRM_Case_Form_Activity_ChangeCaseStatus::beginPostProcess() (line 137 of .../CRM/Case/Form/Activity/ChangeCaseStatus.php).`
1. Create a case.
1. Create another case.
1. Create a link cases activity and link them.
1. Create a change case status activity and check the box to update related cases.
1. Click save.
It looks like it's been this way since it was implemented: https://github.com/civicrm/civicrm-core/commit/74b15fae91a220e2b1ab6f29f6e86001743eac0d#diff-784c2a130a993b23166dadf7f1ddc489R156. The available field at that point is a label not the id (the word id here would really mean option_value.value, but that's not the issue).
So two options:
1. Just remove the `if`, since that's effectively what it's been doing this whole time.
1. Include status_id in the results returned from getRelatedCases().5.31.0https://lab.civicrm.org/dev/core/-/issues/1959Brick\Math\Exception\RoundingNecessaryException2020-08-21T07:54:12ZDon WijesooriyaBrick\Math\Exception\RoundingNecessaryExceptionOverview
----------------------------------------
When viewing/editing a contribution, throws [- Brick\Math\Exception\RoundingNecessaryException: "Rounding is necessary to represent the result of the operation at this scale." -]
Happen...Overview
----------------------------------------
When viewing/editing a contribution, throws [- Brick\Math\Exception\RoundingNecessaryException: "Rounding is necessary to represent the result of the operation at this scale." -]
Happens in 5.28.0 as a regression of dev/translation#48
Reproduction steps
----------------------------------------
1. Install Civi with sample data
2. Go to any contact
3. Create a new General membership with default values (Completed status etc) **Amount should be $100.00**
4. Go to contributions tab and view the new contribution
5. Throws the following error
![error](/uploads/2f2754546ac7aed5437f2088897bd149/error.PNG)
Environment information
----------------------------------------
* __CiviCRM:__ _5.28.0_
* __PHP:__ _7.2.10_
* __CMS:__ _Drupal 7.69/WordPress 5.5_
This issue only happens with servers not having gmp php extension installed or not getting picked up due to following code in `vendor/brick/math/src/Internal/Calculator.php` from line 76
```php
/**
* Returns the fastest available Calculator implementation.
*
* @codeCoverageIgnore
*
* @return Calculator
*/
private static function detect() : Calculator
{
if (\extension_loaded('gmp')) {
return new Calculator\GmpCalculator();
}
if (\extension_loaded('bcmath')) {
return new Calculator\BcMathCalculator();
}
return new Calculator\NativeCalculator();
}
```
Comments
----------------------------------------
Issue only applies to BCMath5.28.3https://lab.civicrm.org/dev/financial/-/issues/141Define return parameters for doPayment2023-03-11T00:09:20Zmattwiremjw@mjwconsult.co.ukDefine return parameters for doPaymentSee #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it'...See #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it's not defined anywhere.
My proposal:
* `doPayment($params)` returns an array.
* It must contain:
* **`payment_status_id`**: **(deprecated)** Numeric value of `Contribution Status` option value Completed or Pending. Eg. 1. Must be set but make sure you set `payment_status` as well because this value will be ignored in the future.
* **`payment_status`**: Text field - Either `Completed` or `Pending`.
* It may contain (and the code that calls `doPayment()` will update these values on the contribution/payment:
* **`trxn_id`**: The transaction ID from the payment processor. This will be recorded in the `Contribution.trxn_id` field and the `Payment.trxn_id` field. We do not return `order_reference` here because that is usually filled in by an IPN callback from the payment processor if required.
* **`fee_amount`**: The amount (in same currency as contribution) of the fee taken by the payment processor for processing the payment.
Historically `$params` was passed by reference. This is deprecated and only the return values should be used.
Ping @eileen @artfulrobot @KarinG5.49.0https://lab.civicrm.org/dev/core/-/issues/1956Typo in groups dropdown on scheduled reminders admin form2020-09-03T00:38:33ZDaveDTypo in groups dropdown on scheduled reminders admin formThis is similar to https://github.com/civicrm/civicrm-core/pull/18154 but it's not as clear that the original intent was correct.
In [the form](https://github.com/civicrm/civicrm-core/blob/5.28.0/CRM/Admin/Form/ScheduleReminders.php#L25...This is similar to https://github.com/civicrm/civicrm-core/pull/18154 but it's not as clear that the original intent was correct.
In [the form](https://github.com/civicrm/civicrm-core/blob/5.28.0/CRM/Admin/Form/ScheduleReminders.php#L253) you have the option to limit to groups, and it seems like it was intended to limit to mailing groups but is missing the first parameter so it shows all.
But for these you might want to send to internal groups or admins, and given that it has showed all groups for a while I'd argue to just remove the parameter completely to explicitly show all.5.30.0https://lab.civicrm.org/dev/core/-/issues/1953Credit card fields still required when a $0 option is selected on event regis...2020-08-14T23:18:25Zmark-rodgers11markrodgers11@gmail.comCredit card fields still required when a $0 option is selected on event registration/contribution pageOverview
----------------------------------------
When submitting an event registration (or contribution page form) with a $0 price option selected the form fails validation, despite credit card fields being hidden. I noticed this on a C...Overview
----------------------------------------
When submitting an event registration (or contribution page form) with a $0 price option selected the form fails validation, despite credit card fields being hidden. I noticed this on a CiviCRM website I manage, reproduced on the circle interactive demo site, also @KarinG reproduced this on yet another site.
https://chat.civicrm.org/civicrm/pl/aer7pqut5b85t8ab83ax3iko3o
Reproduction steps
----------------------------------------
1. Go to an event registration page (or contribution page)
2. Select $0 price option
3. Submit form
Current behaviour
----------------------------------------
![image](/uploads/198a46411385f82538500f2a1d34e940/image.png)
Expected behaviour
----------------------------------------
Credit card fields should not be required when they're hidden.
Environment information
----------------------------------------
* __Browser:__ Chrome 84.0.4147.89
* __CiviCRM:__ 5.28.0
* __PHP:__ 7.2.31
* __CMS:__ Drupal 7.72
* __Database:__ MySQL 5.7.31
* __Web Server:__ _Apache 2.4.46
Comments
----------------------------------------
Works as intended on CiviCRM 5.26.2 but not 5.28.05.28.1https://lab.civicrm.org/dev/core/-/issues/1950Profile settings - Add new contacts to a Group? is misleading2020-08-23T21:47:08ZlarsssandergreenProfile settings - Add new contacts to a Group? is misleadingIn settings for profiles, there is an option to "Add new contacts to a Group?" with a help text "Select a group if you are using this profile for adding new contacts, AND you want the new contacts to be automatically assigned to a group....In settings for profiles, there is an option to "Add new contacts to a Group?" with a help text "Select a group if you are using this profile for adding new contacts, AND you want the new contacts to be automatically assigned to a group."
However, on profile submission, any contact is added to the group, not just new contacts. I think that this is the desired behaviour, but the text is misleading.
I would suggest "Add contacts to a group?" and "Select a group if you want contacts to be automatically added to that group when the profile is submitted." or something along those lines.5.30.0https://lab.civicrm.org/dev/drupal/-/issues/133Breadcrumb error on CiviCRM admin pages (Drupal 8)2023-12-13T17:46:26ZW01FBreadcrumb error on CiviCRM admin pages (Drupal 8)Getting the following error on several CiviCRM admin pages, including /civicrm/admin
```
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 190 of /home/customer/www/youpickfarms.org/v...Getting the following error on several CiviCRM admin pages, including /civicrm/admin
```
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 190 of /home/customer/www/youpickfarms.org/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php).
CRM_Utils_System_Drupal8->appendBreadCrumb('Administer CiviCRM', '/civicrm/admin?reset=1') (Line: 60)
CRM_Utils_System::__callStatic('appendBreadCrumb', Array) (Line: 76)
CRM_Contact_Form_Domain->preProcess() (Line: 599)
CRM_Core_Form->buildForm() (Line: 120)
CRM_Core_StateMachine->perform(Object, 'next', 'Next') (Line: 45)
CRM_Core_QuickForm_Action_Next->perform(Object, 'next') (Line: 203)
HTML_QuickForm_Controller->handle(Object, 'next') (Line: 103)
HTML_QuickForm_Page->handle('next') (Line: 347)
CRM_Core_Controller->run() (Line: 98)
CRM_Utils_Wrapper->run('CRM_Contact_Form_Domain', 'Organization Address and Contact Info', Array) (Line: 285)
CRM_Core_Invoke::runItem(Array) (Line: 68)
CRM_Core_Invoke::_invoke(Array) (Line: 36)
CRM_Core_Invoke::invoke(Array) (Line: 88)
Drupal\civicrm\Civicrm->invoke(Array) (Line: 80)
Drupal\civicrm\Controller\CivicrmController->main(Array, '')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```5.70.0https://lab.civicrm.org/dev/core/-/issues/1949Payment method should reflect the last transaction on the contribution2020-09-09T05:18:38ZyashodhaPayment method should reflect the last transaction on the contributionPayment method should reflect the last transaction on the contribution.
When the payment method is updated on the contribution, the system creates a new payment record with the new payment method attached to the contribution.
When the ...Payment method should reflect the last transaction on the contribution.
When the payment method is updated on the contribution, the system creates a new payment record with the new payment method attached to the contribution.
When the contribution is saved, we must update the payment method field on the contribution with the payment method on the most recent payment record attached to that contribution.
I know we are planning on dropping the payment method on contribution and just have it for individual transaction but till the time it does exist it should have the correct value.
Create a contribution which is pay later by check
![pay_later](/uploads/73fda0162672541c39db8f212f945f59/pay_later.png)
Record payment complete with method Cash
![new_payment](/uploads/5c721d3cf7f0d40daf02373a7ce28916/new_payment.png)
It doesn't reflect
![payment_view](/uploads/72697eeae2a99dee75dcc519ece65b97/payment_view.png)5.31.0