This update reorganizes and cleans up internal website shop configuration files without changing customer-facing behavior. It makes the codebase easier to maintain, which can reduce future development effort and risk when improving the online store.

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

Spreadsheet list and pivot side panels were reorganized to pass the selected item directly instead of storing it through internal commands. This reduces unnecessary internal state and makes the spreadsheet interface easier to maintain, with no intended change to end-user workflows.

There was `SELECT_ODOO_LIST` command that had the list UI plugin store
a list id, which could then be fetched with the getter
`getSelectedListId`.

The getter was only used once (outside the tests): to display the
correct list in the list side panel. But this is not even useful, as
we can just give the correct list as a props of the side panel.

This commit removes the `SELECT_ODOO_LIST` command and its corresponding
getter. It also refactor the list side panel, now there is two
distinct side panels (one for the list of lists, one for the details).
This avoids having to manage a state to determine which list should
be displayed.

Also take the occasion to remove some left-over JQuery and legacy test
utils in the tests.

Same stuff for Pivots

Task: [3557655](https://www.odoo.com/web#id=3557655&cids=1&model=project.task&view_type=form)

In the recent redesign of the `website_event` module(s) [1] a field was used in the templates of event_track that only exists if event_track_live is installed. The `t-att-class` argument is now overriden in `event_track_live` The `t-att-class` attribute is also lightened by moving most of it to `class` to ease the override. task-3597612 [1] 94c5bc3d152c80fdbb6798d9b4d28bf62740856b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port

In the recent redesign of the `website_event` module(s) [1] a field was used in the templates of event_track
that only exists if event_track_live is installed.

The `t-att-class` argument is now overriden in `event_track_live` The `t-att-class` attribute is also lightened by moving most of it to `class` to ease the override.

task-3597612

[1] 94c5bc3d152c80fdbb6798d9b4d28bf62740856b

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

Forward-Port-Of: odoo/odoo#142215

Steps to reproduce: ------------------- - create an invoice without confirm it; - go to the preview and download it; Issue: ------ A traceback appears. Cause: ------ We try to get `ids` field of a non "record" object (not the root cause). The root cause is that we don't create an attachment if the invoice is not posted. And to post an invoice, we must add line before confirm it. Solution: --------- Make sure you are in the case of an invoice that is `posted` to download a pdf.

Steps to reproduce:
-------------------
- create an invoice without confirm it;
- go to the preview and download it;

Issue:
------
A traceback appears.

Cause:
------
We try to get `ids` field of a non "record" object (not the root cause). The root cause is that we don't create an attachment if the invoice is not posted. And to post an invoice, we must add line before confirm it.

Solution:
---------
Make sure you are in the case of an invoice
that is `posted` to download a pdf.

sentry-4612532780

Forward-Port-Of: odoo/odoo#141640

Before this commit, the payment button was part of the checkout/manage form widgets, which caused conflicts when other modules needed to enable/disable the button depending on custom conditions. After this commit, the payment button logic is extracted in a separate widget that handles its enabling after checking if all conditions are satisfied. Other modules can extend the widget and override `isButtonReady` to add custom logic. task-3568861 See also: - https://github.com/odoo/ent

Before this commit, the payment button was part of the checkout/manage
form widgets, which caused conflicts when other modules needed to
enable/disable the button depending on custom conditions.

After this commit, the payment button logic is extracted in a separate
widget that handles its enabling after checking if all conditions are
satisfied. Other modules can extend the widget and override
`isButtonReady` to add custom logic.

task-3568861

See also:
- https://github.com/odoo/enterprise/pull/49894

Forward-Port-Of: odoo/odoo#142265
Forward-Port-Of: odoo/odoo#139556

Issue: ====== When we have a product as a free product reward in cart and we want to add the same product from the shop nothing will happen and the cart stays the same. Steps to reproduce the issue: ============================= - Create a loyalty program with the following options: type: pormotions rule: minimum quantity :1 , gran 1, minimum purchase 0, per order, product: select anyone reward: type : free product , quantity rewarded : 1, product : select any other product - Go to we

Issue:
======
When we have a product as a free product reward in cart and we want to add the same product from the shop nothing will happen and the cart stays the same.

Steps to reproduce the issue:
=============================
- Create a loyalty program with the following options: type: pormotions
rule: minimum quantity :1 , gran 1, minimum purchase 0, per order, product:  select anyone
reward: type : free product , quantity rewarded : 1, product : select any other product
- Go to website and add the product from the rule to cart
- Go to cart and claim reward
- Go back to shop and add the product from the reward to cart
- Go to cart
- The cart stays the same

Issue:
======
When searching for the `line` it doesn't consider if the line is a reward or not.

Solution:
=========
We filter the reward lines if `line_id=False`

opw-3550585

Forward-Port-Of: odoo/odoo#143581
Forward-Port-Of: odoo/odoo#142827

Since the module loader rewrite, it now reports errors directly in the DOM. The error alert also has the class "modal" so that in case a tour comes accross a page with module loading errors, it will only look for elements inside it and fail. But in the QUnit test suite, modals are invisible by default, causing the page to be blank in those cases. This commit adds a css rule to make sure that this error alert is shown, and updates the code that was previously used to report these errors in the

Since the module loader rewrite, it now reports errors directly in the DOM. The error alert also has the class "modal" so that in case a tour comes accross a page with module loading errors, it will only look for elements inside it and fail. But in the QUnit test suite, modals are invisible by default, causing the page to be blank in those cases.

This commit adds a css rule to make sure that this error alert is shown, and updates the code that was previously used to report these errors in the qunit suite to instead simply check for errors reported by the module loader.

Forward-Port-Of: odoo/odoo#143589

[IMP] hw_posbox_homepage: Change logger level Add the possibility to dynamically change the logger level of Odoo and per IoT handler (drivers and interfaces). This will be done through the "Handler List" page. This will be useful to troubleshoot purposes. In particular when it happens on a specific handler. The level set should persist on shutdown as saved in Odoo's configuration using the `--log-handler` parameter, see: https://www.odoo.com/documentation/16.0/developer/reference/cli.

[IMP] hw_posbox_homepage: Change logger level

Add the possibility to dynamically change the logger level of Odoo and per IoT handler (drivers and interfaces).
This will be done through the "Handler List" page.

This will be useful to troubleshoot purposes. In particular when it happens on a specific handler.

The level set should persist on shutdown as saved in Odoo's configuration using the `--log-handler` parameter, see:
https://www.odoo.com/documentation/16.0/developer/reference/cli.html#cmdoption-odoo-bin-log-handler

Notes:
 - When changing Odoo's level, `werkzeug` logger will change to the same level automatically (except in `debug` on which `werkzeug` will be set to `info`)
 - `--log-level` Odoo config wasn't used as it has unintended side effects when dynamically switching to this level
 - `load_iot_handlers` was modified as otherwise the loggers `__name__`  could be wrong and inconsistent on which several logger for a handler exists. For example: `PrinterInterface.py` and `odoo.addons.hw_drivers.iot_handlers.interfaces.PrinterInterface`. In this situation `_logger` can be different from one used in the class. In addition, of that, the parent logger for the different loggers could be different (root and Odoo generally)

Preview:
![image](https://github.com/odoo/odoo/assets/60775325/ee44f97b-a89f-46e0-b23b-9c2637ac8d4c)


opw-3493585

Forward-Port-Of: odoo/odoo#137547
Forward-Port-Of: odoo/odoo#134174

This commit fixes: - hide `read_duration` and `expected_duration` in MO list view. - hide `component availability` byt default in bom overview, unless if coming from mrp forecast. task-3547356 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#140244

This commit fixes:
 - hide `read_duration` and `expected_duration` in MO list view.
 - hide `component availability` byt default in bom overview, unless if coming from mrp forecast.

task-3547356

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

It adds advanced data on the picking view. It's not needed by default so we hide it 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#140577

It adds advanced data on the picking view.
It's not needed by default so we hide it

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

It's not possible to copy paste in the lot_name directly. It has been remove since the import button. Also add by default a search on hand in the quant view from the stock.move.line. We don't want to show quant already send to customer location or without quantity 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 Forwar

It's not possible to copy paste in the lot_name directly. It has been remove since the import button.

Also add by default a search on hand in the quant view from the stock.move.line. We don't want to show quant already send to customer location or without quantity

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

During previous fix: odoo/odoo#141797, the `not move.picked` check was moved to earlier in the if statement to avoid unnecessarily looping through the move lines, but the ( was forgotten to be moved with it. Since we don't want to force all manual consumption marked moves to have a lot_id, let's move the (. ENT PR: odoo/enterprise#51171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142933

During previous fix: odoo/odoo#141797, the `not move.picked` check was moved to earlier in the if statement to avoid unnecessarily looping through the move lines, but the ( was forgotten to be moved with it. Since we don't want to force all manual consumption marked moves to have a lot_id, let's move the (.

ENT PR: odoo/enterprise#51171



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

Forward-Port-Of: odoo/odoo#142933

__Current behavior before commit:__ When searching for an **Internal Reference** of a product variant on the website shop, the fuzzy search is likely to return a wrong result. If the **Internal Reference** of a product template resembles the searched term, it will take it as a fuzzy term and will not even search for product variants internal references. This is because the method `_basic_enumerate_words` only parses the fields of the model considered but not the "subfields", in this case

__Current behavior before commit:__
When searching for an **Internal Reference** of a product variant on the website shop, the fuzzy search is likely to return a wrong result.

If the **Internal Reference** of a product template resembles the searched term, it will take it as a fuzzy term and will not even search for product variants internal references.

This is because the method `_basic_enumerate_words` only parses the fields of the model considered but not the "subfields", in this case the `product_variant_ids.default_code`.

__Description of the fix:__
Run `_search_exact` in any case and only then, if no result is found, run a fuzzy search.

__To reproduce on runbot 15.0:__
In the website shop, search *FURN_0096*. Although there is a variant of *Customizable Desk* that has this exact **Internal Reference**, the search will only return *Office Chair Black* because this product template has a **default_code** set (*FURN_0269*).

opw-3476643

Forward-Port-Of: odoo/odoo#133584

Purpose ======== Update demo data to better show what Appointment can do. Specification ============== Changing the capacity of some tables. Tables 1-4 => from 4 to 2. Tables 9-11 => from 4 to 6. Task-3496910 Forward-Port-Of: odoo/odoo#137673

Purpose
========
Update demo data to better show what Appointment can do.

Specification
==============
Changing the capacity of some tables.
Tables 1-4 => from 4 to 2.
Tables 9-11 => from 4 to 6.

Task-3496910

Forward-Port-Of: odoo/odoo#137673

The issue is that "load older" was called every time the thread was made visible, in particular after chat window unfold. The load more button will naturally be visible when first loading a thread, it only makes sense to check its final visibility and not intermediate steps. But there was a bug where the loading mechanism was relying on the initial "load older" to fetch messages, because the messaging menu preview was incorrectly setting the thread as already loaded, when it just fet

The issue is that "load older" was called every time the thread was made
visible, in particular after chat window unfold.

The load more button will naturally be visible when first loading a
thread, it only makes sense to check its final visibility and not
intermediate steps.

But there was a bug where the loading mechanism was relying on the
initial "load older" to fetch messages, because the messaging menu
preview was incorrectly setting the thread as already loaded, when it
just fetched the last message.

Moreover, the "last message" displayed in the preview was not correctly
computed, and it could end up being the last "currently fetched" message
and not the last of all messages (when jumping in the past), and it
could also be a non-persistent message.

runbot-35533

Forward-Port-Of: odoo/odoo#143129

Have an Invoice partner with type Individual Create an invoice with said customer confirm. ZATCA invoice has warning "invoiceTimeStamp_QRCODE_INVALID". ``` {"type":"WARNING", "code":"invoiceTimeStamp_QRCODE_INVALID", "category":"QRCODE_VALIDATION", "message":"Time on QR Code does not match with Invoice Issue Time (KSA-25). If ZATCA's SDK was used to generate QR Code, kindly use the latest version of SDK", "status":"WARNING"} ``` This occurs because when the In

Have an Invoice partner with type Individual
Create an invoice with said customer confirm.
ZATCA invoice has warning "invoiceTimeStamp_QRCODE_INVALID".
```
{"type":"WARNING",
"code":"invoiceTimeStamp_QRCODE_INVALID",
"category":"QRCODE_VALIDATION",
"message":"Time on QR Code does not match with Invoice Issue Time (KSA-25).
           If ZATCA's SDK was used to generate QR Code, kindly use the
           latest version of SDK",
"status":"WARNING"}
```

This occurs because when the Invoice partner is an Individual the validation requires an additional QR code enclosing invoice information that needs to match the xml content.

In this case the IssueTime of the invoice was not matching because the QR is manually formatted with a wrong 'Z' at the end, while its timezone is, correctly, Asia/Riyadh

opw-3586326

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

Task Adhoc: 29838 Task latam: 1076 **Description of the issue/feature this PR addresses:** -It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks. * In "Accounting/Vendors/Own Checks" it is needed to: 1) Remove the filter "Checks on hand". 2) Remove from "Group By" the group "Third party check Current Journal". * In "Accounting/Customers/Third Party Checks" it is needed to: 1) Add the filter "Checks on hand". 2) Ad

Task Adhoc: 29838
Task latam: 1076

**Description of the issue/feature this PR addresses:**
-It is needed to improve the filters and and "Group By" from the search view of own checks and third party checks.

* In "Accounting/Vendors/Own Checks" it is needed to:
  1) Remove the filter "Checks on hand".
  2) Remove from "Group By" the group "Third party check Current Journal".

* In "Accounting/Customers/Third Party Checks" it is needed to:
  1) Add the filter "Checks on hand".
  2) Add in "Group By" the group "Third party check Current Journal".
  3) Remove the filter "No Bank Matching".
  4) Rename filter "Third party check Current Journal" to "Current Journal".

- When a payment is created is needed show the updated search view "Accounting/Customers/Third Party Checks" when searching more checks if "Existing Third Party Checks" payment method is selected.
![image](https://github.com/odoo/odoo/assets/89547436/5fe36f7b-a342-48ae-a915-8cae1f978574)

- Change spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view from "Actual Diario de Cheques de Terceros" to "Diario de Pago".

**Current behavior before PR:**
* In "Accounting/Vendors/Own Checks" in the search view:
Exists the filter "Checks on hand" and exists the group "Third party check Current Journal" in the "Group by".

* In "Accounting/Customers/Third Party Checks" in the search view:
Don`t exist the filter "Checks on hand". Don`t exist the group "Third party check Current Journal" in the "Group by". Exists the filter "No Bank Matching". There is a filter named "Third party check Current Journal".

* When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected then is showing the same search view as "Accounting/Customers/Third Party Checks".

* Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Actual Diario de Cheques de Terceros".

**Desired behavior after PR is merged:**
* In "Accounting/Vendors/Own Checks" in the search view:
Not exists the filter "Checks on hand" and not exists the group "Third party check Current Journal" in the "Group by".

* In "Accounting/Customers/Third Party Checks" in the search view:
Exists the filter "Checks on hand". Exists the group "Third party check Current Journal" (renamed to "Original Journal") in the "Group by". Not exists the filter "No Bank Matching". There is not existing a filter named "Third party check Current Journal".

*  When a vendor payment is created when searching more checks if "Existing Third Party Checks" payment method is selected them is showing the updated search view as "Accounting/Customers/Third Party Checks".

* Spanish translate of "Third Party Checks" group "Third party check Current Journal" from search view is "Diario de Pago".

Video:
https://drive.google.com/file/d/1H1ng4mPsN0sf1NwW_JMOmZrhe8TrrBlk/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#143526
Forward-Port-Of: odoo/odoo#132770

In this commit, we add the mention of the service type on the ticket and when the service is "table", we add the table stand number. We also fix a problem with stripe and adyen where the ticket does not print the order but an empty order with the kiosk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140047

In this commit, we add the mention of the service type on the ticket and
when the service is "table", we add the table stand number.

We also fix a problem with stripe and adyen where the ticket does not
print the order but an empty order with the kiosk.

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

Forward-Port-Of: odoo/odoo#140047

Steps to reproduce ================== - Enable the debug mode - Use an odoo instance with the design-themes - Click on the debug menu - Click on Start tour `OwlError: Got duplicate key in t-foreach: homepage` Cause of the issue ================== Website theme tours are registered here : https://github.com/odoo/odoo/blob/5c01439cf20b2c0ca08d618df6f249617127e6d1/addons/website/static/src/js/tours/tour_utils.js#L348-L358 The saveAs option is used but since the owl refactor, it

Steps to reproduce
==================

- Enable the debug mode
- Use an odoo instance with the design-themes
- Click on the debug menu
- Click on Start tour

`OwlError: Got duplicate key in t-foreach: homepage`

Cause of the issue
==================

Website theme tours are registered here :
https://github.com/odoo/odoo/blob/5c01439cf20b2c0ca08d618df6f249617127e6d1/addons/website/static/src/js/tours/tour_utils.js#L348-L358

The saveAs option is used but since the owl refactor, it doesn't override the previous tour.

There is a default homepage tour in the website addon and then one for each theme.
There should only be one available at a time (same as in 16.2). When selecting a new theme, the action button_choose_theme is called and that ensures that only one theme can be installed at the same time.

opw-3595512

Forward-Port-Of: odoo/odoo#142288
Forward-Port-Of: odoo/odoo#142148

Issue: ====== When we settle an order that has a product with uom not pos_groupable and quantity isn't an integer for example 3.5 it will add 4 lines each with quantity = 1 which is not correct. Steps to reproduce the issue: ============================= - Create a product with a not pos_groupable uom (kg for example) - Create a sale order with that prouct and add a not integer quantity - Go to pos and settle the order - You will have 4 lines added each with quantity = 1 Origin of t

Issue:
======
When we settle an order that has a product with uom not pos_groupable and quantity isn't an integer for example 3.5 it will add 4 lines each with quantity = 1 which is not correct.

Steps to reproduce the issue:
=============================
- Create a product with a not pos_groupable uom (kg for example)
- Create a sale order with that prouct and add a not integer quantity
- Go to pos and settle the order
- You will have 4 lines added each with quantity = 1

Origin of the issue:
====================
The quantity was hardcoded = 1

Solution:
=========
I addeed order lines equal to the integer part of quantity and one last order line that have the rest quantity.

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

Forward-Port-Of: odoo/odoo#143566
Forward-Port-Of: odoo/odoo#141233

Due a typo, sortedKeys were not always cleared when pruning the new trees after an update. Consequently the method _getTableRows could be called on a inexisting sub tree. Here we simply fix the typo and a test. opw-3584675 Forward-Port-Of: odoo/odoo#143712 Forward-Port-Of: odoo/odoo#143318

Due a typo, sortedKeys were not always cleared when pruning the
new trees after an update. Consequently the method _getTableRows could be
called on a inexisting sub tree. Here we simply fix the typo and a test.

opw-3584675

Forward-Port-Of: odoo/odoo#143712
Forward-Port-Of: odoo/odoo#143318

**Description of the issue/feature this PR addresses:** In case of chained stock moves, we need to consider that a purchase order might be linked to other orders which are already fulfilled differently on the same order line, so we filter for those which are still relevant for propagation or change in procure method. You need at least two sale orders linked where one was fulfilled (forced fulfillment of the chained move) **Current behavior before PR:** UserError **Desired behavior aft

**Description of the issue/feature this PR addresses:**
In case of chained stock moves, we need to consider that a purchase order might be linked to other orders which are already fulfilled differently on the same order line, so we filter for those which are still relevant for propagation or change in procure method.

You need at least two sale orders linked where one was fulfilled (forced fulfillment of the chained move)

**Current behavior before PR:**
UserError

**Desired behavior after PR is merged:**
Proper handling of what it was intended to do...

Info: @wt-io-it


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

Forward-Port-Of: odoo/odoo#143338
Forward-Port-Of: odoo/odoo#133001

Since [this other commit], the `link_tools` tour is failing because the `_syncContent` between url and link text is not working anymore. This is due to the ZWS that are added to the link to permit the user to select edges of the link. In addition, this PR prevents the editor to search for anchors when the link URL is an email. This way we prevent an error in the console. [this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35 runbot-18747 Forwa

Since [this other commit], the `link_tools` tour is failing because the `_syncContent` between url and link text is not working anymore. This is due to the ZWS that are added to the link to permit the user to select edges of the link.

In addition, this PR prevents the editor to search for anchors when the link URL is an email. This way we prevent an error in the console.

[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35

runbot-18747

Forward-Port-Of: odoo/odoo#143436
Forward-Port-Of: odoo/odoo#142135

Improve the uninstallation of payment providers by allowing to uninstall payment providers that have a payment method line on a journal but no payment yet. Task id #3595006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142112

Improve the uninstallation of payment providers by allowing to uninstall payment providers that have a payment method line on a journal but no payment yet.

Task id #3595006

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

Forward-Port-Of: odoo/odoo#142112

*: website_livechat. Forward-Port-Of: odoo/odoo#143645 Forward-Port-Of: odoo/odoo#143115

*: website_livechat.

Forward-Port-Of: odoo/odoo#143645
Forward-Port-Of: odoo/odoo#143115

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#143661 Forward-Port-Of: odoo/odoo#143324

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#143661
Forward-Port-Of: odoo/odoo#143324

Steps: - Install project app. - Go to task view from specific project. - Open activity view. - Set an activity on any task. - Click on "Schedule Activity" button. Issue: - User able to select all tasks instead of tasks from that specific project as it is working for first time user opens that view. Cause: - Domain of `SelectCreateDialog` became empty when load calls from other activity view actions. Fix: - Pass props in load method call to have default data as it is when calling

Steps:
- Install project app.
- Go to task view from specific project.
- Open activity view.
- Set an activity on any task.
- Click on "Schedule Activity" button.

Issue:
- User able to select all tasks instead of tasks from that specific project as it is working for first time user opens that view.

Cause:
- Domain of `SelectCreateDialog` became empty when load calls from other activity view actions.

Fix:
- Pass props in load method call to have default data as it is when calling load method.

task-3293310

Forward-Port-Of: odoo/odoo#143721
Forward-Port-Of: odoo/odoo#139810

… to 303|60 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#142027

… to 303|60

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

Previous to this commit, the qty reserved was only considering the currently reserved quantities in the MO, not the ones calculated and displayed in the MO Overview (i.e. including the quantities reserved in the picking during 2 step mrp). This would lead to showing reserved quantities but a "Not Ready" status, which is confusing and inconsistent. Now we pass the calculated component quantities to the method that calculates this state and ensure the calculation is consistent. Steps to repr

Previous to this commit, the qty reserved was only considering the currently reserved quantities in the MO, not the ones calculated and displayed in the MO Overview (i.e. including the quantities reserved in the picking during 2 step mrp). This would lead to showing reserved quantities but a "Not Ready" status, which is confusing and inconsistent.

Now we pass the calculated component quantities to the method that calculates this state and ensure the calculation is consistent.

Steps to reproduce:
- enable 2 or 3 step mrp
- create an MO with a component that is in stock at the stock loc
- confirm MO and open "Overview"

Also change "Quantity" back to "Reserved" in the pdf version of the MO Overview. This was a mistake change since this column name already exists and "Reserved" will be hopefully less confusing for users.




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

Forward-Port-Of: odoo/odoo#140767

Steps: - Install `contacts` and `l10n_se` - Open swedish contact in `contacts` Address are in this format ``` {street} {street2} {city} {state_code} {zip} {country_name} ``` instead of ``` {street} {street2} {zip} {city} {country_name} ``` opw-3393569 Forward-Port-Of: odoo/odoo#142051 Forward-Port-Of: odoo/odoo#131070

Steps:
  - Install `contacts` and `l10n_se`
  - Open swedish contact in `contacts`

Address are in this format
```
{street}
{street2}
{city} {state_code} {zip}
{country_name}
```
instead of
```
{street}
{street2}
{zip} {city}
{country_name}
```

opw-3393569

Forward-Port-Of: odoo/odoo#142051
Forward-Port-Of: odoo/odoo#131070

Before: No lituanian translation was created for this version about the number of remaining products in stock on website ecommerce page. Step to reproduce: - Create a db with the website_sale_stock module - Configure a product in sales tab: active Show available qty with only if below 1000 - Add lituanian language - Go on the product page on the website and change the lanuage in lituanian Now: Translation added opw-3560842 Forward-Port-Of: odoo/odoo#142772 Forward-Port-Of: odoo/odo

Before: No lituanian translation was created for this version about the number of remaining products in stock on website ecommerce page.

Step to reproduce:
- Create a db with the website_sale_stock module
- Configure a product in sales tab: active Show available qty with only if below 1000
- Add lituanian language
- Go on the product page on the website and change the lanuage in lituanian

Now: Translation added

opw-3560842

Forward-Port-Of: odoo/odoo#142772
Forward-Port-Of: odoo/odoo#140523

1. If the name of a product on an imported EDI document is a substring of the name of a product on the DB, said product could be used instead of the correct one, depending on their order (i.e. ID) in the DB. Example: There are 2 products named "Placement" and "Displacement" in a DB. A PDF is imported. It contains a product named "Placement". If the "Displacement" product on the DB appears before the "Placement" one, the product on the AML will be set to the "Displacement" one. To fix

1.
If the name of a product on an imported EDI document is a substring
of the name of a product on the DB, said product could be used instead
of the correct one, depending on their order (i.e. ID) in the DB.

Example: There are 2 products named "Placement" and "Displacement" in
a DB. A PDF is imported. It contains a product named "Placement". If
the "Displacement" product on the DB appears before the "Placement"
one, the product on the AML will be set to the "Displacement" one.

To fix this, we first check if there is a product identically named to
the one in the EDI document.

2.
In case a product from the DB is used, if possible, the UoM used should
be the one present on the EDI document. Thus there should be a check to
ensure that the UoM category on said document matches the one of the
product's UoM before assigning it, to avoid a compatibility error.

Co-authored-by: Julien Van Roy <juvr@odoo.com>

opw-3470969

Forward-Port-Of: odoo/odoo#142754
Forward-Port-Of: odoo/odoo#136109

Steps to reproduce: - Install l10n_sa_edi - Switch to a SA company - Create a 15% INCLUDED tax - Create an invoice: * Customer: [any] * Invoice Lines: - Product: [any] - Quantity: 90 - Price: 200.00 - Taxes: [the 15% INCLUDED tax] - Confirm the invoice and process it by ZATCA service => The invoice is accepted by ZATCA, but there is the following warning: `BR-KSA-EN16931-11 : Invoice line net amount (BT-131) must equal (Invoiced quantity (BT-129) * (Item net pr

Steps to reproduce:
- Install l10n_sa_edi
- Switch to a SA company
- Create a 15% INCLUDED tax
- Create an invoice:
  * Customer: [any]
  * Invoice Lines:
    - Product: [any]
    - Quantity: 90
    - Price: 200.00
    - Taxes: [the 15% INCLUDED tax]
- Confirm the invoice and process it by ZATCA service

=> The invoice is accepted by ZATCA, but there is the following warning:
`BR-KSA-EN16931-11 : Invoice line net amount (BT-131) must equal (Invoiced quantity (BT-129) * (Item net price (BT-146) / item price base quantity (BT-149))) + Sum of invoice line charge amount (BT-141) - Sum of invoice line allowance amount (BT-136)`

Cause:
The net unit price (200 / 1.15) has more than 2 decimals but its value is rounded to the decimal accuracy of "Product Price" (2 digits by default) in the generated EDI document.
When multiplying its rounded value with the quantity, the result is not equal to the invoice line subtotal, which is triggering the warning.

Solution:
Remove the rounding for unit price amount as there is no restriction on its number of decimals.

Reference:
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_unit_price_amount
- https://zatca.gov.sa/ar/E-Invoicing/SystemsDevelopers/Documents/20230519_ZATCA_Electronic_Invoice_XML_Implementation_Standard_%20vTrack.pdf

opw-3509940




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

Forward-Port-Of: odoo/odoo#143348
Forward-Port-Of: odoo/odoo#143131

This commit fixes a visual issue with a label of the properties modal that has a bolder font-weight than the other. This issue comes from the fact we recently changed the behavior of our `bold` and `bolder` variants. To avoid this issue, we simply remove the label to render the text directly inside the `label`. task-3580556  Forward-Port-Of: odoo/odoo#140732

This commit fixes a visual issue with a label of the properties modal that has a bolder font-weight than the other.

This issue comes from the fact we recently changed the behavior of our `bold` and `bolder` variants.

To avoid this issue, we simply remove the label to render the text directly inside the `label`.

task-3580556

![image](https://github.com/odoo/odoo/assets/8558351/860562e9-caa9-4adb-857e-125fc63a528e)

Forward-Port-Of: odoo/odoo#140732

Steps: - Install timesheet. - Go to configuration->projects. - Internal project is visible. - Check the projects menu. - Internal project not visible. - Turn on project stages from the configuration. Issue: - After turning on project stages, the internal project gets visible in projects menu as well. Cause: - We have not set 'is_internal_project' to false for group stages. Fix: - Set 'is_internal_project' to false. task-3392129 Forward-Port-Of: odoo/odoo#143670 Forward-Port

Steps:
- Install timesheet.
- Go to configuration->projects.
- Internal project is visible.
- Check the projects menu.
- Internal project not visible.
- Turn on project stages from the configuration.

Issue:
- After turning on project stages, the internal project gets visible in projects menu as well.

Cause:
- We have not set 'is_internal_project' to false for group stages.

Fix:
- Set 'is_internal_project' to false.

task-3392129

Forward-Port-Of: odoo/odoo#143670
Forward-Port-Of: odoo/odoo#127031

This issue occur When the customer tries to make a payment from Accounting Dashboard of account module,at that time the error will be generated. step to reproduce: - install the `Accounting`. - open the `Accounting`. - go to `Accounting Dashboard` - click on this `⋮` of bank (Right side of top) - click on the payment of view - the error will be generated. sentry traceback- ``` TypeError: account_journal.open_payments_action() missing 1 required positional argument: 'payment_type'

This issue occur When the customer tries to make a payment from Accounting Dashboard of account module,at that time the error will be generated.

step to reproduce:
- install the `Accounting`.
- open the `Accounting`.
- go to `Accounting  Dashboard`
- click on this `⋮` of bank (Right side of top)
- click on the payment of view
- the error will be generated.

sentry traceback-
```
TypeError: account_journal.open_payments_action() missing 1 required positional argument: 'payment_type'
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 28, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 466, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
```

(1) -  https://github.com/odoo/enterprise/pull/49762

accounting to this (1) PR, One link to "Payments" is enough (rather than customer,Payments, Vendor Payments, Internal Transfers) > Those filters exist in the list view of payments

after this commit ,The customer will see "account all payments" if they click on the payment screen.

sentry-4620831582

Forward-Port-Of: odoo/odoo#142649

Steps to reproduce: - Drop a "Share" snippet anywhere on the page and save. - Click on the email icon. - Your default email client should open with, as a subject line, the title of the page where spaces are replaced by +. => This should not be the case, spaces should show as spaces. Since the sharer refactoring in [1], the title of a page used in share buttons of the `s_share` snippet is encoded as a `URLSearchParams()`, which encodes spaces as "+" characters (see the specs [2] of the bu

Steps to reproduce:
- Drop a "Share" snippet anywhere on the page and save.
- Click on the email icon.
- Your default email client should open with, as a subject line, the
title of the page where spaces are replaced by +.
=> This should not be the case, spaces should show as spaces.

Since the sharer refactoring in [1], the title of a page used in share buttons of the `s_share` snippet is encoded as a `URLSearchParams()`, which encodes spaces as "+" characters (see the specs [2] of the built-in method). This works fine for most share buttons, but not for email clients, which do not properly parse the "+". Typically, that means that the subject line of the mailto link is something like "Home+%7CMy+Website", which renders as "Home+|+My+Website" in a mail client, instead of showing spaces.

This commit uses another way to encode the title parameter, so that it works for every share button. It also replaces a space that was encoded twice for Whatsapp.

[1]: https://github.com/odoo/odoo/commit/5297388cd2aa1f693b04538c846c7025e243b09d
[2]: https://url.spec.whatwg.org/#ref-for-urlsearchparams%E2%91%A4

task-3603556

Forward-Port-Of: odoo/odoo#142876

This commit adds the missing neutralisation necessary for the `pos_viva_wallet` module introduced in [1] The purpose of the standard neutralisation framework is to allow us to create database copies that will not interract with external systems in ways that could impact the production database (or if it is not possible to prevent the interractions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is mainl

This commit adds the missing neutralisation necessary for the `pos_viva_wallet`
module introduced in [1]

The purpose of the standard neutralisation framework is to allow us to
create database copies that will not interract with external systems in
ways that could impact the production database (or if it is not possible
to prevent the interractions, make sure that they are benign or wont
result in actual changes), or impact the customers of the operator of
the production database.

This is mainly useful to allow safe support investigation on database
duplicates.

[1] https://github.com/odoo/odoo/pull/140353

Forward-Port-Of: odoo/odoo#143741

**Before this PR** Clicking to review an appointment after creating your first resource-based appointment type with onboarding panel still creates a new one. **After this PR** It opens the existing appointment. Task-3503869 Forward-Port-Of: odoo/enterprise#48091

**Before this PR**
Clicking to review an appointment after creating your first resource-based appointment type with onboarding panel still creates a new one.

**After this PR**
It opens the existing appointment.

Task-3503869

Forward-Port-Of: odoo/enterprise#48091

Issue: ====== In `Parnter Ledger` report it only shows the primary currency symbols and not the foreign currency (If the bill was in foreign currency) Steps to reproduce the issue: ============================= - Make vendor bill in `Accounting` app in a different currency than the journal - Open `Parnter Ledger` report (`Accounting` app > Reporting > Partner Ledger - The `Amount Currency` field will be debited in the journal currency, not the one you specified. (just a wrong symbol, di

Issue:
======
In `Parnter Ledger` report it only shows the primary currency symbols and not the foreign currency (If the bill was in foreign currency)

Steps to reproduce the issue:
=============================
- Make vendor bill in `Accounting` app in a different currency than the journal
- Open `Parnter Ledger` report (`Accounting` app > Reporting > Partner Ledger
- The `Amount Currency` field will be debited in the journal currency, not the one you specified. (just a wrong symbol, digits are fine).
- 
This was due to the transition from version 16.3 > 16.4, in which currency symbols started to appear in the report (in previous versions symbols appeared only if it was a foreign currency), but the logic in the partner ledger remained the same, while the principle of passing a string to the report itself changed. 

Solution
========
I changed the logic of passing currency in report._build_column_dict by adding currency passing to the function and removing variables that are not used.

opw-3584282

Forward-Port-Of: odoo/enterprise#51346
Forward-Port-Of: odoo/enterprise#50361

**Steps to reproduce** Step 1. As a customer, schedule a meeting Step 2. Add extra attendees from the backend through the calendar event Step 3. Now again go to the appointment confirmation page and try to cancel the meeting. -> error(page crash) **Technical** If there are more than 2 attendees in the meeting then the person who is cancelling the meeting should only leave the meeting and his leaving notification should display on the chatter. we are removing the attendee before and t

**Steps to reproduce**

Step 1. As a customer, schedule a meeting
Step 2. Add extra attendees from the backend through the calendar event Step 3. Now again go to the appointment confirmation page and try to cancel the meeting.
-> error(page crash)

**Technical**

If there are more than 2 attendees in the meeting then the person who is cancelling the meeting should only leave the meeting and his leaving notification should display on the chatter.
we are removing the attendee before and then trying to send the message from that attendee, so it is giving a traceback of not finding the record.

**After this PR**

Now the traceback is gone and user can cancel the meeting.

Task-3505659

Forward-Port-Of: odoo/enterprise#51327
Forward-Port-Of: odoo/enterprise#48078

UPS rolled out their REST API with 0Auth credentials and as of June 2023 have stopped issuing new API access keys used by the older SOAP Integration. and as of June 2024, all requests with the old auth will be rejected. The new REST API Integration is added in the new module `delivery_ups_rest` to allow users a period to transition to the new integration. The old module `delivery_ups` is now deprecated and will be deleted in 2024 when it becomes obsolete. taskId: 3349269 COM PR: odoo/o

UPS rolled out their REST API with 0Auth credentials and as of June 2023 have stopped issuing new API access keys used by the older SOAP Integration. and as of June 2024, all requests with the old auth will be rejected.

The new REST API Integration is added in the new module `delivery_ups_rest` to allow users a period to transition to the new integration.

The old module `delivery_ups` is now deprecated and will be deleted in 2024 when it becomes obsolete.

taskId: 3349269
COM PR: odoo/odoo#137713
Github Issue: odoo/odoo#123446

Forward-Port-Of: odoo/enterprise#51304
Forward-Port-Of: odoo/enterprise#43538

Issue: ====== After adding all the values in a sign doucent and then go back to change other fields, clicking in a text field and then clicking on another will make the sign & validate button unresponsive. Steps to reproduce the issue: ============================= - install sign - send a sign request to a customer , the sign document should have at least 2 text fields - - Open the sent link using mobile display and add all tha values but do not validate - Click on any text field - C

Issue:
======
After adding all the values in a sign doucent and then go back to change other fields, clicking in a text field and then clicking on another will make the sign & validate button unresponsive.

Steps to reproduce the issue:
=============================
- install sign
- send a sign request to a customer , the sign document should have at least 2 text fields -
- Open the sent link  using mobile display and add all tha values but do not validate
- Click on any text field
- Click on another text field and click next
- Clicking on the button validate will do nothing.

Origin of the issue:
====================
Toggling between text fields will remove `show` class from the old bottom sheet and add it to the new one. but when closing the new one , the old one will still exist but we can't see it  because it doesn't have the class `show` but it's display is still `block` , that's why clicking on the button validate woudln't work , it's below the div of the bottom sheet.

Solution:
=========
Removing the manual style as block and adding it to the show class so it will be updated automatically when we add/remove the class.

opw-3477410
opw-3511365m

Forward-Port-Of: odoo/enterprise#51526
Forward-Port-Of: odoo/enterprise#51377

minor mistake. `_create_starting_transfer_log` method defined on `sale.order.log` model but given wrong reference by mistake to `sale_subscription`. so got error during upgrade database ``` File "/home/odoo/src/enterprise/17.0/sale_subscription/models/sale_order_log.py", line 132, in _create_mrr_log return sub._create_starting_transfer_log(sub, values.copy()) AttributeError: 'sale.order' object has no attribute '_create_starting_transfer_log' ``` Forward-Port-Of: odoo/enterprise#5

minor mistake. `_create_starting_transfer_log` method defined on `sale.order.log` model but given wrong reference by mistake to `sale_subscription`. so got error
during upgrade database

```
  File "/home/odoo/src/enterprise/17.0/sale_subscription/models/sale_order_log.py", line 132, in _create_mrr_log
    return sub._create_starting_transfer_log(sub, values.copy())
AttributeError: 'sale.order' object has no attribute '_create_starting_transfer_log'
```

Forward-Port-Of: odoo/enterprise#51549

As this community PR https://github.com/odoo/odoo/pull/143348 is removing the rounding on unit price amount, some tests have to be adapted. opw-3509940 Forward-Port-Of: odoo/enterprise#51469

As this community PR https://github.com/odoo/odoo/pull/143348 is removing the rounding on unit price amount, some tests have to be adapted.

opw-3509940

Forward-Port-Of: odoo/enterprise#51469

Steps ===== - Open app Project - In settings of Project activate task dependencies - Open a project with dependencies between task (e.g. research and development in demo data) - Go to the Gantt view of the tasks of this project in mobile view (or with as small window) - Deactivate all filters to ensure that tasks with dependencies appear in the current view - Switch to desktop view (or resize the window) Issue ===== A traceback appears indicating "Cannot read properties of undefined

Steps
=====
- Open app Project
- In settings of Project activate task dependencies
- Open a project with dependencies between task (e.g. research and development in demo data)
- Go to the Gantt view of the tasks of this project in mobile view (or with as small window)
- Deactivate all filters to ensure that tasks with dependencies appear in the current view
- Switch to desktop view (or resize the window)

Issue
=====
A traceback appears indicating "Cannot read properties of undefined (reading '__pill__1')".

Cause
=====
The connections between dependent pill is only displayed if the user is not in mobile view. To avoid unecessary memory allocation, some variable used to manage the connections display (e.g. mappingPillToConnectors), are only declared if the user is not in mobile view. However, when resizing the window (or leaving mobile view), the onWillRender method is called and can make use of those variables if the connections need to be displayed. This create the traceback are those variables have not been declared.

Fix
===
The method computeDerivedParams used to manage such variable declaration is called in the onWillRender method under the condition that connectors were not present in the previous render (i.e. it was in mobile view).

Forward-Port-Of: odoo/enterprise#50525
Forward-Port-Of: odoo/enterprise#48107

1) Steps: - Install sale,timesheet and helpdesk app. - Add a timesheet and validate it. Issue: - Some field are not read-only even though timesheets are validated. Cause: - After this PR-https://github.com/odoo/enterprise/pull/24609 some of read-only attrs overridden by invisible attrs. Fix: - Add read-only attrs with invisible attrs in inherited views. 2) Before this commit user avatar and it's label are not correctly aligned. This commit align label and avatar by giving

1) Steps:
- Install sale,timesheet and helpdesk app.
- Add a timesheet and validate it.

Issue:
- Some field are not read-only even though timesheets
are validated.

Cause:
- After this PR-https://github.com/odoo/enterprise/pull/24609 some of
read-only attrs overridden by invisible attrs.

Fix:
- Add read-only attrs with invisible attrs in inherited views.

2) Before this commit user avatar and it's label are not
correctly aligned.

This commit align label and avatar by giving padding to
to label of avatar.

3) Step:
- Install planning.
- Go to form view of shift.

Issue:
- Percentage field has more width than needed.

Cause:
- `oe_inline` give mw inherit to float field.

Fix:
- Added `o_field_percentage` class to get 7ch width same
as percentage field.

task-3282848

Forward-Port-Of: odoo/enterprise#51522
Forward-Port-Of: odoo/enterprise#37155

**Steps:** - Open Timesheet - In Grid View apply groupby - Switch to List View or Kanban View - Click on the start timer **Issue:** - on click of the start timer, we get a traceback **Cause:** - Due to some missing fields, the function is not able to get the correct values and so the values appear to be undefined. This is mainly because the parameters are wrongly passed. When the view is normally loaded, commonRecordParams are passed but when groupby is applied, commonGroupParams sho

**Steps:**
- Open Timesheet
- In Grid View apply groupby
- Switch to List View or Kanban View
- Click on the start timer

**Issue:**
- on click of the start timer, we get a traceback

**Cause:**
- Due to some missing fields, the function is not able to get the correct values and so the values appear to be undefined. This is mainly because the parameters are wrongly passed. When the view is normally loaded, commonRecordParams are passed but when groupby is applied, commonGroupParams should be applied as it has some extended parameters.

**Fix:**
- passing commonGroupParams along with commonRecordParams so that we do not get the undefined values.

task-3422009

Forward-Port-Of: odoo/enterprise#50095
Forward-Port-Of: odoo/enterprise#44063

The [refactoring] of knowledge macros introduced 2 kinds of errors that are fixed in this work: 1) An infinite loop during a macro if a Knowledge article is accessed by going back in the breadcrumbs from any Form view (the macro button should not be visible in that case since the controller of the Form view is not accessible after going back). 2) An error saying that the "record can not be found" whilst the macro is actually succeeding in loading the correct record, that is caused by

The [refactoring] of knowledge macros introduced 2 kinds of errors that are 
fixed in this work:

1) An infinite loop during a macro if a Knowledge article is accessed by going
back in the breadcrumbs from any Form view (the macro button should not be
visible in that case since the controller of the Form view is not accessible
after going back).

2) An error saying that the "record can not be found" whilst the macro is
actually succeeding in loading the correct record, that is caused by the fact
that an embedded view in an article can have breadcrumbs that make the macro
advance too fast.

See each commit for more details.

[refactoring]: https://github.com/odoo/enterprise/commit/1fc6c7ef19462eda0cacfccb242f88e495f8ab1f

task-3598754

Forward-Port-Of: odoo/enterprise#50779

The newly added widget for file generation error added in this commit https://github.com/odoo/enterprise/commit/49c9dc9151435fddfc2e3b62ad397015f144a7b6 needs a minor fix to be able to handle methods that have multiple arguments. task-3610890 Forward-Port-Of: odoo/enterprise#51456

The newly added widget for file generation error added in this commit https://github.com/odoo/enterprise/commit/49c9dc9151435fddfc2e3b62ad397015f144a7b6 needs a minor fix to be able to handle methods that have multiple arguments.

task-3610890

Forward-Port-Of: odoo/enterprise#51456

This fix makes the helper of the closing entry button of the tax report be markuped as it is currently not the case and its content is in plain text. Forward-Port-Of: odoo/enterprise#51318 Forward-Port-Of: odoo/enterprise#50914

This fix makes the helper of the closing entry button of the tax report be markuped as it is currently not the case and its content is in plain text.

Forward-Port-Of: odoo/enterprise#51318
Forward-Port-Of: odoo/enterprise#50914

In this commit (https://github.com/odoo/enterprise/commit/6c570325dc64adba441c748d834cee2c0fe488b7), there has been a changed in the options of reports and the consolidation report was impacted. In the PR, we will come back to the behavior of the 16.3 version task: 3471071 Forward-Port-Of: odoo/enterprise#51430 Forward-Port-Of: odoo/enterprise#46076

In this commit (https://github.com/odoo/enterprise/commit/6c570325dc64adba441c748d834cee2c0fe488b7), there has been a changed in the options of reports and the consolidation report was impacted. In the PR, we will come back to the behavior of the 16.3 version

task: 3471071

Forward-Port-Of: odoo/enterprise#51430
Forward-Port-Of: odoo/enterprise#46076

WhatsApp category was shown in Discuss app sidebar in desktop, but was not visible in the bottom navbar in mobile. Part of Task-3525542 opw-3580979 Forward-Port-Of: odoo/enterprise#51393

WhatsApp category was shown in Discuss app sidebar in desktop, but was not visible in the bottom navbar in mobile.

Part of Task-3525542
opw-3580979

Forward-Port-Of: odoo/enterprise#51393

Issue: This SQL query is slow when an user has a big quantity of account move lines and products. Analyze: In this query it joins the table of account_move_line with product_product to check if the product is active which is causing the slowness. The issue is that the CTEs are inlined by the planner due to this Postgres commit : postgres/postgres@608b167f. The source and ranking CTE become a single SQL query and thus the tsvector Filter is run on all the account_move_line instead of th

Issue:
This SQL query is slow when an user has a big quantity of account move lines and products.

Analyze:
In this query it joins the table of account_move_line with product_product to check if the product is active which is causing the slowness.
The issue is that the CTEs are inlined by the planner due to this Postgres commit
: postgres/postgres@608b167f.

The source and ranking CTE become a single SQL query and thus the tsvector Filter is run on all the account_move_line instead of the query limitation number. To solve the planner has to execute the first query (first_source) and then the second (source) on the result of first_source.

Fix:
In order to force the planner to make the limit on account_move_line a MATERIALIZED view has been used.
(https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-CTE-MATERIALIZATION)

Note:
MATERIALIZED views have been implemented on PSQL 12. But all Odoo's internal servers (both Odoo.sh and SaaS) haven't any server running a previous version.

Benchmark:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
|   3M AML               |    28.579 s            |     59.4 ms |
|   47 AML (demo data)                  |    1.262ms (planning) + 0.682 ms (execution)            |   5.289 ms + 0.994 ms            |

Related task:
opw-3539632 (Query and Planners are available in the task)

Forward-Port-Of: odoo/enterprise#51211
Forward-Port-Of: odoo/enterprise#50911

Purpose ======== Update demo data to better show what Appointment can do. Specification ============== 1). Changing the capacity of some tables -> Tables 1-4 => from 4 to 2. -> Tables 9-11 => from 4 to 6. 2). Main Floor Tables -> Linking all main floor tables to main floor table 1. 3). Changing the name of the Table 12 -> Table 12 (Patio) to 12-Patio (4). 4). Changing the resource name -> Table 3 (2) to Table 3 (🪑2) Technical ========== For the 3rd point, the eval was

Purpose
========
Update demo data to better show what Appointment can do.

Specification
==============
1). Changing the capacity of some tables
-> Tables 1-4 => from 4 to 2.
-> Tables 9-11 => from 4 to 6.

2). Main Floor Tables
-> Linking all main floor tables to main floor table 1.

3). Changing the name of the Table 12
-> Table 12 (Patio) to  12-Patio (4).

4). Changing the resource name
-> Table 3 (2) to Table 3 (🪑2)

Technical
==========
For the 3rd point, the eval was not given correctly so the name of the table changed from 12-Patio to Table 12 (Patio).

Task-3496910

Forward-Port-Of: odoo/enterprise#48438

This traceback arises when the user tries to click on Recent in Softphone To reproduce this issue: 1. Install `VoIP` 2. Open `Discuss/Softphone/Recent` 3. Try to search for something in the Voip search bar Error: ``` ValueError: too many values to unpack (expected 3) File "odoo/http.py", line 2157, in __call__ response = request._serve_db() File "odoo/http.py", line 1732, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "odoo/service

This traceback arises when the user tries to click on Recent in Softphone

To reproduce this issue:
1. Install `VoIP`
2. Open `Discuss/Softphone/Recent`
3. Try to search for something in the Voip search bar

Error: 

```  ValueError: too many values to unpack (expected 3)
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 462, in call_kw
    result = _call_kw_model(method, model, args, kwargs)
  File "odoo/api.py", line 435, in _call_kw_model
    result = method(recs, *args, **kwargs)
  File "home/odoo/src/enterprise/17.0/voip/models/voip_call.py", line 85, in get_recent_phone_calls
    return self.search(domain, offset=offset, limit=limit, order="create_date DESC")._format_calls()
  File "odoo/models.py", line 1604, in search
    return self.search_fetch(domain, [], offset=offset, limit=limit, order=order)
  File "odoo/models.py", line 1627, in search_fetch
    query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
  File "odoo/models.py", line 5366, in _search
    query = self._where_calc(domain)
  File "odoo/models.py", line 5081, in _where_calc
    return expression.expression(domain, self).query
  File "odoo/osv/expression.py", line 788, in __init__
    self.expression = domain_combine_anies(domain, model)
  File "odoo/osv/expression.py", line 597, in domain_combine_anies
    domain_any = _anyfy_leaves(domain, model)
  File "odoo/osv/expression.py", line 371, in _anyfy_leaves
    left, operator, right = item = tuple(item)
```

When the user tries to search for something in the search bar an invalid domain format is formed in `get_recent_phone_call`method. Which leads to the traceback from here

https://github.com/odoo/enterprise/blob/5c42708683905cfb5fe8c1005aabbbc9fb016fa2/voip/models/voip_call.py#L79-L85

After applying this commit will resolve the issue by giving a valid domain format to search.

sentry-4644858097

Forward-Port-Of: odoo/enterprise#51276

This commit does 2 things: - avoids an error occurring when scanning a source location that has no (remaining) reserved qtys at that location to scan. Issue was due to: https://github.com/odoo/enterprise/blob/61d3aa2d4ba7540803b88ca4f426e6ee6503e8dd/stock_barcode/static/src/models/barcode_picking_model.js#L165 still being used by barcode_mrp_model, but this.needSourceConfirmation is set to `false` in the mrp model, so an error is thrown because booleans don't have an index. O

This commit does 2 things:

- avoids an error occurring when scanning a source location that has no
  (remaining) reserved qtys at that location to scan. Issue was due to:

https://github.com/odoo/enterprise/blob/61d3aa2d4ba7540803b88ca4f426e6ee6503e8dd/stock_barcode/static/src/models/barcode_picking_model.js#L165

  still being used by barcode_mrp_model, but this.needSourceConfirmation
  is set to `false` in the mrp model, so an error is thrown because
  booleans don't have an index. Originally it was thought this
  (picking) feature wasn't wanted for MOs, but this has been
  reconsidered and we now want it (afterall, it is better to have
  consistent behavior).

  Note that in order to add this check in, the _createNewLine in MOs had
  to be adjusted so that the assignment of the final product for an MO
  created from scratch occurred before the check:
  https://github.com/odoo/enterprise/blob/57986a41fb80deecd7c4d2a374afa801bc44a507/stock_barcode/static/src/models/barcode_picking_model.js#L51

  because the this.location will throw a cache error due to there being
  no default location to find (i.e. there are no locations for the MO
  yet). No tests were added for this because existing tours already
  failed when creating MOs from scratch.

  Steps to reproduce:
  - activate multi-locations + set barcode setting for manufacture
    picking type: `restrict_scan_source_location`=`mandatory`
  - create 2 products, 1 with stock in WH/Stock, the other with stock in
    WH/Stock/Shelf 1, both with barcodes
  - create MO using those 2 products + reserve
  - open MO in barcode, scan "Shelf 1" barcode + scan component in that
    loc
  - scan "WH/Stock"

  expected result: should switch source locations + should be able to
  scan the other component

  actual result: JS error

- adds in a test to avoid the same mistake that is fixed in the COM PR
  of this branch. Existing test has been redone so the test includes:
  + the above location switching scanning (to scan a non-reserved
    component)
  + the mandatory consumption check
  + the original test of scanning a diff lot than the one already
    reserved

COM PR: https://github.com/odoo/odoo/pull/142933

Forward-Port-Of: odoo/enterprise#51171

In barcode app, we need to apply a responsible filter for manufacturing orders. Only MO that are assigned to the user or unassigned should be displayed. task-3547356 Forward-Port-Of: odoo/enterprise#49802

In barcode app, we need to apply a responsible filter for manufacturing orders. Only MO that are assigned to the user or unassigned should be displayed.

task-3547356

Forward-Port-Of: odoo/enterprise#49802

Currently in barcode app, you are limited to scan sub location of the picking. However in some cases, you would like to move the picking to another zone than initialy plan. Forward-Port-Of: odoo/enterprise#49814

Currently in barcode app, you are limited to scan sub location of the picking. However in some cases, you would like to move the picking to another zone than initialy plan.

Forward-Port-Of: odoo/enterprise#49814

task-3568861 See also: - https://github.com/odoo/odoo/pull/139556 Forward-Port-Of: odoo/enterprise#50783 Forward-Port-Of: odoo/enterprise#49894

task-3568861

See also:
- https://github.com/odoo/odoo/pull/139556

Forward-Port-Of: odoo/enterprise#50783
Forward-Port-Of: odoo/enterprise#49894

If mrp_workorder_expiry module is installed a skip_expired context key is defined on the two buttons "Mark as Done" and "Mark as Done and Close MO". However, the context key was not transmitted properly to the backend because params.context is a string, whereas this.props.context is an Object, resulting in a new context were only the key/values from this.props.context were consistent, while the string in params.context was exploded in multiple characters. Forward-Port-Of: odoo/enterprise#48988

If mrp_workorder_expiry module is installed a skip_expired context key is defined on the two buttons "Mark as Done" and "Mark as Done and Close MO". However, the context key was not transmitted properly to the backend because params.context is a string, whereas this.props.context is an Object, resulting in a new context were only the key/values from this.props.context were consistent, while the string in params.context was exploded in multiple characters.

Forward-Port-Of: odoo/enterprise#48988

When using 'resource_time' without pictures, the name of the variable within the resource loop in the select is 'resource', which is also the name of the resource described in the details right column. Therefore, the last resource was always shown. It should not be shown at all. Templates are updated to have unique names. Also, when selecting a user in operator screen (when website is installed and pictures are enabled), their info is not showing on the right column on time selection s

When using 'resource_time' without pictures, the name
of the variable within the resource loop in the select is
'resource', which is also the name of the resource described
in the details right column. Therefore, the last resource was
always shown. It should not be shown at all. Templates are
updated to have unique names.

Also, when selecting a user in operator screen (when website is
installed and pictures are enabled), their info is not showing on
the right column on time selection screen.

We also remove isOperator as not strcitly useful but instead
explicitely set resource to False in appointment_select_operator
in order to make sure it is not used as a selected resource in
other templates. This is necessary because of the loop on
available resources using t-as="resource". This solution avoids
renaming all instances in that template.


Task-3588251

Forward-Port-Of: odoo/enterprise#50826

Issue: ------ The purpose of the `signature_count` field is to count the number of signature requests. However, it counts signatures that have been archived. For example, in the recruitment application, when we want to see the number of requests sent to a job application. Solution: --------- Modify the domain to take status into account and display only signatures that are `sent` and `completed`. opw-3550893 Forward-Port-Of: odoo/enterprise#51372 Forward-Port-Of: odoo/enterprise#509

Issue:
------
The purpose of the `signature_count` field is to count the number of signature requests.
However, it counts signatures that have been archived.
For example, in the recruitment application, when we want to see the number of requests sent to a job application.

Solution:
---------
Modify the domain to take status into account and display only signatures that are `sent` and `completed`.

opw-3550893

Forward-Port-Of: odoo/enterprise#51372
Forward-Port-Of: odoo/enterprise#50907