This pr contains a second set of fix for ubuntu noble, mainly regarding python 3.12 and lxml 5.2 For easier forwardport, the pr is split in multiple parts ## This PR ### [FIX] base, tools: adapt optcode for python ### [FIX] mail: addapt lxml.html.defs Will be useful when using new package lxml_hmtl_clean. Done in another ### [FIX] test_lint: adapt for pylint 3.0.0 ## Other pr ### [FIX] *: SyntaxWarning: invalid escape sequence Automatic fix in all versions -

This pr contains a second set of fix for ubuntu noble, mainly regarding python 3.12 and lxml 5.2

For easier forwardport, the pr is split in multiple parts


## This PR

###  [FIX] base, tools: adapt optcode for python 

### [FIX] mail: addapt lxml.html.defs 

Will be useful when using new package lxml_hmtl_clean. Done in another

### [FIX] test_lint: adapt for pylint 3.0.0


## Other pr

### [FIX] *: SyntaxWarning: invalid escape sequence

Automatic fix in all versions 

- [x] 15.0 
https://github.com/odoo/odoo/pull/163493
https://github.com/odoo/enterprise/pull/61571
- [x] 16.0 
https://github.com/odoo/odoo/pull/163753
https://github.com/odoo/enterprise/pull/61658
- [x] 16.3 
https://github.com/odoo/odoo/pull/163754
https://github.com/odoo/enterprise/pull/61659
- [x] 16.4 
https://github.com/odoo/odoo/pull/163755
https://github.com/odoo/enterprise/pull/61660
- [x] 17.0 
https://github.com/odoo/odoo/pull/163756
https://github.com/odoo/enterprise/pull/61661
- [x] 17.1 
https://github.com/odoo/odoo/pull/163757
https://github.com/odoo/enterprise/pull/61662
- [x] 17.2 
https://github.com/odoo/odoo/pull/163758
https://github.com/odoo/enterprise/pull/61663
- [x] master 
https://github.com/odoo/odoo/pull/163759
https://github.com/odoo/enterprise/pull/61664

### [FIX] netsvc: silent utcnow errors (temp)
- [x]  done in #163794 (easier forwardport, may conflict)

### [FIX] tests: avoid to fork in multithread 

- [x]  #163562

### [FIX] ast 

- [x]  15.0: mute warning #163559 (python 3.7 - Python 3.13)
- [x]  16.0+: fix it #163487 (python 3.8 - python 3.14 + )

### [FIX] packaging of lxml_html_clean
- [ ]  Will be done in #163788

### [FIX] root xpath deprecation warning
- [x]  done in https://github.com/odoo/enterprise/pull/61570

Forward-Port-Of: odoo/odoo#165315
Forward-Port-Of: odoo/odoo#162438

### Steps to reproduce the issue: 1. In _Maintenance > Maintenance > Maintenance Requests_, set multiple maintenance requests with scheduled dates 2. In _Maintenance > Maintenance > Maintenance Calendar_, get to a week or month with multiple requests 3. Drag and drop one of the requests in the calendar - You can also double click or resize the request 4. In most cases, the request that is changed or accessed is not the right one ### Explanation: `rawRecord` is the record as retr

### Steps to reproduce the issue:

1. In _Maintenance > Maintenance > Maintenance Requests_, set multiple maintenance requests with scheduled dates
2. In _Maintenance > Maintenance > Maintenance Calendar_, get to a week or month with multiple requests
3. Drag and drop one of the requests in the calendar
    - You can also double click or resize the request
4. In most cases, the request that is changed or accessed is not the right one

### Explanation:

`rawRecord` is the record as retrieved by `fetchRecords`, it is then processed in `loadRecords`. In `CalendarWithRecurrence`, with the option of having recurring events, `record.id` is nearly always different from `rawRecord.id`.
https://github.com/odoo/odoo/blob/74a0703671f29fefad02843c0d679f903b812575/addons/maintenance/static/src/views/calendar_with_recurrence/calendar_with_recurrence_model.js#L11-L17

### Suggested fix:

Overriding the methods that lead to the wrong model to replace `record.id` with `record.rawRecord.id` solves the issue without breaking other methods.
For requests with recurrence, any change made using an occurrence in the calendar view would target the original request instead. Accessing it is not an issue, so we will only disable the edition of the occurrences.

opw-3848278
opw-3849852

Forward-Port-Of: odoo/odoo#162041

Payment term on reversed invoices should not be displayed in the preview page. Steps: - Create and confirm an invoice - Open the preview - The invoice due date is displayed on the top left of the page just above the "Download" and "Print" buttons - Go back to the invoice and make a full refund - The payment state of the invoice is "reversed" - Go back to the invoice preview -> The invoice due date is still displayed, it should not be opw-3894596 Forward-Port-Of: odoo/odoo#164

Payment term on reversed invoices should not be displayed
in the preview page.

Steps:

- Create and confirm an invoice
- Open the preview
- The invoice due date is displayed on the top left of the page
  just above the "Download" and "Print" buttons
- Go back to the invoice and make a full refund
- The payment state of the invoice is "reversed"
- Go back to the invoice preview
-> The invoice due date is still displayed, it should not be

opw-3894596

Forward-Port-Of: odoo/odoo#164897

This PR fixes a layout issue inside the eCommerce categories form view on mobile devices. Prior to this PR, a `.oe_left` class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized `form_sheet`. To fix the issue, we have to provide a CSS workaround to modify the view without modifying the XML directly. To do so, we set a `float:none` that will cancel the utility class, and we apply a `.col-md-6` and a `.pe-3` class to ensure that the labels

This PR fixes a layout issue inside the eCommerce categories form
view on mobile devices.

Prior to this PR, a `.oe_left` class was applied to the content of
the sheet, moving it "out of the flow", resulting in a wrong sized
`form_sheet`.

To fix the issue, we have to provide a CSS workaround to modify the view
without modifying the XML directly. To do so, we set a `float:none` that
will cancel the utility class, and we apply a `.col-md-6` and a `.pe-3`
class to ensure that the labels are not placed right next to the image
in mobile and the layout doesn't take the full width on larger devices.

task-3847917

Forward-Port-Of: odoo/odoo#165486
Forward-Port-Of: odoo/odoo#162034

Steps to reproduce: - Enable multistep delivery/reciept - Create a kit and subkit with product quantity set on the bom (exemple values in the tests) - Create and confirm an SO (pickings created with correct values) - Update the orders quantity Bug: wrong Delivered/Recieved ammount on the SO line FIX: all boms should be taken into account not just the one on the move line to handle subkits in "_compute_kit_quantities" done quantity of moves should be considered for done moves inste

Steps to reproduce:
- Enable multistep delivery/reciept
- Create a kit and subkit with product quantity set on the bom (exemple values in the tests)
- Create and confirm an SO (pickings created with correct values)
- Update the orders quantity

Bug:
wrong Delivered/Recieved ammount on the SO line

FIX:
all boms should be taken into account not just the one on the move line to handle subkits

in "_compute_kit_quantities" done quantity of moves should be considered for done moves instead of their demand

opw-3827388

Forward-Port-Of: odoo/odoo#164544

This commit removes the dead and undeterministic test added by mistake after an unsucessful merge. This test assumes that the organizer of the event might always be on the position 0 of the attendees list but it is not always the case. Issue from: odoo/odoo#164408 Forward-Port-Of: odoo/odoo#165346

This commit removes the dead and undeterministic test added by mistake after an unsucessful merge. This test assumes that the organizer of the event might always be on the position 0 of the attendees list but it is not always the case.

Issue from: odoo/odoo#164408

Forward-Port-Of: odoo/odoo#165346

This is an extension of odoo/odoo#160055 as this issue is also present for allocations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165249

This is an extension of odoo/odoo#160055 as this issue is also present for allocations

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

Forward-Port-Of: odoo/odoo#165249

Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants. Step to produce: - Install a 'Sales' module. - Navigate to the Sales / Products / Products, And create a product. - Add a 'Product Name' and save a record, and then add dynamic Attributes & Variants. - Repeat the process described in the above step to create another product with the same configuration as the first one. -Go to list view of 'Product'. select both products that we

Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants.

Step to produce:

- Install a 'Sales' module.
- Navigate to the Sales / Products / Products, And create a product.
- Add a 'Product Name' and save a record, and then add dynamic Attributes & Variants.
- Repeat the process described in the above step to create another product with the same configuration as the first one.
-Go to list view of 'Product'. select both products that we made recently and click on the Action button to archive both products.
- Click on 'Filters' to see the archive product, And select those products to Unarchive.

ValueError: Expected singleton: product.template(39, 37, 40, 42, 38, 46, 34)

The issue occurs when unarchive multiple products that contain dynamic attributes & variants. As a result, the system receives multiple product templates at [1].

link[1]: https://github.com/odoo/odoo/blob/e5635c38810a745f00b106d7a075ae1553de50c7/addons/product/models/product_template.py#L745

To resolve the issue, replace a 'self' with 'tmpl_id' to get a single product template record instead of multiple.

sentry-5222160918

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

Forward-Port-Of: odoo/odoo#165394

In this PR, if the user has created a leave request for today and it remains unvalidated, they can delete it However, past leave cannot be deleted Task-3775186 Forward-Port-Of: odoo/odoo#165351

In this PR, if the user has created a leave request for today and it remains unvalidated, they can delete it
However, past leave cannot be deleted

Task-3775186

Forward-Port-Of: odoo/odoo#165351

Steps to reproduce: - Install stock_account and UAE account (l10N_ae) "UAE has nothing to do with the bug it's just a pain to setup a new company accounting otherwise" - Create and configure a product FIFO automated with on hand qty for both companies - In stock valuation select UAE and try to reavluate that product Bug: wrong company (the default one) is set on the context Fix: set the correct allowed_company_ids from the cids in the request cookies opw-3765174 Forward-Port-Of: o

Steps to reproduce:
- Install stock_account and UAE account (l10N_ae) "UAE has nothing to do with the bug it's just a pain to setup a new company accounting otherwise"
- Create and configure a product FIFO automated with on hand qty for both companies
- In stock valuation select UAE and try to reavluate that product

Bug:
wrong company (the default one) is set on the context

Fix:
set the correct allowed_company_ids from the cids in the request cookies

opw-3765174

Forward-Port-Of: odoo/odoo#158074

Problem: when adding attendees to a course, the sent email is not translated into the recipient's language. Fix: Upon sending, translate the email on a per recipient basis, but **only when** the final message to sent is exactly the same as the template. (i.e. the body was not edited from the dialog box) This is a compromise to permit emails being translated while not breaking the following 2 current features: * there can be many recipients (with different languages) * the body is pre-f

Problem:
when adding attendees to a course, the sent email is not translated into the recipient's language.

Fix:
Upon sending, translate the email on a per recipient basis, but **only when** the final message to sent is exactly the same as the template. (i.e. the body was not edited from the dialog box)

This is a compromise to permit emails being translated while not breaking the following 2 current features:
* there can be many recipients (with different languages)
* the body is pre-filled with a template but can be edited further by the user directly from the dialog box.

opw-3862369

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

Forward-Port-Of: odoo/odoo#162237

**[FIX] website_slides: rectify the trigger on the course title input field** Before this commit: - While running the `slides_tour`, it freezes after we click on `Course` to create a new course. The prompt to input the title while creating the new course is not visible. - The prompt to add 'Section Name' is missing. Reason: The 'trigger' update was not addressed in the following PR: https://github.com/odoo/odoo/pull/117799 After this commit: - The prompt to input the course title

**[FIX] website_slides: rectify the trigger on the course title input field**

Before this commit:
- While running the `slides_tour`, it freezes after we click on `Course` to
create a new course. The prompt to input the title while creating the new course
is not visible.
- The prompt to add 'Section Name' is missing.

Reason:
The 'trigger' update was not addressed in the following PR:
https://github.com/odoo/odoo/pull/117799

After this commit:
- The prompt to input the course title is visible.
- The prompt to add the 'Section Name' is added.

task-3539126

Forward-Port-Of: odoo/odoo#164190
Forward-Port-Of: odoo/odoo#138651

Steps to reproduce: - create a new spreadsheet - right click any cell => boom `Cannot read properties of undefined (reading 'id')` Bug introduced by odoo/enterprise@31401c7 opw-3900571 X-original-commit: odoo/enterprise@78218c9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165270 Forward-Port-Of: odoo/odoo#165183

Steps to reproduce:
- create a new spreadsheet
- right click any cell

=> boom `Cannot read properties of undefined (reading 'id')`

Bug introduced by odoo/enterprise@31401c7

opw-3900571

X-original-commit: odoo/enterprise@78218c9


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

Forward-Port-Of: odoo/odoo#165270
Forward-Port-Of: odoo/odoo#165183

Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line empty - Add some text in the third line - Select some prefix of the third line with the second line too - delete - All the content before the empty line is removed Origin of the issue: ==================== We are in this case: `<p>abc</p>` `<p>[<br></p>` `<p>d]ef</p>` - The

Issue:
======
The whole content is removed when deleting empty line

Steps to reproduce the issue:
=============================
- Go to to-do
- Add some text in the first line
- Keep the second line empty
- Add some text in the third line
- Select some prefix of the third line with the second line too
- delete
- All the content before the empty line is removed

Origin of the issue:
====================
We are in this case:
	`<p>abc</p>`
	`<p>[<br></p>`
	`<p>d]ef</p>`

- The `startContainer` in this case is the `p` element and not the `br` so
we will not insert the `zws` node inside the `p`.
- We assign `next` as the text node containing `ef`
- Extract content will remove all the content inside the second `p`
  element and will be like this
	`<p>abc</p>`
	`<p></p>`
	`<p>ef</p>`
- We set selection at the end of the `start` node `<p>[]</p>`so it's like we set
  the selection in  `<p>[]ef</p>` so now `getRange` will return
  `startContainer=endContainer=textNode(ef)` so `joinWith` is
  equal to next which is the text node containing `ef`
- In the join `while` loop , we have `doJoin=true`, `next` always
  truthy, `next.previousSibling` will never be equal to `joinWith`
  since `next=joinWith` so it will keep deleting until we don't
  have anymore previousSiblings which is basically remove everything
  before.

Note: This doesn't happen in the case the second line has some text
because we insert a `zws` before the text node.

Solution:
=========
Since we apply `fillEmpty` on `start` after extracting the content, we
need to get the range after we insert the `br` again to make sure we
get the correct `startContainer` and `endContainter`.

opw-3878575

Forward-Port-Of: odoo/odoo#165104

Issue: ====== History steps aren't cleared when we click discard Steps to reproduce the issue: ============================= - Add anything to a todo record - Click discard - Click ctrl+Z - The block reappears but in reverse order Origin of the issue: ==================== This commit introduced the behavior: https://github.com/odoo/odoo/commit/0e22763a85ee2f4caf663185eb70d3d181b954b0 We only set the value of the edtior and we don't reset it that's why the history stays. Solut

Issue:
======
History steps aren't cleared when we click discard

Steps to reproduce the issue:
=============================
- Add anything to a todo record
- Click discard
- Click ctrl+Z
- The block reappears but in reverse order

Origin of the issue:
====================
This commit introduced the behavior: https://github.com/odoo/odoo/commit/0e22763a85ee2f4caf663185eb70d3d181b954b0
We only set the value of the edtior and we don't reset it that's why the
history stays.

Solution:
=========
When we discard the field, it will have `dirty=false` , we can use this
information in the field to check if we are in a discard flow or not.

task-3768456

Forward-Port-Of: odoo/odoo#155511

Previously: - Users without create access could see the 'Duplicate' action. After this fix: - Users without create access cannot see the 'Duplicate' action. task-3898435 Forward-Port-Of: odoo/odoo#163776

Previously:
- Users without create access could see the 'Duplicate' action.

After this fix:
- Users without create access cannot see the 'Duplicate' action.

task-3898435

Forward-Port-Of: odoo/odoo#163776

The class doesn't have the post_install tag, and so, is skipped. runbot-25903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165240

The class doesn't have the post_install tag, and so, is skipped.

runbot-25903




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

Forward-Port-Of: odoo/odoo#165240

To reproduce: - Connect as Marc Demo (Administrator for Sales, wihout Administration) for access rights - Create a quotation, confirm it - Create a downpayment of 50%. => Access Right Error. The reason being that we define the Downpayment product if we don't have one on the company. We should add a sudo here. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165454

To reproduce:
- Connect as Marc Demo (Administrator for Sales, wihout Administration) for access rights
- Create a quotation, confirm it
- Create a downpayment of 50%.
=> Access Right Error.

The reason being that we define the Downpayment product if we don't have one on the company.
We should add a sudo here.



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

Forward-Port-Of: odoo/odoo#165454

Description: The Attendee List report uses `date_begin` and `date_end` to display the Event's Dates, however these values are always UTC rather than using the `date_tz` set on the Event. In order to show the times with the correct tz, we should use the already existing `date_begin_located` and `date_end_located` fields instead, which already formats the fields with tz. Desired Behavior after fix: Attendee List report properly displays the datetime based on the tz set on the record. opw-3

Description:
The Attendee List report uses `date_begin` and `date_end` to display the Event's Dates, however these values are always UTC rather than using the `date_tz` set on the Event. In order to show the times with the correct tz, we should use the already existing `date_begin_located` and `date_end_located` fields instead, which already formats the fields with tz.

Desired Behavior after fix:
Attendee List report properly displays the datetime based on the tz set on the record.

opw-3895264

Forward-Port-Of: odoo/odoo#164851

Steps to reproduce: - Enable event barcode in Event settings - Create a new event - Add an attendee and send him the ticket by email - Download the ticket - Scan the ticket in the registraion desk - Server Error: 'payment_status_value': dict(self._fields['payment_status']._description_selection(self.env))[self.payment_status], KeyError: False Bug: the field is a selection field we use _description_selection to get the string to display but in this case the ticket is not linked to a sal

Steps to reproduce:
- Enable event barcode in Event settings
- Create a new event
- Add an attendee and send him the ticket by email
- Download the ticket
- Scan the ticket in the registraion desk
- Server Error: 'payment_status_value': dict(self._fields['payment_status']._description_selection(self.env))[self.payment_status], KeyError: False

Bug:
the field is a selection field we use _description_selection to get the string to display but in this case the ticket is not linked to a sale so the value is False

Note:
-the value is correctly checked before being displayed \<tr t-if="registration.payment_status_value">

-in V17 same for sale_status instead

opw-3870653

Forward-Port-Of: odoo/odoo#164193

In production we are encountering an issue wherein the message number is exceeding the maximum value (255). This results in an error when converting the integer into its byte value representation. The solution to this is to reset the message number upon each send. task-id: none Forward-Port-Of: odoo/odoo#165242

In production we are encountering an issue wherein the message number is exceeding the maximum value (255). This results in an error when converting the integer into its byte value representation.

The solution to this is to reset the message number upon each send.

task-id: none

Forward-Port-Of: odoo/odoo#165242

1. VMT_1 tag should report the currency rate instead of the invoice untaxed amount 2. CDE_2 tag should be limited to a max of 30 characters Related: https://github.com/odoo/odoo/pull/148953 and https://github.com/odoo/enterprise/pull/54086 task-3925896 Forward-Port-Of: odoo/enterprise#62512

1. VMT_1 tag should report the currency rate instead of the invoice untaxed amount
2. CDE_2 tag should be limited to a max of 30 characters

Related: https://github.com/odoo/odoo/pull/148953 and https://github.com/odoo/enterprise/pull/54086
task-3925896

Forward-Port-Of: odoo/enterprise#62512

task-3908271 Forward-Port-Of: odoo/enterprise#61944

task-3908271

Forward-Port-Of: odoo/enterprise#61944

Sometimes companies might not have a vat number. In this case they are often prevented from exporting a report. They've been using a workaround by enterping '-' or '/' but that prevents from easily setting proper default values elsewhere, for example in l10n_lu_reports. mentioned in opw-3802589 Forward-Port-Of: odoo/enterprise#62410 Forward-Port-Of: odoo/enterprise#62391

Sometimes companies might not have a vat number.
In this case they are often prevented from exporting a report. They've been using a workaround by enterping '-' or '/' but that prevents from easily setting proper default values elsewhere, for example in l10n_lu_reports.

mentioned in
opw-3802589

Forward-Port-Of: odoo/enterprise#62410
Forward-Port-Of: odoo/enterprise#62391

Steps to reproduce: - Create a QC of type operation - Set it on reciepts Bug: you are able to validate reciepts without passing the QC Fix: use the same logic as in "check_quality" opw-3839794 Forward-Port-Of: odoo/enterprise#62259

Steps to reproduce:
- Create a QC of type operation
- Set it on reciepts

Bug:
you are able to validate reciepts without passing the QC

Fix:
use the same logic as in "check_quality"

 opw-3839794

Forward-Port-Of: odoo/enterprise#62259

Before this commit, the upsell lines were not translated into the customer lang. taskid: 3911032 Forward-Port-Of: odoo/enterprise#62394 Forward-Port-Of: odoo/enterprise#62086

Before this commit, the upsell lines were not translated into the
customer lang.


taskid: 3911032

Forward-Port-Of: odoo/enterprise#62394
Forward-Port-Of: odoo/enterprise#62086

Quality check wizard shows '- False' instead of Serial number in title if no lot_name opw-3839794 Forward-Port-Of: odoo/enterprise#62260

Quality check wizard shows '- False' instead of Serial number in title if no lot_name

opw-3839794

Forward-Port-Of: odoo/enterprise#62260

### Steps to reproduce: With company 1: - Go to the General Settings and activate: 1) Inter-Company Transactions: - "Synchronize Sales and Purchase Order" - "Automatic Validation" - "Copy Lots on Delivery Validation" 2) Multi-Step Routes - Go to Inventory > Configuration > Warehouse Management > Locations - Create a new Location SHELF with COMP1/STOCK as parent - Go to Inventory > Configuration > Warehouse Management > Putaway Rules - Create a new putaway r

### Steps to reproduce:

With company 1:

- Go to the General Settings and activate: 
  1) Inter-Company Transactions: 
     - "Synchronize Sales and Purchase Order" 
     - "Automatic Validation" 
     - "Copy Lots on Delivery Validation" 
  2) Multi-Step Routes
- Go to Inventory > Configuration > Warehouse Management > Locations
- Create a new Location SHELF with COMP1/STOCK as parent
- Go to Inventory > Configuration > Warehouse Management > Putaway Rules
- Create a new putaway rule applicable to all products from COMP2/STOCK to COMP2/STOCK/SHELF

With company 2:

- Create a storable product tracked by a Unique Serial Number
- Click on "On Hand" > Register 1 on hand qty with a new serial Number
- Create and confirm an SO for company 2 with your product

At this point, if you go to company 1:

A purchase order related to the SO was created and confirmed. If you open the related delivery and inspect the related stock move line the destination, it will correctly be set to COMP1/STOCK/SHELF.

With company 2:

- Open the delivery linked to your SO click on the list icon of you stock move line
- Add a stock picking referencing the serial number you created
- Validate the delivery

If you go to company 1, the move line is now attached with a serial number but the destination is set to set to COMP1/STOCK.

#### > The putaway rule is not applied anymore

### Cause of the issue:

When you confirmed the SO with company 2, it will create an PO in company 1:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/sale_order.py#L22 and a related stock move will then be created. During the "_action_confirm" of this stock move the putaway rules will be applied to the stock move lines a few lines after creation: https://github.com/odoo/odoo/blob/58fefc94ca39f7951392063921fe9b5e606178e6/addons/stock/models/stock_move.py#L1720 When you confirm the delivery, this correclty set stock move line will be deleted and a new one will be created:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/stock_picking.py#L30-L33 However, as the "apply_putaway_strategy" method is not called after the creation of this newly created stock move line, the destination of the line will entirly be set by the destination of the stock move: https://github.com/odoo/odoo/blob/42b760c8fa27cfc75fcb2fd5b232defc9002e85f/addons/stock/models/stock_move.py#L1441 so that the put away rules will not be applied anymore.

opw-3744375

Forward-Port-Of: odoo/enterprise#60161

How to reproduce: - Enable "Storage Locations"; - Create a receipt with WH/Stock/Shelf 2 as the Destination Location; - Add a product with a barcode in this receipt and mark it as todo; - Open the created receipt in the Barcode app; - Scan the product; - Scan WH/Stock/Shelf 1 barcode. -> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.) -> Expected behavior: a product cannot be moved in a destination who is not

How to reproduce:
- Enable "Storage Locations";
- Create a receipt with WH/Stock/Shelf 2 as the Destination Location;
- Add a product with a barcode in this receipt and mark it as todo;
- Open the created receipt in the Barcode app;
- Scan the product;
- Scan WH/Stock/Shelf 1 barcode.

-> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.)

-> Expected behavior: a product cannot be moved in a destination who is not (a part of) the picking's destination.

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

Forward-Port-Of: odoo/enterprise#61878
Forward-Port-Of: odoo/enterprise#61560

the nssf number restriction should not be apply given the real world scenario where the number can be in other format (eg 000000000x) task-3908312 Forward-Port-Of: odoo/enterprise#61947

the nssf number restriction should not be apply
given the real world scenario where the number
can be in other format (eg 000000000x)

task-3908312

Forward-Port-Of: odoo/enterprise#61947

In the BE loca, we were flexible on the notion of complete month. This was useful for odoo but did not make sense for the localization. A complete month of work is if you work from the first work day of the month to the last. Non-working days and public holidays are excluded. Forward-Port-Of: odoo/enterprise#62258

In the BE loca, we were flexible on the notion of complete month. 
This was useful for odoo but did not make sense for the localization. 
A complete month of work is if you work from
the first work day of the month to the last.
Non-working days and public holidays are excluded.

Forward-Port-Of: odoo/enterprise#62258

Child asset has an `asset_lifetime_days` that depends on it's parent's. So, we need to add `recursive=True` to the field. Forward-Port-Of: odoo/enterprise#62351

Child asset has an `asset_lifetime_days` that depends on it's parent's. 
So, we need to add `recursive=True` to the field.

Forward-Port-Of: odoo/enterprise#62351