Summing discount percentages doesn't mean anything. This commit makes sure the operator used to compute discount on group of records is 'average'. It won't always be meaningful, but in some cases, e.g. when the solines only hold one product, and the lines are grouped by product. opw-3649377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152386 Forward-Port-Of: odoo/odoo#152265

Summing discount percentages doesn't mean
anything.

This commit makes sure the operator used to
compute discount on group of records is 'average'.

It won't always be meaningful, but in some cases,
e.g. when the solines only hold one product,
and the lines are grouped by product.

opw-3649377


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

Forward-Port-Of: odoo/odoo#152386
Forward-Port-Of: odoo/odoo#152265

Steps to reproduce: 1) Try to make a payment with the amount less than 0.50$ (minimum amount required in Stripe) 2) Stripe inline form fails to load 3) One can still click pay and see the traceback After this commit the error are handled and displayed on the form loading and on the form submit. opw-3634316 Forward-Port-Of: odoo/odoo#152307

Steps to reproduce:
1) Try to make a payment with the amount less than 0.50$ (minimum amount required in Stripe)
2) Stripe inline form fails to load
3) One can still click pay and see the traceback

After this commit the error are handled and displayed on the form loading and on the form submit.

opw-3634316

Forward-Port-Of: odoo/odoo#152307

Commit [1] introduced a way to "hide" an ir.ui.view through a new visibility field. That field has multiple possible values to restrict the access. One of those is "Restricted Groups", but when selected it's really hard to figure what to do next because nothing happens on screen: there is no "groups" field where to add the groups. Those groups should actually be added a bit below, in the groups_id field which is "hidden" inside the "Access Rights" second tab. This is because the groups_id fi

Commit [1] introduced a way to "hide" an ir.ui.view through a new visibility field.
That field has multiple possible values to restrict the access. One of those is "Restricted Groups", but when selected it's really hard to figure what to do next because nothing happens on screen: there is no "groups" field where to add the groups.

Those groups should actually be added a bit below, in the groups_id field which is "hidden" inside the "Access Rights" second tab. This is because the groups_id field already existed (in base module) before introducing the website visibility feature which just relied on that field when set to "Restricted Groups".

Note that another possible value for visibility is "Password", and in this case a password field appear below the visibility field as one would expect.

[1]: https://github.com/odoo/odoo/commit/e239934abe456257c9dc285d1ad9829c0353900c

![image](https://github.com/odoo/odoo/assets/30048408/7cad0a47-cbe3-464c-8e86-3c4f30f8c848)

Forward-Port-Of: odoo/odoo#151602

Current behavior: When you try to pay with razorpay, you got an error saying the phone number was missing. Steps to reproduce: - Setup RazorPay - Set a phone number on admin - Go to the POS - Add a product to the cart - Click on the payment button - Select razorpay - Scan the QRCode with your phone (make sure you'r connected on the admin account) - Try to finalize the payment opw-3669600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Fo

Current behavior:
When you try to pay with razorpay, you got an error saying the phone number was missing.

Steps to reproduce:
- Setup RazorPay
- Set a phone number on admin
- Go to the POS
- Add a product to the cart
- Click on the payment button
- Select razorpay
- Scan the QRCode with your phone (make sure you'r connected on the admin account)
- Try to finalize the payment

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

Forward-Port-Of: odoo/odoo#152040

In order to better analyze profitability, we added an extra measure to the Invoice Analysis report to show the "Margin" on every invoice line based on the product cost price. In order to have a simplified inventory valuation without fully using the Inventory app, we also added an "Inventory Value" measure that also uses the product cost price to show the change in inventory value based on incoming and outgoing accounting documents. An extra filter "Inventory Valuation" was added as well to

In order to better analyze profitability, we added an extra measure to the Invoice Analysis report to show the "Margin" on every invoice line based on the product cost price.

In order to have a simplified inventory valuation without fully using the Inventory app, we also added an "Inventory Value" measure that also uses the product cost price to show the change in inventory value based on incoming and outgoing accounting documents.

An extra filter "Inventory Valuation" was added as well to show the "Inventory Value" values per storable product and per month.

[task-3708415](https://www.odoo.com/web#id=3708415&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form)

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

Forward-Port-Of: odoo/odoo#151805

In form views, when the user closes the tab while having unsaved changes, and if those changes are valid, we want to save them automatically before leaving. Before this commit, there could be situations where the changes weren't actually saved. For instance, if they involved an heavy payload for the write rpc, or if the network connection was poor, it might happen that the xhr is killed. Or at least, browsers do not offer any guarantee to wait for those xhr to reach the server. Instead of

In form views, when the user closes the tab while having unsaved changes, and if those changes are valid, we want to save them automatically before leaving.

Before this commit, there could be situations where the changes weren't actually saved. For instance, if they involved an heavy payload for the write rpc, or if the network connection was poor, it might happen that the xhr is killed. Or at least, browsers do not offer any guarantee to wait for those xhr to reach the server.

Instead of a classical xhr, we thus use navigator.sendBeacon which ensures that the data will be sent reliably [1]. There's a drawback though, as its payload is limited. When the payload is too heavy, sendBeacon simply returns false and does nothing. In this case, we prevent the page from unloading and display a notification suggesting the user to manually save his changes before leaving.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon

Task 3537838

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#151834
Forward-Port-Of: odoo/odoo#149944

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False. Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line in whatsapp_message.py if self.env['phone.blacklist'].sudo().search([('number', 'ilike', numb

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.

Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line in whatsapp_message.py

if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):

In SaaS 16.4, this line returns the following SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";

Here, we check if the Active state is True to block the message if necessary.

In 17, this same line returns this SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";

I correct it in a PR https://github.com/odoo/enterprise/pull/55498

But if we go further we find that it's really because of the active_test = False of this line in thread.py thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)]) from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c

with the fix of this PR, the discussion on Whatsapp is now possible and we keep the fix of the previous commit.

opw-3704136

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

Forward-Port-Of: odoo/odoo#152273

Purpose ======= From 800ms to 6ms to execute _compute_new_application_count on odoo.com 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#151303

Purpose
=======

From 800ms to 6ms to execute _compute_new_application_count on odoo.com

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#151303

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#144266 Forward-Port-Of: odoo/odoo#142709

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#144266
Forward-Port-Of: odoo/odoo#142709

Before this commit, the displayed allocation on the dashboard were all the ones linked to allocations regardless of their validity period. This resulted with an overloaded dashboard with leave types that are not supposed to be displayed. Forward-Port-Of: odoo/odoo#151306

Before this commit, the displayed allocation
on the dashboard were all the ones linked to allocations regardless of their validity period. This resulted with an overloaded dashboard with leave types that are not supposed to be displayed.

Forward-Port-Of: odoo/odoo#151306

Force post does not work in the validate account move wizard. Steps: - Create a move in the future and set it to be auto post - On the list view, select the move and select action "post entries" - On the wizard, check "force" and validate -> UserError "This move is configured to be auto-posted ..." Forward-Port-Of: odoo/odoo#152271 Forward-Port-Of: odoo/odoo#152003

Force post does not work in the validate account move wizard.

Steps:

- Create a move in the future and set it to be auto post
- On the list view, select the move and select action "post entries"
- On the wizard, check "force" and validate
-> UserError "This move is configured to be auto-posted ..."

Forward-Port-Of: odoo/odoo#152271
Forward-Port-Of: odoo/odoo#152003

**Current behavior before PR:** - In the project module, when a user opens the color picker, it opens as a dropdown even if there is not enough space available, resulting in some parts of the color picker being inaccessible. - In the project, when a user opens the color picker a second time, it always opens as a dropup, even if there is space available for it to open as a dropdown. **Desired behavior after PR is merged:** - Now, when a user opens the color picker, it opens as a dropup

**Current behavior before PR:**

- In the project module, when a user opens the color picker, it opens as a dropdown even if there is not enough space available, resulting in some parts of the color picker being inaccessible.
- In the project, when a user opens the color picker a second time, it always opens as a dropup, even if there is space available for it to open as a dropdown.

**Desired behavior after PR is merged:**

- Now, when a user opens the color picker, it opens as a dropup when there is not enough space available for the color picker to open as a dropdown.
- The color picker will open as a dropdown when there is enough space available.

task-3608803

Forward-Port-Of: odoo/odoo#151681
Forward-Port-Of: odoo/odoo#144698

Thanks to changes in 82314364c6029a83 the auto-lock settings also works for public users. But, going from `self.env.user` to `self.create_uid` to check the group leads to a traceback when `self.create_uid` is not a singleton. This is because `has_group` expects a single record. To fix that, this commits checks the group of the create_uid of the first record in self. Because `sale.group_auto_done_setting` is an implied_group of a res.config.settings parameter, it's enough to only check for the

Thanks to changes in 82314364c6029a83 the auto-lock settings also works for public users. But, going from `self.env.user` to `self.create_uid` to check the group leads to a traceback when `self.create_uid` is not a singleton. This is because `has_group` expects a single record.

To fix that, this commits checks the group of the create_uid of the first record in self. Because `sale.group_auto_done_setting` is an implied_group of a res.config.settings parameter, it's enough to only check for the first record in the recordset.

To reproduce:
 - Install sale
 - Create a quotation as Mitchell Admin
 - Create a quotation as Marc Demo
 - Create a cron that searches on all draft sale.orders and confirm them in batch
 - Run the cron -> Singleton Error

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

Forward-Port-Of: odoo/odoo#151903
Forward-Port-Of: odoo/odoo#151789

In Language settings, change decimal separator to ',' Go to Journal Items In the search bar input '4,50' and search for 'Amount' Error: ValueError: could not convert string to float: '4,50' This occurs becuase when the search model assemble the domain for the orm we use the original string '4,50' and not the parsed value '4.5' opw-3700578 Forward-Port-Of: odoo/odoo#152075

In Language settings, change decimal separator to ',' 
Go to Journal Items
In the search bar input '4,50' and search for 'Amount'

Error: ValueError: could not convert string to float: '4,50'

This occurs becuase when the search model assemble the 
domain for the orm we use the original string '4,50'
and not the parsed value '4.5'

opw-3700578

Forward-Port-Of: odoo/odoo#152075

Since https://github.com/odoo/odoo/issues/1432 To reproduce the problem, you need to ensure that a read_group returns several groups, with the first element being a group with no value if you choose to group on a many2many (see test). Here's an example to reproduce in website_sale: - Install `website_sale` without demo-data - Go to `eCommerce/Products` - Create a new product - Go to `Sales` tab in the product form view - Set a new `eCommerce shop/Categories` like `Sales` - Save

Since https://github.com/odoo/odoo/issues/1432

To reproduce the problem, you need to ensure that a read_group returns several groups,
with the first element being a group with no value if you choose to group on a many2many (see test).

Here's an example to reproduce in website_sale:

- Install `website_sale` without demo-data
- Go to `eCommerce/Products`
- Create a new product
- Go to `Sales` tab in the product form view
	- Set a new `eCommerce shop/Categories` like `Sales`
	- Save
- Return to `eCommerce/Products`
- Remove default filters
- Group by `Website Product Categories`
- There are two group: `None` and Sales`
- Click on None
- Traceback

In this case, the orderby is website_sequence:sum ASC,
and will therefore return as first group None containing `Delivery Product`
and as second group `Sales` containing the newly created product.

What happens is that `read_group` will build `rows_dict` thanks to `_read_group`.

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2724

this `rows_dict` will be ordered according to `orderby`and then passed as an argument to the `_read_group_format_result` function

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2759

For each row, this function will convert `row[group]` (group in this case is the many2many field)
into a tuple containing (id, displayname) in case the value (`row[group]`)
is found which will be used to build the domain `[(field_name, =, value)]`.

So, for example, replacing
```py
rows_dict = [
  groupbyField': odoo.model(1),
  groupbyField': odoo.model(4),
]

```
with
```py
rows_dict = [
  groupbyField': (1, 'First record'),
  groupbyField': (4, 'Fourth record'),
]
```

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2460-L2462

If the value is False, we'll use the 'not in' operator instead.
To do this, we need to retrieve the ids of all the other groups to
include in this one all the records that aren't in any group,
either by retrieving the id if it's a model,
or by retrieving the first element of the tuple if it's already been modified,
or by directly retrieving the value of the field if it's not a many2x.

Except that if the first element is directly a group without a value,
it won't be able to retrieve the values of the other groups,
because the condition for checking that it's a `BaseModel` instance contained a typo

https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2465-L2467

Forward-Port-Of: odoo/odoo#151497

Commit that introduced the issue: fbc167bf84340b4bb6d0f8c59f2734814f56c6df Issue: ====== Adding a table in a long chatter message with scroll raise a traceback Steps to reproduce the issue: ============================= - Switch to RTL lang - Go to any form view and open the editor composer to create a log note - Write a lot of lines so that the scrollbar appears - Add a table - Log the note - Try to scroll -> traceback Origin of the issue: ==================== The `_onScroll

Commit that introduced the issue: fbc167bf84340b4bb6d0f8c59f2734814f56c6df

Issue:
======
Adding a table in a long chatter message with scroll raise a traceback

Steps to reproduce the issue:
=============================
- Switch to RTL lang
- Go to any form view and open the editor composer to create a log note
- Write a lot of lines so that the scrollbar appears
- Add a table
- Log the note
- Try to scroll -> traceback

Origin of the issue:
====================
The `_onScroll` method is called and it has `this._rowUiTarget` as the row from the composer dialog which is not in the ui anymore so `closestElement(row, 'table')`  will return `null`.

Solution:
=========
We just do nothing when the element is not connected.

task-3707808

Forward-Port-Of: odoo/odoo#151800

To reproduce: - Create an employee record for the connected admin user - Switch the user's company to another one (or the employee's company) - Upgrade to 17.0 A user who has the correct rights can change his company anytime to see employees from other companies So it doesn't make sense to have access right error during an upgrade. In this line: https://github.com/odoo/odoo/blob/140e58c5a68db674fc1d240147e4d669b29f2cad/addons/hr_expense/models/hr_expense_sheet.py#L385 The call to parent

To reproduce:
 - Create an employee record for the connected admin user
 - Switch the user's company to another one (or the employee's company)
 - Upgrade to 17.0

A user who has the correct rights can change his company anytime to see employees from other companies So it doesn't make sense to have access right error during an upgrade. In this line: https://github.com/odoo/odoo/blob/140e58c5a68db674fc1d240147e4d669b29f2cad/addons/hr_expense/models/hr_expense_sheet.py#L385 The call to parent_id.user_id fail upgrades to 17.0 if the parent and the user have different companies.

Since Administrator-level users are not restricted, we put the check on that at the top to avoid errors during upgrades to 17.0. Note: in 17.1, it was made possible to have a manager from another company: https://github.com/odoo/odoo/pull/112768/commits/b841a24fc11cb83ca8e95fce7a83648d87cb90e3

Description of the issue/feature this PR addresses:

Current behavior before PR:

During upgrade, the Administrator doesn't have access rights to employees if he's not in the same company.

Desired behavior after PR is merged:

Since the admin can change companies to access other employees, it should not be blocking during the upgrade.


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

Forward-Port-Of: odoo/odoo#150660

Current behavior before PR: When in a checklist where first and second checklist are marked done after selecting first and second checklist and deleting it the third checklist would be marked as done. Desired behavior after PR is merged: Now deleting previous done checklist would not affect the current checklist. task-3203889 Forward-Port-Of: odoo/odoo#151778 Forward-Port-Of: odoo/odoo#134619

Current behavior before PR:

When in a checklist where first and second checklist are marked done after selecting first and second checklist and deleting it the third checklist would be marked as done.

Desired behavior after PR is merged:

Now deleting previous done checklist would not affect the current checklist.

task-3203889

Forward-Port-Of: odoo/odoo#151778
Forward-Port-Of: odoo/odoo#134619

**Steps to reproduce the bug:** - Configure the ups connector: - UPS Package Type: UPS Pallet - UPS Service Type: UPS Worldwide Express Freight - Package Weight Unit: Kilograms - Package Size Unit: Centimeters - Create a French contact - Create a storable product “P1”: - Weight: 500 kg - Create a SO - Add the product P1 - Add shipping: - Select UPS - Get Rate **Problem:** A user Error is triggered: “Missing or Invalid Total Number of Pieces in

**Steps to reproduce the bug:**
- Configure the ups connector:
    - UPS Package Type: UPS Pallet
    - UPS Service Type: UPS Worldwide Express Freight
    - Package Weight Unit: Kilograms 
    - Package Size Unit: Centimeters

- Create a French contact

- Create a storable product “P1”:
    - Weight: 500 kg

- Create a SO
- Add the product P1
- Add shipping:
    - Select UPS
    - Get Rate

**Problem:**
A user Error is triggered: “Missing or Invalid Total Number of Pieces in all Pallets in a Shipment."

Phone numbers in the API can't contain space characters: e.g: “+32 465 65 65 65”

opw-3680420
opw-3681186

Forward-Port-Of: odoo/enterprise#55241
Forward-Port-Of: odoo/enterprise#55121

Steps to reproduce: - Install attendance app - Setup working schedule with no break like so (Mon 8-12h), (Mon 12-17h) - Check attendance for the week Issues: Traceback is displayed opw-3705883 opw-3706118 Forward-Port-Of: odoo/enterprise#55603

Steps to reproduce:
- Install attendance app
- Setup working schedule with no break like so (Mon 8-12h), (Mon 12-17h)
- Check attendance for the week

Issues:
Traceback is displayed

opw-3705883
opw-3706118

Forward-Port-Of: odoo/enterprise#55603

Before this commit, when a pending transaction was created for a subscription payment, the invoice was posted and the pending_transaction flag remained. After this commit, the invoice is not posted and the flag prevent the cron to process the contract again. taskid: 3685013 Forward-Port-Of: odoo/enterprise#54305

Before this commit, when a pending transaction was created for a subscription payment, the invoice was posted and the pending_transaction flag remained. After this commit, the invoice is not posted and the flag prevent the cron to process the contract again.

taskid: 3685013

Forward-Port-Of: odoo/enterprise#54305

When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount. This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow

When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount.

This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow searching on all plans, and should hence be used in this context.

Forward-Port-Of: odoo/enterprise#50893

Steps to reproduce: ------------------- In Data Cleaning app, try to apply a custom filter on Company with "contains" or "not contains" operator. Issue: ------ A traceback occurs. For this line: `res = self._obj.execute(query, params)`, we have `IndexError: list index out of range`. Cause: ------ There is a mismatch between the `%` in the query and the number of parameters. The query is constructed by combining subqueries with a template. These subqueries will be determined using

Steps to reproduce:
-------------------
In Data Cleaning app, try to apply a custom filter on Company with "contains" or "not contains" operator.

Issue:
------
A traceback occurs.
For this line: `res = self._obj.execute(query, params)`, we have `IndexError: list index out of range`.

Cause:
------
There is a mismatch between the `%` in the query and the number of parameters.

The query is constructed by combining subqueries with a template. These subqueries will be determined using the `mogrify` method and will be concatenated to the main query template.
The `'` characters are correctly escaped with `\` , but the `%` characters are not.

Solution:
---------
Don't use mogrify, so that we can keep the subquery parameters
and pass them directly to the main query.
By leaving the values wrapped with `%` in the parameters,
there are no more escape problems.

Note:
This is a better fix than manually escaping the `%` if necessary like:
```py
if operator in ('not ilike', 'ilike'):
	value = f'%{value}%'
```

opw-3668433

Forward-Port-Of: odoo/enterprise#55204
Forward-Port-Of: odoo/enterprise#54287

In 17.0, the style applied in the python side was not used in the template. This commit will add the style classes, change the template used in the python side since it isn't there anymore and correct a traceback when the date_maturity is not set. Also, a bug fix is applied: - the date was not populated on top of the report because the field today is only accessible on lines but not on the report itself. task: 3695867 Forward-Port-Of: odoo/enterprise#54901

In 17.0, the style applied in the python side was not used in the template.
This commit will add the style classes, change the template used in the python
side since it isn't there anymore and correct a traceback when the date_maturity
 is not set.

Also, a bug fix is applied:
 - the date was not populated on top of the report because the field today is
 only accessible on lines but not on the report itself.


task: 3695867

Forward-Port-Of: odoo/enterprise#54901

Current behavior: When both preparation display and printer are enabled, the printer was not able to print changes from an order. Steps to reproduce: - Create a preparation display that show all the orders - Create a pos printer that print all the pos categories - Setup the PoS to use both the preparation display and the printer - Create an order with some products - Validate the order, and pay for it - At this point the order should be printed and displayed on the preparation display.

Current behavior:
When both preparation display and printer are enabled, the printer was not able to print changes from an order.

Steps to reproduce:
- Create a preparation display that show all the orders
- Create a pos printer that print all the pos categories
- Setup the PoS to use both the preparation display and the printer
- Create an order with some products
- Validate the order, and pay for it
- At this point the order should be printed and displayed on the preparation display. But the printer will not print the order.

opw-3606888

Forward-Port-Of: odoo/enterprise#55245

### **Version:** - 17.0 ### **Cause:** When a subscription is not paid automatically, We sent an email to customers to inform them that we would be retrying. ### **Improvement:** In this commit, a button has been added to the email that enables users to pay for failed subscription payments directly. task-3640650 ---- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#53046

### **Version:**

- 17.0

### **Cause:**
When a subscription is not paid automatically,
We sent an email to customers to inform them that we would be retrying.

### **Improvement:**
In this commit, a button has been added to the email that enables users to
pay for failed subscription payments directly.


task-3640650

----
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#53046

When an analytic distribution is set on the counterpart of a bank transaction, the analytic column should appear in the preview of the bank entry. task-3687839 Forward-Port-Of: odoo/enterprise#55354 Forward-Port-Of: odoo/enterprise#54837

When an analytic distribution is set on the counterpart of a bank transaction, the analytic column should appear in the preview of the bank entry.

task-3687839

Forward-Port-Of: odoo/enterprise#55354
Forward-Port-Of: odoo/enterprise#54837

This commit is the counterpart of odoo/odoo#149944 where we use sendBeacon instead of the classical xhr in the case of an urgent save. As a consequence, a knowledge needed to be adapted. Task 3537838 Forward-Port-Of: odoo/enterprise#55457 Forward-Port-Of: odoo/enterprise#54634

This commit is the counterpart of odoo/odoo#149944 where we use sendBeacon instead of the classical xhr in the case of an urgent save. As a consequence, a knowledge needed to be adapted.

Task 3537838

Forward-Port-Of: odoo/enterprise#55457
Forward-Port-Of: odoo/enterprise#54634

Fixed wrong dictionary access in salary rule Forward-Port-Of: odoo/enterprise#55586

Fixed wrong dictionary access in salary rule

Forward-Port-Of: odoo/enterprise#55586

The Location API allow developpers to specify options when requesting a device's location - notably, it can request 'high accuracy' positioning. By default, 'high accuracy' is set to false so that the location API returns a position *quickly*. We can assume that it will return a position based on e.g. WiFi networks it sees around it and an API call to a location provider like Google, Apple, Here, etc. Setting 'high accuracy' to high will make this process much slower (20-30s is not gonna be a

The Location API allow developpers to specify options when requesting a device's location - notably, it can request 'high accuracy' positioning.

By default, 'high accuracy' is set to false so that the location API returns a position *quickly*. We can assume that it will return a position based on e.g. WiFi networks it sees around it and an API call to a location provider like Google, Apple, Here, etc. Setting 'high accuracy' to high will make this process much slower (20-30s is not gonna be an exception), but it means that devices with built-in GPS will usually provide an far more precise location.

In Sign, it's rather important to have reliable data rather than a quick process.

Assuming a person signing something for real, it's safe to assume that the browser will have the time to provide a precise position before the user submits their signature. If not, the position will simply not be saved.

opw-3677499

Forward-Port-Of: odoo/enterprise#55588
Forward-Port-Of: odoo/enterprise#55411

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False. Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line: if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]): In SaaS 16.4

When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.

Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line:

if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):

In SaaS 16.4, this line returns the following SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";

Here, we check if the Active state is True to block the message if necessary.

In 17.0, this same line returns this SQL request:

SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";

This time, the Active state is not checked, so regardless of whether it's False or True, the message is blocked. This makes it impossible to have a conversation with a customer in Odoo 17.0

The solution is to add ('active', '=', True) to the line in 17.0

if we go further we find that it's really because of the active_test = False of this line in thread.py thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)]) from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c

Forward-Port-Of: odoo/enterprise#55498

Fix net wage pdf value. Forward-Port-Of: odoo/enterprise#55425

Fix net wage pdf value.

Forward-Port-Of: odoo/enterprise#55425

The menu actions to access the pivot & list properties were visible when the formula was referring to an inexisting datasource. Clicking on the said action would then traceback as ce cannot find a datasource. Task: 3670824 Forward-Port-Of: odoo/enterprise#55529 Forward-Port-Of: odoo/enterprise#54675

The menu actions to access the pivot & list properties were visible when the formula was referring to an inexisting datasource. Clicking on the said action would then traceback as ce cannot find a datasource.

Task: 3670824

Forward-Port-Of: odoo/enterprise#55529
Forward-Port-Of: odoo/enterprise#54675

Steps (from customer DB): - Setup automation rules that send mail - Run the rules No precise steps found, running the existing code in SA is enough too trigger an issue ``` Partner = env['res.partner'] Partner._parse_partner_name('johndoe@example.com') ``` Actual result: - Traceback due to missing attribute for partner - _parse_partner_name definition has been removed in 17.0, still exist in 16.4 Expected result: - no traceback, mail send - email is parse to name opw-369312

Steps (from customer DB):
- Setup automation rules that send mail
- Run the rules

No precise steps found, running the existing code in SA is enough too trigger an issue
```
Partner = env['res.partner']
Partner._parse_partner_name('johndoe@example.com')
```

Actual result:
- Traceback due to missing attribute for partner
- _parse_partner_name definition has been removed in 17.0, still exist in 16.4

Expected result:
- no traceback, mail send
- email is parse to name

opw-3693124
task-2612945

Forward-Port-Of: odoo/enterprise#54690

Forward-Port-Of: odoo/enterprise#55604 Forward-Port-Of: odoo/enterprise#55217

Forward-Port-Of: odoo/enterprise#55604
Forward-Port-Of: odoo/enterprise#55217

Steps to reproduce ================== - In date_merge modul, have enough records (such as leads) to be merged - unfolf one record - select all -> only the unfolded record is selected opw-3613615 Forward-Port-Of: odoo/enterprise#55459 Forward-Port-Of: odoo/enterprise#53941

Steps to reproduce
==================
- In date_merge modul, have enough records (such as leads) to be merged
- unfolf one record
- select all
-> only the unfolded record is selected

opw-3613615

Forward-Port-Of: odoo/enterprise#55459
Forward-Port-Of: odoo/enterprise#53941

Forward-Port-Of: odoo/enterprise#55491

Forward-Port-Of: odoo/enterprise#55491

After changing the payment method of a subscription, the confirmation message was not displayed on the subscription. To reproduce: - prerequisite: setup a test payment provider with tokenization support - login in as 'portal' user - Buy a 'Car Leasing' product, on payment choose the preceding payment provider with tokenization - go to 'My Account', then click on 'Subscriptions' - choose the order with 'Car Leasing' - click "Manage Payment Method" - click on "Save Payment Method" =>

After changing the payment method of a subscription, the confirmation message was not displayed on the subscription.

To reproduce:
- prerequisite: setup a test payment provider with tokenization support
- login in as 'portal' user
- Buy a 'Car Leasing' product, on payment choose the preceding payment provider with tokenization
- go to 'My Account', then click on 'Subscriptions'
- choose the order with 'Car Leasing'
- click "Manage Payment Method"
- click on "Save Payment Method"

=> After page reload we should see a message saying that the payment
   method was successfully changed, but no message are displayed.

Forward-Port-Of: odoo/enterprise#48671

### Steps to reproduce issue: 1. Create a quotation, set a recurrence and a subscription product 2. Confirm quotation 3. Start date (Other Infos tab) becomes readonly ### Explanation: Behaviour was changed in versions 16.2 and 16.3 with commit odoo@433f631cba0d1889674fadf999a1b078266e0110 but was brought back to original with commit odoo@1748e8368c1dcce4c7ddfb326ea8a11bb6f9bce3 ### Suggested fix: Make behaviour the same for every version. Here, we adapt the saas to the major ver

### Steps to reproduce issue:

1. Create a quotation, set a recurrence and a subscription product
2. Confirm quotation
3. Start date (Other Infos tab) becomes readonly

### Explanation:

Behaviour was changed in versions 16.2 and 16.3 with commit odoo@433f631cba0d1889674fadf999a1b078266e0110 but was brought back to original with commit odoo@1748e8368c1dcce4c7ddfb326ea8a11bb6f9bce3

### Suggested fix:

Make behaviour the same for every version. Here, we adapt the saas to the major versions.

opw-3670543

Forward-Port-Of: odoo/enterprise#55545
Forward-Port-Of: odoo/enterprise#55250

These tests are testing the monthly declaration in 2022. As of today, 2022 is no longer a valid year in the wizard, thus causing the tests to fail. In order to ensure that such an issue won't happen again, we will freeze the time for these tests to dec 31 2022, so that the year will always be valid. Forward-Port-Of: odoo/enterprise#55583

These tests are testing the monthly declaration in 2022. As of today, 2022 is no longer a valid year in the wizard, thus causing the tests to fail.

In order to ensure that such an issue won't happen again, we will freeze the time for these tests to dec 31 2022, so that the year will always be valid.

Forward-Port-Of: odoo/enterprise#55583