The email template screen now clarifies that the Reply-To setting applies to mass mailing only. This reduces confusion for users sending regular emails, who might otherwise expect that field to affect all outgoing messages.

Currently, the reply_to field is used only in the case of a mass
mailing.
Its label was misleading for users sending regular mail.
We fix the label in order to avoid confusion.

cc @Abridbus

The CRM team reporting shortcut for Leads now opens the proper lead list instead of showing the opportunity list. This prevents confusion for sales teams and ensures lead reporting matches the selected menu option.

When clicking on "Teams -> Reporting (on a team vignette) -> Leads" list
view used is the opportunity one. We fix it by correctly setting action
views for ``action_report_crm_lead_salesteam`` reporting action.

Task ID-2497936

Current behavior before PR: Traceback occurs when deleting company field task - 2475520 Forward-Port-Of: odoo/odoo#70467

Current behavior before PR:
Traceback occurs when deleting company field

task - 2475520

Forward-Port-Of: odoo/odoo#70467

When partner is not selected, Odoo sends name_search request `[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such domain mean ( see #70584 ). This commit clarifies what do we expect to get: we want all records without restrictions on `partner_id` value. This also fixes performance issue because domain leaf `('partner_id', 'child_of', [False])` is converted to where-clause `<table>.partner_id in <all or almost all ids>` --- opw-2524010 Description of the

When partner is not selected, Odoo sends name_search request
`[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such
domain mean ( see #70584 ). This commit clarifies what do we expect to get:
we want all records without restrictions on `partner_id` value.

This also fixes performance issue because domain leaf `('partner_id',
'child_of', [False])` is converted to where-clause `<table>.partner_id in <all
or almost all ids>`

---

opw-2524010

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#70638

Issue - Install "Contacts" & 'base_address_extended' modules - Go to contacts and create a contact with value: - street name : Chaussee de Namur - House : 40 - Save and edit again - Set country to 'Netherlands' then save. Address not splited well (wrong values for street name and house). The issue is not present in UI but is in tests. (Issue in UI from odoo 14.0+) Cause There is 2 '_split_street_with_params' (inverse function that set street fields): - partne

Issue

	- Install "Contacts" & 'base_address_extended' modules
	- Go to contacts and create a contact with value:
	  - street name : Chaussee de Namur
	  - House : 40
	- Save and edit again
	- Set country to 'Netherlands' then save.

	Address not splited well (wrong values for street name and house).
	The issue is not present in UI but is in tests.
	(Issue in UI from odoo 14.0+)

Cause

	There is 2 '_split_street_with_params'
	(inverse function that set street fields):
	- partner_autocomplete_address_extended (removed in 14.0)
	- base_address_extended

	The 'spliting' logic is not the same in both function.

	In UI, looks like it does not call '_split_street_with_params'
	from 'base_address_extended' since no super(Partner, self)...

	However in testing, it does call it from module
	'base_address_extended' and therefore trigger the issue.

Solution

	Adapt _split_street_with_params function
	(in 'base_address_extended' module):
	If previous field (from 'street_format') to parse
	in 'street_raw' is 'street_name', then:
	- set `tmp` to: splitted (max 1 split) street_raw
	  with current field seperator
	- set `append_previous, sep, tmp[0]` to:
	  splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
	- add 'append_previous' to 'street_name' value
	- join 'tmp' values and set it to street
	  (should equal to what left from `rpartition(' ')` split
	  + second part of first normal split)
	- continue normal parsing flow

opw-2476096

Forward-Port-Of: odoo/odoo#70783
Forward-Port-Of: odoo/odoo#70720

In Ogone's backend, it is possible to remove `CARD.CARDNUMBER` from Flexcheckout's feedback data (Configuration -> Technical information -> Transaction feedback -> Alias gateway and Tokenization -> Dynamic parameters). Since this is the configuration that was suggested to Odoo customers migrating from a previous version, we must be able to process feedback data when the card number is missing. This commit creates an anonymous card number ('XXXX...') if one is not provided by Ogone. t

In Ogone's backend, it is possible to remove `CARD.CARDNUMBER` from
Flexcheckout's feedback data (Configuration -> Technical information ->
Transaction feedback -> Alias gateway and Tokenization -> Dynamic
parameters). Since this is the configuration that was suggested to Odoo
customers migrating from a previous version, we must be able to process
feedback data when the card number is missing.

This commit creates an anonymous card number ('XXXX...') if one is not
provided by Ogone.

task-2494916

Forward-Port-Of: odoo/odoo#70875

- fix missing access rights when handling feedback data - redirect customers to the payment confirmation page when notification data are not acknowledged by PayPal, rather than displaying an internal server error task-2494916 Forward-Port-Of: odoo/odoo#70862

- fix missing access rights when handling feedback data
- redirect customers to the payment confirmation page when notification
  data are not acknowledged by PayPal, rather than displaying an
  internal server error

task-2494916

Forward-Port-Of: odoo/odoo#70862

Before this commit, in Project App, when the "Collaborative Pads" is enabled in the Settings of this app, if the user create a task without project or in a project that has not the pad enabled and he writes a description for his new task and select (another) project in which the pads is enabled then the description field in the form view changed to have the collaborative pad and the problem is the description is not copied in the pad and seems erase/delete for the user. This commit chec

Before this commit, in Project App, when the "Collaborative Pads" is
enabled in the Settings of this app, if the user create a task without
project or in a project that has not the pad enabled and he writes a
description for his new task and select (another) project in which the
pads is enabled then the description field in the form view changed to
have the collaborative pad and the problem is the description is not
copied in the pad and seems erase/delete for the user.

This commit checks if the pad_content_field is not empty after
generating the pad url for the new task/record, if it is the case then
we copy the content in the pad and the user can continue his edition
before saving the task/record.

Step to reproduce:
-----------------

1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project A"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the Project B. With this change,
the collaborative pad is actived for this task since the Project B has
the pad, and then the description in the pad is empty rather than have
the content that we have just written.

task-2515150

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#70401

If an error occurred when sending the verification SMS in SEPA's form, the error was shown both in the payment form and in a notification. This commit prevents the notification from being shown. task-2494916 Forward-Port-Of: odoo/enterprise#18340

If an error occurred when sending the verification SMS in SEPA's form,
the error was shown both in the payment form and in a notification.
This commit prevents the notification from being shown.

task-2494916

Forward-Port-Of: odoo/enterprise#18340

As we were clearing the taxes on the invoice line after having set its description, it would remove any tax set by prediction, most notably, intracom taxes. This tax clear was done to prevent using the default tax from being. Now, this is done when the invoice line is created, so that it only removes this default tax. Forward-Port-Of: odoo/enterprise#17033

As we were clearing the taxes on the invoice line after having set its
description, it would remove any tax set by prediction, most notably,
intracom taxes.

This tax clear was done to prevent using the default tax from being.
Now, this is done when the invoice line is created, so that it only
removes this default tax.

Forward-Port-Of: odoo/enterprise#17033

Forward-Port-Of: odoo/enterprise#18291 Forward-Port-Of: odoo/enterprise#18075

Forward-Port-Of: odoo/enterprise#18291
Forward-Port-Of: odoo/enterprise#18075

…port TaskID: 2528726 Forward-Port-Of: odoo/enterprise#18293

…port

TaskID: 2528726

Forward-Port-Of: odoo/enterprise#18293

- Updated the WSDL URLs for new customer Task: https://www.odoo.com/web#id=2508208&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 Forward-Port-Of: odoo/enterprise#17758

- Updated the WSDL URLs for new customer


Task: https://www.odoo.com/web#id=2508208&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720

Forward-Port-Of: odoo/enterprise#17758

- When paying a sales order to renew or upsell a subscription, the tokenization of the transaction was forced and only compatible acquirers were shown. This was not necessary as no payment token is ever assigned to the subscription afterward. This is only true when a subscription is created when confirming the sales order. - If the tokenization of the transaction was not required by Subscriptions, it prevented other modules to require it. task-2494916 Forward-Port-Of: odoo/en

- When paying a sales order to renew or upsell a subscription, the
  tokenization of the transaction was forced and only compatible
  acquirers were shown. This was not necessary as no payment token is
  ever assigned to the subscription afterward. This is only true when
  a subscription is created when confirming the sales order.
- If the tokenization of the transaction was not required by
  Subscriptions, it prevented other modules to require it.

task-2494916

Forward-Port-Of: odoo/enterprise#18284