This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645

This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb

Forward-Port-Of: odoo/odoo#196645

**Current behavior:** With a FIFO + real-time product, `ProductA`: Creating a sale order with multiple order lines for ProductA, processing the resulting delivery in 2 separate pickings via backorder (1st delivery for the 1st line, 2nd delivery for the 2nd line), then invoicing the delivered product separately result in an invoice with invoice lines which do not reflect the value of the product at delivery time. **Expected behavior:** The SVLs generated from the deliveries should info

**Current behavior:**
With a FIFO + real-time product, `ProductA`:
Creating a sale order with multiple order lines for ProductA,
processing the resulting delivery in 2 separate pickings via
backorder (1st delivery for the 1st line, 2nd delivery for the
2nd line), then invoicing the delivered product separately
result in an invoice with invoice lines which do not reflect the
value of the product at delivery time.

**Expected behavior:**
The SVLs generated from the deliveries should inform the
generated AccountMoves.

**Steps to reproduce:**
1. `FIFO-prod`: FIFO and real-time valuation & costing

2. Receive 12 units of `FIFO-prod` @ $100 per

3. Create a sale order with order lines:
* `FIFO-prod` `10 units` `price_unit=$100`
* `FIFO-prod` `2 units` `price_unit=$100`

4. Confirm the sale order, on the delivery, only receive the
first move for the 10 qty, backorder the other 2 qty

5. Receive the backorder, create an invoice- edit the invoice
lines so that 5/10 of line 1 and 2/2 of line 2 are invoiced,
then post/confirm

6. Edit the `standard_price` of `FIFO-prod` (e.g., $100 -> $50)

7. Create another invoice for the remaining quantity and post

8. Observe that the COGs lines on the invoice have been
calculated with a different price unit than the other invoice &
unit_price for the out SVLs

**Cause of the issue:**
When getting the price unit of a given anglo saxon invoice line,
there is no check that all the collected COGS lines are linked
to the sale order line which corresponds to the product and
product_qty that we are attempting to value.

This creates an imbalance in the qty calculation later here:
https://github.com/odoo/odoo/blob/f2728b2fe13a355ecb301a3714639b8a07f418b4/addons/stock_account/models/stock_valuation_layer.py#L202-L211
when the valuation is actually performed.

**Fix:**
Only consider posted COGS lines for the sale order line with the
product qty that is getting valued when calculating
`qty_invoiced`.

opw-4321363

Forward-Port-Of: odoo/odoo#195046

@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910

@qrtl QT5121

Forward-Port-Of: odoo/odoo#193910

A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, s

A sales team should be assigned only to sales type moves (invoices,
credit notes, ...). Currently, it is possible that some Bills get a
sales team assigned. This is not ok as it will distort the reports
if users analyze by sales team.

It occurs when `_compute_team_id` is called on a recordset containing
sales moves and other moves.
Even if sales moves are correctly filtered a `self.concat` is used to
set the `team_id` and it will return the concatenation of `self` with
the arguments, so also the non sales moves will have the team assigned

opw-4422292

Forward-Port-Of: odoo/odoo#195852
Forward-Port-Of: odoo/odoo#195645

Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008

Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules,
ensuring the padding is applied only to the outer large box and not to the inner elements.

task-4370763

Forward-Port-Of: odoo/odoo#196451
Forward-Port-Of: odoo/odoo#193008

The base.group_user did not have the access right to read overtime_id, which is necessary for filtering allocations that do not have a null overtime_id. The access right was granted to base.group_user only when the allocation state is either draft or confirm. task-4452360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196502 Forward-Port-Of: odoo/odoo#193797

The base.group_user did not have the access right to read overtime_id, which is necessary for filtering allocations that do not have a null overtime_id. The access right was granted to base.group_user only when the allocation state is either draft or confirm.

task-4452360

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

Forward-Port-Of: odoo/odoo#196502
Forward-Port-Of: odoo/odoo#193797

When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are r

When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings.

To reproduce:
 - `-i sale_stock,sale_management`
 - Create a storable product (I) with 30 qty on hand
 - Create and confirm an internal transfer to put the product I in a pack (P)
 - Create and confirm two SO :
   - Sell 10 I
   - Sell 20 I
 - Check the 2 SO delivery pickings (D):
   - Each are reserved from pack P
   - They don't have any 'Destination Package' [Expected]
 - From the picking list view, by selecting the 2 pickings D :
   - 'Unreserve' them both
   - 'Check Availability' them both
 - Check the pickings D:
   - Each are reserved from pack P
   - Each have 'Destination Package' P [Faulty]

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

Forward-Port-Of: odoo/odoo#193745

The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#195482

The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost.

Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider.

This commit disables the cron until a provider is enabled.

task-4467217

Forward-Port-Of: odoo/odoo#195482

Related to https://github.com/odoo/enterprise/pull/78533 Forward-Port-Of: odoo/odoo#196475 Forward-Port-Of: odoo/odoo#196447

Related to https://github.com/odoo/enterprise/pull/78533

Forward-Port-Of: odoo/odoo#196475
Forward-Port-Of: odoo/odoo#196447

Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196035 Forward-Port-Of: odoo/odoo#187405

Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated.

Task-3759325

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

Forward-Port-Of: odoo/odoo#196035
Forward-Port-Of: odoo/odoo#187405

Versions -------- - 17.0+ Steps ----- 1. Enable Adyen as payment provider in test mode; 2. do an eCommerce checkout; 3. select Adyen as payment option; 4. use the following card details[^1]: - card number: 4111111111111111 - expiry: 03/30 - cvc: 737 - name on card: CARD_EXPIRED 5. click Pay Now; 6. check order chatter on the backend. Issue ----- > Error: Adyen: Received data with invalid payment state: Refused Refusal shouldn't be an invalid payment state.

Versions
--------
- 17.0+

Steps
-----
1. Enable Adyen as payment provider in test mode;
2. do an eCommerce checkout;
3. select Adyen as payment option;
4. use the following card details[^1]:
    - card number: 4111111111111111
    - expiry: 03/30
    - cvc: 737
    - name on card: CARD_EXPIRED
5. click Pay Now;
6. check order chatter on the backend.

Issue
-----
> Error: Adyen: Received data with invalid payment state: Refused

Refusal shouldn't be an invalid payment state.

Cause
-----
Commit 04f75728fd3e accidentally removed an `elif` branch that was added by commit 4d340a330462e specifically to handle refused payments.

Solution
--------
Re-add the `elif` branch.

opw-4481602

[^1]: https://docs.adyen.com/development-resources/testing/result-codes#values-for-testing-result-reasons

Forward-Port-Of: odoo/odoo#196394

**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have s

**Issue:**

Users are able to delete timesheets associated with public holidays, unlike regular time off requests

**Steps to Reproduce:**

   - Ensure "Time Off" is enabled in the Timesheet settings.
  - Time Off > Configurations > Public Holidays.
  - Create a new public holiday.
  - Timesheet > My Timesheet (list view).
  - Attempt to delete the timesheet entry corresponding to the public holiday.

The entry is deleted without any warning.

opw-4464411

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

Forward-Port-Of: odoo/odoo#196506
Forward-Port-Of: odoo/odoo#195379

Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456

Fixes an issue with the renaming of the attachment after detaching to not change the extension.

task-4500319

Forward-Port-Of: odoo/odoo#196456

Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo

Steps to reproduce:

- Enter edit mode.
- Drag and drop a carousel into the page.
- Use the arrow keys to slide the carousel.
- Bug: a traceback occurs.

Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard.

[1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd

opw-4373535

Forward-Port-Of: odoo/odoo#196486
Forward-Port-Of: odoo/odoo#196433

Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible

Steps to reproduce the bug:
- Create two delivery transfers.
- Add them to a single batch transfer.
- Assign a responsible person to the batch transfer.
- The assigned responsible person will automatically be updated in all related transfers.
- Now, remove the responsible person from the batch transfer.

Problem:
When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible person is removed from the batch transfer, this change is not applied to the individual transfers linked to it.

opw-4519994

Forward-Port-Of: odoo/odoo#196487
Forward-Port-Of: odoo/odoo#196333

**Steps to reproduce:** 1. Create a new Workspace 2. Upload any amount of documents 3. Delete the workspace 4. Go to the Thrash workspace and try to move the documents that used to be in the deleted workspace **Issue:** When deleting a workspace, this one will get archived, however the documents inside of it will be moved to the Thrash and still be linked to the archived workspace, so we will no longer have access to that folder unless we restore it. Then the problem arises when w

**Steps to reproduce:**

1. Create a new Workspace
2. Upload any amount of documents
3. Delete the workspace
4. Go to the Thrash workspace and try to move the
documents that used to be in the deleted workspace

**Issue:** 
When deleting a workspace, this one will get archived, however the documents inside of it will be moved to the Thrash and still be linked to the archived workspace, so we will no longer have access to that folder unless we restore it.

Then the problem arises when we try to do this `foldersById[record.data.folder_id[0]]` since foldersById doesn't seem to include archived
folders, it will be undefined so we won't be able to read the `.has_write_access` raising a traceback

**Solution:** 
In this case the proposed solution is to follow the behavior in 18.0 where we can not move
the documents that are attached to an archived folder unless this one is restored. We get rid of
the traceback by checking if we have a folder before directly tryng to read the `has_write_access`

Additionally we added an override for `_createCategoryTree` for getting rid of the folders archived, this affects
the case where we directly archived a folder and try to move the documents that were inside of it from the thrash.
(folder will sill be present in the model when retrieving it with foldersById)

Backport of https://github.com/odoo/enterprise/commit/fac02ad43d523e55546ab21f3cc9a44db18d137b

opw-4357753

Forward-Port-Of: odoo/enterprise#75322

Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab

Description of the issue/feature this PR addresses:

This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.

Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".

Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.

Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company. 
- Add a line without a product and add a label, a unit price, quantity and tax. 
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
      <Item>
        <NroLinDet>4</NroLinDet>
        <IndFact>2</IndFact>
        <NomItem>-</NomItem>
        <DscItem>PRODUCT X</DscItem>
        <Cantidad>1.000</Cantidad>
        <UniMed>N/A</UniMed>
        <PrecioUnitario>20.000000</PrecioUnitario>
        <MontoItem>20.00</MontoItem>
      </Item>
```

Forward-Port-Of: odoo/enterprise#78551

During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the

During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected.

In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the same issue - didn't complained with it... But the "new" mode (which is actually closer to the actual GUI behavior of Chrome) got stuck at those steps.

This commit fixes this issue by using the `private_street` field (which contains the actual street name) instead of the `private_street2` field (which is often empty).

Once done, a second issue was detected as the step filling the computation of "58/4" didn't match (even wrongly) any empty field anymore.

This commit simply removes those unused steps.

Forward-Port-Of: odoo/enterprise#78547
Forward-Port-Of: odoo/enterprise#78397

Mod349 tax report in Spanish localization report the total number of intra-community operations. This counter however, does not take into account paid invoices Steps to reproduce: - With an ES company setup - Create an invoice to an EU partner - Register payment for the invoice - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operations is 0 opw-4403287 Forward-Port-Of: odoo/enterprise#77527

Mod349 tax report in Spanish localization report the total number of
intra-community operations. This counter however, does not take into
account paid invoices

Steps to reproduce:
- With an ES company setup
- Create an invoice to an EU partner
- Register payment for the invoice
- Go to Accounting / Reporting / Statement Reports / Tax Report
- Select Tax Report (Mod 349) (ES)

Issue: Total number of intra-community operations is 0

opw-4403287

Forward-Port-Of: odoo/enterprise#77527
Forward-Port-Of: odoo/enterprise#77238

Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115

Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date

- change the `date` argument while getting the `public_transport_max_amount` parameter because
if it is None is gets the real date not the freeze one

Task: 4509216

Forward-Port-Of: odoo/enterprise#78115

Related to https://github.com/odoo/odoo/pull/196447 Forward-Port-Of: odoo/enterprise#78542 Forward-Port-Of: odoo/enterprise#78533

Related to https://github.com/odoo/odoo/pull/196447

Forward-Port-Of: odoo/enterprise#78542
Forward-Port-Of: odoo/enterprise#78533

As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR

As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.

However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them

This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':

```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers 
Traceback (most recent call last):
  File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
    unlink_file(*filenames)
  File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
    path.unlink()
  File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
    os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```

This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.

task-4527243

Forward-Port-Of: odoo/enterprise#78544

Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new

Steps:
- enable rental transfers
- activate MTO route
- create a product with MTO route and 0 stock
- create a rental order for that product, validate

Issue:
The rental order will create 2 pickings that are waiting for each other.
This is because the MTO move is using the same rental route with the stock
destination, so it ends on the return rental picking.

Fix:
Force the procurement to use the `route_id` of the `rule_id` of the origin move.
This way it will correctly create a new picking from Vendor to Stock for the product.
If the product has a Buy or Manufacture route, it will use those instead.

Also found another issue when enabling, then disabling, then re-enabling rental pickings:
the stock rule stays archived. It is now fixed and a test has been added.

Forward-Port-Of: odoo/enterprise#76477

This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78303 Forward-Port-Of: odoo/enterprise#73906

This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis.

Task-3759325

Forward-Port-Of: odoo/enterprise#78303
Forward-Port-Of: odoo/enterprise#73906

The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h

The following `response` was being returned when checking the CFDI status:

```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```

Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.

Forward-Port-Of: odoo/enterprise#78552