With tens of millions of channels, the query for getting the channels of the current user goes from 1.2s to 6ms. `auto_join` makes sense as channels are almost always fetched together with member (and in particular for checking ACL of member). Forward-Port-Of: odoo/odoo#167205

With tens of millions of channels, the query for getting the channels of the current user goes from 1.2s to 6ms.

`auto_join` makes sense as channels are almost always fetched together with member (and in particular for checking ACL of member).

Forward-Port-Of: odoo/odoo#167205

This commit adds a check to ensure that the listId exists when processing the command `UPDATE_ODOO_LIST_DOMAIN` in the `beforeHandle` function. Task: 3908657 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#167000 Forward-Port-Of: odoo/odoo#166797

This commit adds a check to ensure that the listId exists when processing the command `UPDATE_ODOO_LIST_DOMAIN` in the `beforeHandle` function.

Task: 3908657

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#167000
Forward-Port-Of: odoo/odoo#166797

Current behavior: When using a loyalty program that grant 1 free product for each product bought the wrong product was added. This only hapens when the reward product is a tag. For example if you buy product A you get one product A free and if you buy one product B you also get a product A free when you should get a product B free. Steps to reproduce: - Create tag T that should includes product A and B - Create a loyalty program : . grant 1 point per unit paid among tag T products . get 1

Current behavior:
When using a loyalty program that grant 1 free product for each product bought the wrong product was added. This only hapens when the reward product is a tag. For example if you buy product A you get one product A free and if you buy one product B you also get a product A free when you should get a product B free.

Steps to reproduce:
- Create tag T that should includes product A and B
- Create a loyalty program : . grant 1 point per unit paid among tag T products . get 1 free product among tag T products for 1 point
- Open PoS session, and add 2 product A, you get one product A free
- Add 2 product B, you also get one product A free

Note:
When adding the second B product it's actually adding the correct product, but when recomputing the rewards it's adding two products A.

opw-3836634

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

before this commit: users without read permission of ir.module.category cannot search res.groups by names. An access error will be raised. after this commit: all users with read permission of res.groups can search res.groups by names Backport of odoo/odoo#97877 with small fix for bool case Forward-Port-Of: odoo/odoo#108204 Forward-Port-Of: odoo/odoo#108155

before this commit:
users without read permission of ir.module.category cannot search res.groups by names. An access error will be raised.

after this commit:
all users with read permission of res.groups can search res.groups by names

Backport of odoo/odoo#97877 with small fix for bool case

Forward-Port-Of: odoo/odoo#108204
Forward-Port-Of: odoo/odoo#108155

Activate Margins and Margin Analysis Create a new product [TEST] with no price set (0.0) Create a SO Add a line with [TEST] setting a unit price of 100 Margin will be 100 Confirm sale, create and confirm the invoice Go to Accounting>Reporting>Invoice Analysis Switch to pivot view Enable Margin mesure Issue: Margin for invoice will not be set This occurs because the price has not set so the sql computation for the margin will be NULL opw-3916863 Forward-Port-Of: odoo/odoo#166845

Activate Margins and Margin Analysis
Create a new product [TEST] with no price set (0.0) Create a SO
Add a line with [TEST] setting a unit price of 100 Margin will be 100
Confirm sale, create and confirm the invoice
Go to Accounting>Reporting>Invoice Analysis
Switch to pivot view
Enable Margin mesure

Issue: Margin for invoice will not be set
This occurs because the price has not set so the sql computation for the margin will be NULL

opw-3916863

Forward-Port-Of: odoo/odoo#166845

Update tax codes: - IVA 5% (411, Bienes) -> _IVA 5% (435, Bienes) (code_base: 435, code_applied: 445)_ - IVA 5% (510, Crédito IVA) -> _IVA 5% (550, Crédito IVA) (code_base: 550, code_applied: 560)_ Create Report lines: - _Ventas locales (excluye activos fijos) gravadas tarifa 5%_ - _Adquisiciones y pagos locales (excluye activos fijos) gravados con tarifa 5% (con derecho a crédito tributario)_ Forward-Port-Of: odoo/odoo#165672

Update tax codes:

- IVA 5% (411, Bienes)  ->  _IVA 5% (435, Bienes) (code_base: 435, code_applied: 445)_
- IVA 5% (510, Crédito IVA) -> _IVA 5% (550, Crédito IVA)  (code_base: 550, code_applied: 560)_

Create Report lines:

- _Ventas locales (excluye activos fijos) gravadas tarifa 5%_
- _Adquisiciones y pagos locales (excluye activos fijos) gravados con tarifa 5% (con derecho a crédito tributario)_

Forward-Port-Of: odoo/odoo#165672

Purpose ======= Fix the course title which was truncated with a single letter in the website breadcrumbs. Specification ============= The course title breadcrumb had its width limited by a w-25 class which always prevented the title from being fully visible. Removing that class and allowing each breadcrumb to take the whole available width before being truncated. Also adding the "title" attribute on each breadcrumb so that, even truncated, hovering on it will still make them readable.

Purpose
=======
Fix the course title which was truncated with a single letter in the website breadcrumbs.

Specification
=============
The course title breadcrumb had its width limited by a w-25 class which always prevented the title from being fully visible. Removing that class and allowing each breadcrumb to take the whole available width before being truncated.
Also adding the "title" attribute on each breadcrumb so that, even truncated, hovering on it will still make them readable.

Co-authored-by: pko-odoo pko@odoo.com
Co-authored-by: amdi-odoo amdi@odoo.com

Task-3876972


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

Forward-Port-Of: odoo/odoo#167013
Forward-Port-Of: odoo/odoo#165625

Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161821

Problem:
* If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error.

Notes about fix:
* The error is caused by a hr_fleet child field being accessed in the base Vehicle model.

opw-3858626

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

Forward-Port-Of: odoo/odoo#161821

# Current behavior: Cancelling a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client they had PO with more than 200 lines which makes it impossible for them to cancel them. # Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Confirm the PO - Try to cancel it - Take a long time or timeout # Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:----

# Current behavior:
Cancelling a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client they had PO with more than 200 lines which makes it impossible for them to cancel them.

# Step to reproduce:
- Install mrp and mrp_subcontracting
- Create PO with more than 50 order lines or more
- Confirm the PO
- Try to cancel it
- Take a long time or timeout

# Benchmark (made in 16):
| No. of PO lines | Before  | After  |
|-----------------|:-------:|:------:|
| 9               |   650ms |  600ms |
| 91              |  1min26 |     9s |
| 273             |  4min50 |    34s |
| 405             |  7min13 |    55s |

# Fix:
Batch more actions and records to reduce the number of queries generated by the ORM.

# Reference:
opw-3690875

Forward-Port-Of: odoo/odoo#166728
Forward-Port-Of: odoo/odoo#151526

Description of the issue/feature this PR addresses: This PR aims to address the issue where the cancel buttons (on transfer and MO) are prone to accidental presses due to their proximity. Currently, pressing the cancel button immediately cancels the transfer or MO. Current behavior before PR: Pressing the cancel button results in immediate cancellation of the transfer or MO. Desired behavior after PR is merged: After merging this PR, Odoo will prompt for confirmation when the cancel but

Description of the issue/feature this PR addresses:
This PR aims to address the issue where the cancel buttons (on transfer and MO) are prone to accidental presses due to their proximity. Currently, pressing the cancel button immediately cancels the transfer or MO.

Current behavior before PR:
Pressing the cancel button results in immediate cancellation of the transfer or MO.

Desired behavior after PR is merged:
After merging this PR, Odoo will prompt for confirmation when the cancel button on a transfer or MO is pressed. This will help prevent accidental cancellations. Additionally, the confirmation warning should always be present for both cancel buttons on the MO to ensure consistency.
See below attached for a confirmation message:
On transfer,
![picking_cancel_warning](https://github.com/odoo/odoo/assets/150078409/822c2182-9916-45ac-a355-10fd578ba6a4)

On MO,
![mo_cancel_warning](https://github.com/odoo/odoo/assets/150078409/6842e4b0-95e7-4925-88e2-a8bc55941265)


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

Forward-Port-Of: odoo/odoo#160609

There is a traceback when editing the `amount_currency` field in the "Journal Items" tab of an inovice. It happens when account_3way_match is installed. The commit that introduced the traceback: 87a1ebb338277e45d2367344c212d4867405b7a4 Related commit setting the `bin_size` key to `True` ebd538a1942c532bcf1c9deeab3c25efe23b6893 A test was added to the account_3way_match module in the related enterprise PR. enterprise PR: https://github.com/odoo/enterprise/pull/63339 related PR: t

There is a traceback when editing the `amount_currency` field in the "Journal Items" tab of an inovice.
It happens when account_3way_match is installed.

The commit that introduced the traceback:
87a1ebb338277e45d2367344c212d4867405b7a4

Related commit setting the `bin_size` key to `True` ebd538a1942c532bcf1c9deeab3c25efe23b6893

A test was added to the account_3way_match module in the related enterprise PR.

enterprise PR: https://github.com/odoo/enterprise/pull/63339

related PR: that fixes account_3way_match: https://github.com/odoo/enterprise/pull/63336 (16.0)

Forward-Port-Of: odoo/odoo#167014

Commit 9ca10649b857f8ba4d7f212200a64f98d5e8582b corrected the opening of the "detailed operation for subcontracting stock moves but uses a wrong icon to display in the list view. 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#167051

Commit 9ca10649b857f8ba4d7f212200a64f98d5e8582b corrected the opening of the "detailed operation for subcontracting stock moves but uses a wrong icon to display in the list view.

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

When connecting to a remote server using the "certificate" authentication method, both a x509 PEM certificate and a PEM public key are required. Forward-Port-Of: odoo/odoo#166870 Forward-Port-Of: odoo/odoo#163584

When connecting to a remote server using the "certificate" authentication method, both a x509 PEM certificate and a PEM public key are required.

Forward-Port-Of: odoo/odoo#166870
Forward-Port-Of: odoo/odoo#163584

Before this commit, there was a race condition in the way kanban progressbar were handled: when the kanban view was reloaded, two (sequences of) rpcs were done: 1) by the model, to load the data (e.g. 1 web_read_group followed by n web_search_read) 2) by the progress bar hook, to load progressbar data. 1 and 2 weren't synchronized, and if 2 returned after 1, the view wasn't re-rendered to reflect the new progressbar data. This issue was caused by a misuse of owl reactivity: in th

Before this commit, there was a race condition in the way kanban
progressbar were handled: when the kanban view was reloaded, two
(sequences of) rpcs were done:
 1) by the model, to load the data (e.g. 1 web_read_group followed
    by n web_search_read)
 2) by the progress bar hook, to load progressbar data.

1 and 2 weren't synchronized, and if 2 returned after 1, the view
wasn't re-rendered to reflect the new progressbar data. This issue
was caused by a misuse of owl reactivity: in the progressbar hook,
in onWillUpdateProps, we didn't call loadProgressBar on the reactive
version of the progressbar state, so changes in that state didn't
trigger a rendering.

Fixing this highlighted a bunch of other issues, all of them kind
of related to the fact that the model and the progressbar don't
synchronize when fetching their data. In particular, scenarios
where the progressbar data was loaded before the kanban data failed,
because the rendering triggered by the progressbar state mutation
(now that it is reactive) altered its caches (see `getGroupInfo`)
or even the groups (see `applyFilter`), with almost outdated
datapoints that were about to be replaced (as soon as the new root
would be loaded).

Properly fixing this isn't possible in stable versions as it might
require an in-depth rework of the way the progressbar interacts
with the model. This will be done in master.

For stable, we found a workaround that seems to be enough: instead
of hooking on `onWillUpdateProps` to reload the progressbar (i.e.
in parallel of the model), we hook on `onWillRender` (i.e. once
the model has loaded the data), and we only load the progressbar
data when the root changed (i.e. as often as before). But by doing
that sequentially, we ensure that the data are always loaded first,
and that the rendering produced by the mutations done on the
progressbar state is done with the correct datapoints.

Master task-3928143

opw-3634027

Forward-Port-Of: odoo/odoo#166055
Forward-Port-Of: odoo/odoo#149626

 This `next_serial` argument was added in https://github.com/odoo/odoo/pull/117513. Forward-Port-Of: odoo/odoo#165034

![Selection_3178](https://github.com/odoo/odoo/assets/25005517/b57d3321-6727-496b-bb6a-def6f3c2a436)

This `next_serial` argument was added in https://github.com/odoo/odoo/pull/117513.

Forward-Port-Of: odoo/odoo#165034

Since [this other commit], we match all purchase orders using the vendor bill reference. However, this was not working for factur-x because the `invoice_origin_node` was not being found. This commit addresses the issue by correctly identifying and searching for the appropriate XML node. [this other commit]: https://github.com/odoo/odoo/commit/f39c28ec451daaa54ad00c26815c9cde6acf7e4a task-3932965 Forward-Port-Of: odoo/odoo#166199

Since [this other commit], we match all purchase orders using the vendor bill reference. However, this was not working for factur-x because the `invoice_origin_node` was not being found. This commit addresses the issue by correctly identifying and searching for the appropriate XML node.

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

task-3932965

Forward-Port-Of: odoo/odoo#166199

Issue: ===== We can't scroll in iframe using the mouse (no scroll available) Steps to reproduce the issue: ============================= - Install events, mass_mailing - Go to any event and click invite - Choose any template - You can't scroll inside the template Origin of the issue: ==================== Many other apps inherits the view with id `view_mail_mass_mailing_form` and not the view with id `mailing_mailing_view_form_full_width` which have the logic of resizing the ifra

Issue:
=====
We can't scroll in iframe using the mouse (no scroll available)

Steps to reproduce the issue:
=============================
- Install events, mass_mailing
- Go to any event and click invite
- Choose any template
- You can't scroll inside the template

Origin of the issue:
====================
Many other apps inherits the view with id `view_mail_mass_mailing_form`
and not the view with id `mailing_mailing_view_form_full_width` which
have the logic of resizing the iframe to the length of its content
(introduced here [1]) so we don't really need to scroll inside the
iframe. But for the other apps since they inherit from the first
mentioned view, they will have the iframe class `.o_mass_mailing_iframe`
but we specified in mass_mailing.ui.scss file that html that have that
class we don't assign `overflow:visible` to them , that's why we can't
scroll inside the iframe.

Solution:
=========
There are a lof of ways to solve this problem but most of them needs an
xml change which requires an update of the module. The current solution
is to add a special class to the full_width view using js from it's
already defined js_class and then we exclude it from the scss selector.

opw-3897165

[1]: https://github.com/odoo/odoo/commit/8a74c1f79340c58d62c9577f1011d9dc6a58ff70

Forward-Port-Of: odoo/odoo#164666

We prepare the following fix by adding a modelParam getter that can be overridden by sub-classes. How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document name is not renamed. In the kanban and list view, the document is updated because multiEdit model parameter is enabled. It is not the case for the activity view. Similarly to what is done in li

We prepare the following fix by adding a modelParam getter that can be overridden by sub-classes.

How to reproduce:
1. Schedule an activity for a document.
2. Go to activity view.
3. Select the document to preview in the inspector.
4. Rename the document.
5. Refresh the page.

The document name is not renamed.

In the kanban and list view, the document is updated because multiEdit model parameter is enabled. It is not the case for the activity view.

Similarly to what is done in list and kanban controller, we add a modelParam getter to the activity controller to allow to override the parameters in subclasses which will allows to enable the multiEdit parameter in the document activitty controller.

Task-3817795

Forward-Port-Of: odoo/odoo#164052
Forward-Port-Of: odoo/odoo#158874

Description of the issue/feature this PR addresses: Fix the way that product_id, and set_qty parameters are handled. Because of the way `website_sale_loyalty` handles base arguments in it's `_cart_update` override, all overrides of that method, that earlier, need to pass arguments to super by key instead of position. Otherwise, an error is raised, because the override in question, receives those parameters in args, instead of kwargs, producing a KeyError. This should not be something a commun

Description of the issue/feature this PR addresses:
  Fix the way that product_id, and set_qty parameters are handled. Because of the way `website_sale_loyalty` handles base arguments in it's `_cart_update` override, all overrides of that method, that earlier, need to pass arguments to super by key instead of position. Otherwise, an error is raised, because the override in question, receives those parameters in args, instead of kwargs, producing a KeyError. This should not be something a community plugin should need to worry about. This commit makes it so, the override is declared with explicitly stated base arguments, instead of using `*args`, and `**kwargs`. This not only fixes the issue, but also simplifies the method.

Current behavior before PR:
  If any potential `_cart_update` overrides call `super` with position based arguments, a KeyError is raised.

Desired behavior after PR is merged:
  `super` may be called with either key and position based arguments in `_cart_update` overrides.


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

Forward-Port-Of: odoo/odoo#165033

Before this commit, drag-and-drop functionality for groups/records in the kanban view did not work properly if the user lacked write access. Steps to Reproduce: - Log in to Odoo as Marc Demo. - Open the Project module. - Attempt to drag and drop any group/record in the kanban view. Observed Behavior: The group in the kanban view does not reset to its original position if the user lacks the right to reorder the groups/records, rendering the group/record immovable. Expected Behavior

Before this commit, drag-and-drop functionality for groups/records in the kanban view did not work properly if the user lacked write access.

Steps to Reproduce:

- Log in to Odoo as Marc Demo.
- Open the Project module.
- Attempt to drag and drop any group/record in the kanban view.

Observed Behavior:
The group in the kanban view does not reset to its original position if the user lacks the right to reorder the groups/records, rendering the group/record immovable.

Expected Behavior:
The group in the kanban view should reset to its original position if the user lacks the right to reorder the groups/records.

After this commit, drag-and-drop functionality for groups/records in the kanban view now works properly, even if the user does not have write access.

Task ID: 3865617

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

Forward-Port-Of: odoo/odoo#164879

Some live chat sessions are available as demo data. Some of these sessions had incorrectly crafted messages, leading to small visual glitches. For exemple, some messages were missing their `subtype_xmlid`, resulting in emojis being displayed with an incorrect margin. Others assigned the `message_type` field twice. This PR fixes this issue. task-3850900 Before:  After: ![image](https://g

Some live chat sessions are available as demo data. Some of these sessions had incorrectly crafted messages, leading to small visual glitches.

For exemple, some messages were missing their `subtype_xmlid`, resulting in emojis being displayed with an incorrect margin.

Others assigned the `message_type` field twice.

This PR fixes this issue.

task-3850900

Before:
![image](https://github.com/odoo/odoo/assets/48757558/0989a0d7-f535-4b84-90e9-9986462134a1)

After:
![image](https://github.com/odoo/odoo/assets/48757558/babbdad0-6123-4a04-beaf-e52e3304931f)

Forward-Port-Of: odoo/odoo#167063

steps to reproduce: - create a PO and buy 10 units of acoustic bloc screens from Azure interior - validate PO and picking (you now have qty_received=10 on the PO line) - create a return of 25 units and validite the picking (qty_received=-15) - change the PO line quantity to a negative amount (ex: -3) => ``` File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 392, in write lines.with_context(previous_product_qty=previous_product_uom_qty)._create_or_update_pick

steps to reproduce:
- create a PO and buy 10 units of acoustic bloc screens from Azure interior
- validate PO and picking (you now have qty_received=10 on the PO line)
- create a return of 25 units and validite the picking (qty_received=-15)
- change the PO line quantity to a negative amount (ex: -3)

=>

```
  File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 392, in write
    lines.with_context(previous_product_qty=previous_product_uom_qty)._create_or_update_picking()
  File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 445, in _create_or_update_picking
    line.invoice_lines[0].move_id.activity_schedule(
  File "/data/build/odoo/odoo/models.py", line 5952, in __getitem__
    return self.browse((self._ids[key],))
IndexError: tuple index out of range

```

opw-3941103


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

Forward-Port-Of: odoo/odoo#166245

Before this commit, deleting a list and updating its domain concurrently would lead to a crash. This was due to the fact that the transformation of `UPDATE_ODOO_LIST_DOMAIN` was missing. This commit adds the missing transformation. This commit also fix a test that checked the number of pivots instead of the number of lists. Task: 3908657 Forward-Port-Of: odoo/enterprise#63332 Forward-Port-Of: odoo/enterprise#63246

Before this commit, deleting a list and updating its domain concurrently would lead to a crash. This was due to the fact that the transformation of `UPDATE_ODOO_LIST_DOMAIN` was missing.

This commit adds the missing transformation.
This commit also fix a test that checked the number of pivots instead of the number of lists.

Task: 3908657

Forward-Port-Of: odoo/enterprise#63332
Forward-Port-Of: odoo/enterprise#63246

When `test_discuss_full` and at least `web_enterprise` are installed, `test_discuss_full_enterprise` must be installed for the tests in `test_discuss_full` to pass. runbot-65732 Forward-Port-Of: odoo/enterprise#63366

When `test_discuss_full` and at least `web_enterprise` are installed, `test_discuss_full_enterprise` must be installed for the tests in `test_discuss_full` to pass.

runbot-65732

Forward-Port-Of: odoo/enterprise#63366

The aim of this commit is checking that the function `collect_global_info_data` properly checks if one of the user's companies is the one on the journal and not necessarily the one from the current company (`self.env.company`). In the mean time, we're now returning an empty string instead of a False for the balance_amount's value in the returned dict because we have a props validation on this field. no task id Forward-Port-Of: odoo/enterprise#63365

The aim of this commit is checking that the function `collect_global_info_data` properly checks if one of the user's companies is the one on the journal and not necessarily the one from the current company (`self.env.company`). In the mean time, we're now returning an empty string instead of a False for the balance_amount's value in the returned dict because we have a props validation on this field.

no task id

Forward-Port-Of: odoo/enterprise#63365

Create an Invoice for an EC customer hading a section line and a tax on the product line Confirm the invoice Add Withholding move Go to Accounting>Reporting>Tax report Generate ATS Warning will be shown "Invoice lines should have exactly one VAT tax." ATS file will download anyway opw-3896076 Forward-Port-Of: odoo/enterprise#63363

Create an Invoice for an EC customer hading a section line and a
 tax on the product line
Confirm the invoice
Add Withholding move
Go to Accounting>Reporting>Tax report
Generate ATS

Warning will be shown
"Invoice lines should have exactly one VAT tax."
ATS file will download anyway

opw-3896076

Forward-Port-Of: odoo/enterprise#63363

There was a typo in the error message "You have to attach at **lease** one document.", where _lease_ should be _least_. This commit fixes that. We also export the latest version of the .pot file. Forward-Port-Of: odoo/enterprise#63123 Forward-Port-Of: odoo/enterprise#63051

There was a typo in the error message "You have to attach at **lease** one document.", where _lease_ should be _least_. This commit fixes that.

We also export the latest version of the .pot file.

Forward-Port-Of: odoo/enterprise#63123
Forward-Port-Of: odoo/enterprise#63051

When user clicks on contracts smart button in application and if application has two contracts (one archived and one active), a traceback will appear. Steps to reproduce the error: - Install "hr_contract_salary" module - Go to Recruitment > Applications > All Applications > Create new application > Generate Offer > Select Contract Template > Send By Email > Send - Click on Offers > Salary Configurator > Fill all required fields > Review Contract & Sign > Validate & Send Completed Do

When user clicks on contracts smart button in application and if application has
two contracts (one archived and one active), a traceback will appear.

Steps to reproduce the error:
- Install "hr_contract_salary" module
- Go to Recruitment > Applications > All Applications > Create new application >
  Generate Offer > Select Contract Template > Send By Email > Send
- Click on Offers > Salary Configurator > Fill all required fields >
  Review Contract & Sign > Validate & Send Completed Document
- Open that application > Contracts > Create new contract > Save
- Archived one contract > Click on Contract smart button

Traceback:
```
ValueError: Expected singleton: hr.contract(27, 29)
  File "odoo/http.py", line 2253, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1829, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1849, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1827, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1834, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2059, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 42, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/hr_contract_salary/models/hr_applicant.py", line 59, in action_show_proposed_contracts
    "res_id": self.env['hr.contract'].search([["applicant_id", "=", self.id], '|', ["active", "=", False], ["active", "=", True]]).id,
  File "odoo/fields.py", line 5182, in __get__
    raise ValueError("Expected singleton: %s" % record)
```

https://github.com/odoo/enterprise/blob/504b3c66a9a8d142b89f9c873675ec65fdb43dd0/hr_contract_salary/models/hr_applicant.py#L59
Here when application has two contracts (one is archived and one is active),
So when it tries to access the id of 2 records.
It will lead to the above traceback.

sentry-5350130147

Forward-Port-Of: odoo/enterprise#62627

Steps to reproduce: - Install sign - Add two document to sign for the Marc Demo - Sign in as Marc Demo - Go to the sign app and sign both documents Issues: There's no button to close the dialog box, you are forced to close the window. opw-3847269 Forward-Port-Of: odoo/enterprise#61380

Steps to reproduce:
- Install sign
- Add two document to sign for the Marc Demo
- Sign in as Marc Demo
- Go to the sign app and sign both documents

Issues:
There's no button to close the dialog box, you are forced to close the window.

opw-3847269

Forward-Port-Of: odoo/enterprise#61380

See the related community PR for the fix and more info. community PR: https://github.com/odoo/odoo/pull/167014 Forward-Port-Of: odoo/enterprise#63339

See the related community PR for the fix and more info.

community PR: https://github.com/odoo/odoo/pull/167014

Forward-Port-Of: odoo/enterprise#63339

Currently, several l10n_pe_edi tests are failing every night. This is due to: - Error 98 meaning that not enough time is given to the remote sever to process cancellation requests -> wait and check several times before asserting - Duplicated name: Sometimes, some invoices have duplicated names. We make sure it is not possible by 'incrementing' the name for each invoice we create. ----- 1. `test_send_delivery_guide` was failing because the picking vehicule was not set up properly in

Currently, several l10n_pe_edi tests are failing every night. This is
due to:
- Error 98 meaning that not enough time is given to the remote sever to
process cancellation requests -> wait and check several times before
asserting
- Duplicated name: Sometimes, some invoices have duplicated names. We
make sure it is not possible by 'incrementing' the name for each invoice
we create.

-----

1. `test_send_delivery_guide` was failing because the picking vehicule
was not set up properly in the test. After this was fix, another issue
appeared: the company needed proper credential to connect to the SUNAT.
Since those were not available, the function connecting to SUNAT has
been patched to simulate a basic answer from SUNAT.

2. `test_generate_delivery_guide`'s expected document has been updated
to include the vehicule set up in the previous step.

3. Since there is no more call to an external API. The `external` and
`l10n_external` tags are not necessary anymore. This allows to group
both tests under the same class.

task-3718645

Forward-Port-Of: odoo/enterprise#63291
Forward-Port-Of: odoo/enterprise#62452

Before this commit, the journal report did not show the date for credit notes. opw-3939676 Forward-Port-Of: odoo/enterprise#63187

Before this commit, the journal report did not show the
date for credit notes.

opw-3939676

Forward-Port-Of: odoo/enterprise#63187

Issue: ====== Creating a MO with barcode uses the wrong quantity for the components. Steps to reproduce the issue: ============================= - Install mrp , barcode - Activate unit of measure - Create a product and assigna barcode number to it - Create a BoM for that product with a component `comp` - The `comp` product have `g` as unit of measure - Assign the unit of measure in the BoM for the `comp` as `kg` - Go to barcode -> operations -> manufacturing - Create a new order -

Issue:
======
Creating a MO with barcode uses the wrong quantity for the components.

Steps to reproduce the issue:
=============================
- Install mrp , barcode
- Activate unit of measure
- Create a product and assigna barcode number to it
- Create a BoM for that product with a component `comp`
- The `comp` product have `g` as unit of measure
- Assign the unit of measure in the BoM for the `comp` as `kg`
- Go to barcode -> operations -> manufacturing
- Create a new order
- Enter barcode manually of the product that you set up early
- Click on +1 button
- You can see the quantity is wrong as and not counting the difference of UoM

Solution:
=========
We need to fetch the uom data of the move to compare it to the one of the product and update the quantity accordingly.

opw-3776896

Forward-Port-Of: odoo/enterprise#63103
Forward-Port-Of: odoo/enterprise#59131

Bug 1: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document name is not renamed. Similarly to what is done in document kanban and list controller where updating the document through the inspector works, we activate the parameter multiEdit which solve the problem. Bug 2: How to reproduce: 1. Schedule an activity for a document. 2. Go to activit

Bug 1: How to reproduce:
1. Schedule an activity for a document.
2. Go to activity view.
3. Select the document to preview in the inspector.
4. Rename the document.
5. Refresh the page.

The document name is not renamed.

Similarly to what is done in document kanban and list controller where updating the document through the inspector works, we activate the parameter multiEdit which solve the problem.

Bug 2: How to reproduce:
1. Schedule an activity for a document.
2. Go to activity view.
3. Select the document to preview in the inspector.
4. Erase the name of a doc and click anywhere to save.

No alert pop-up is shown up while saving with an empty name while this is the case when editing the document from the kanban or the list view.

Similarly to what is done in document kanban and list view, we add the required attribute to the field name.

Technical note: to avoid duplicate a lot of code, we add the test inside documents_kanban_tests.js (while it is testing the update of a document in the inspector of the activity view).

Task-3817795

Forward-Port-Of: odoo/enterprise#61792
Forward-Port-Of: odoo/enterprise#59263