This fix prevents hardware driver requests from failing when no request headers are provided. It helps keep connected hardware communication stable by ensuring the system can always add its required identification information.

Previously, if `headers` was explicitly passed to `None`, we couldn't assign it the custom User Agent. Now, we ensure to set it to an empty dictionary before assigning it.

This change updates internal Spanish reporting tests so they no longer rely on demo data, which is not allowed in this context. It helps keep automated checks compliant and reliable without changing day-to-day user functionality.

This is illegal.

https://runbot.odoo.com/odoo/error/161658

This change makes the Indian payroll test setup create its own department data instead of depending on optional sample records. It helps keep automated checks reliable in standard test configurations without changing payroll features for users.

`hr.dep_rd` is demo data, it's not available anymore during tests in the default configuration. So replace it by creating a department on the fly. And remove the resolution of `employee_al` which is also demo data *and* seems unused.

While at it, nuke a bunch of instance variables which don't seem used outside of `setUp`.

https://runbot.odoo.com/odoo/error/161648

This update fixes an internal test setup so Amazon marketplace-related tests run with the required sales administrator access. It helps keep automated validation reliable for Amazon sales integrations without changing day-to-day user behavior.

Interaction with the amazon marketplace models requires sales admin access. Furthermore, these accesses are also necessary during the `l10n_es_sale_amazon` tests (which use this setup), so adding then removing the group for the setup or locally using `sudo` doesn't seem like a great option.

https://runbot.odoo.com/odoo/error/163666

The VAT return draft-check now focuses only on customer invoices and vendor bills. This prevents unrelated miscellaneous journal entries from blocking VAT return preparation, reducing false warnings for accounting teams.

In the VAT report return, we check that there are no draft moves in the period. However, we only want customer invoices and bills, MISC entries should not be included in the check.

task-4627315

Spreadsheet pivot tables now generate DATE formulas without extra spaces before the day and month values. This prevents formatting issues and makes generated spreadsheet formulas cleaner and more reliable for users.

Removed extra spaces in front of the day and month in DATE function.

Task: 4725023

Appointment pages with no available staff or resources now show the unavailable-slot message only once. This avoids a confusing duplicate message for visitors trying to book an appointment.

Reproduce:
Check the front page of an appointment type with no resources or staff users.

This commit avoids duplicating the ‘No slot’ message on the front page of appointment types for which there is no slot available.

Task-4750234

Accessing external resources in chrome can increase randomness in execution for multiple reasons: - the external resource may temporary not be available - the external resource may be faster-slower to load - the external server could block some requests because of rate limiting - the network may be unreachable. Moreover, downloading fonts at every execution also slows down the tests A possibility to solve the issue was to block the network on runbot, in the dockers. The main problem

Accessing external resources in chrome can increase randomness in execution for multiple reasons:

- the external resource may temporary not be available
- the external resource may be faster-slower to load
- the external server could block some requests because of rate limiting
- the network may be unreachable.

Moreover, downloading fonts at every execution also slows down the tests

A possibility to solve the issue was to block the network on runbot, in the dockers. The main problem with this solution is that it wouldn't be the same behavior locally. It is also hard to adapt all versions at the same time.

This commit introduced another solution, using Fetch.enable in the chrome developers tools. This will allow to have a callback on every external request, allowing to enable/disable/give an alternate answer to the request.

All local request are allowed, all external request should be either
blocked or an alternative answer given.

This could be costly but at first glance it looks like it had no visible
negative impact on performances.

The first version was blocking all external requests, leading to a lot of failing tests, most of them already seen in nighties. It is hard to say since depending on when it happens it could create different error message, at least a few dozens of error related to this where found, maybe a few hundreds looking at the kind of patterns it can cause.  

Following this attempts a fix was to vendor all needed sources leading to ~130 cached url, with more than 100 fonts. This list was furthered reduced to have default fonts that would be returned reducing the load.

A test was made to return a 404 instead and it was actually enough, and it is the same for most requests (stripe, ayden, ...). Only a few of them needs a answer close to reality.

- The gooleapis css can be emty but not a 404 because it may make some of the css computation fail (website.backend_assets_all_wysiwyg.min.css) One of the failling test is TestCustomSnippet.test_01_run_tour

This final version returns a 404 for most resources.

A version returning 500 also works fine.

This pr could impact other cis (odoosh, other runbot) but the impact is expected to be slow wince only two tests needed to be adapted outside tests/common.py. It would be still possible to make Fetch.enable optional using an environment variable. 

Targeting 18.0 looks reasonable for a start, could be backported to 16.0 later

Note that this pr may make some random error more frequent, #207469 was needed to make this pr green. 
The assumption is that the speedup of the loading of some resources (or possible slowdown of local request) may change the timing of the execution revealing making some error more frequent.

Forward-Port-Of: odoo/odoo#207157

Before this commit, if a combo product contains a product with multi options attribute, you will have an error when proceeding the order. opw-4637372 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202663

Before this commit, if a combo product contains a product with multi options attribute, you will have an error when proceeding the order.

opw-4637372

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

Forward-Port-Of: odoo/odoo#202663

Enable canvas image smoothing with high quality settings to improve the visual output of resized images. The issue was most noticeable in the 128px version, which appeared blurry or pixelated. <img width="1279" alt="Screenshot 2025-04-02 at 11 03 17" src="https://github.com/user-attachments/assets/dd2c9f92-1ad9-409b-9c17-184059dc5adf" /> opw-4689905 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204431

Enable canvas image smoothing with high quality settings to improve the visual output of resized images.

The issue was most noticeable in the 128px version, which appeared blurry or pixelated.

<img width="1279" alt="Screenshot 2025-04-02 at 11 03 17" src="https://github.com/user-attachments/assets/dd2c9f92-1ad9-409b-9c17-184059dc5adf" />

opw-4689905

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

Forward-Port-Of: odoo/odoo#204431

In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461 This causes the transaction to get rolled back, and any successfully-sent invoices to be lost. Solution: Commit after each invoice is sent. opw-4630496 Forward-Port-Of: odoo/odoo#206901 Forward-Port-Of: odoo/odoo#205593

In Romania, when sending multiple invoices to e-Factura, if one invoice is rejected, the Send & Print wizard will raise a UserError at

https://github.com/odoo/odoo/blob/9416ca8cb63fc53a862aa8533dfa60ba33506191/addons/account/wizard/account_move_send.py#L461

This causes the transaction to get rolled back, and any successfully-sent invoices to be lost.

Solution: Commit after each invoice is sent.

opw-4630496

Forward-Port-Of: odoo/odoo#206901
Forward-Port-Of: odoo/odoo#205593

Previously, an inline search was used to fetch the production location. If no production location existed for the company,a SQL constraint error would occur during warehouse creation due to the missing field default_location_dest_id. This change uses the existing _get_production_location method to raise a clear UserError instead, making the issue easier to understand. I have seen this on several tickets now so this would prevent future tickets from ending up in our pipe as now the user can

Previously, an inline search was used to fetch the production location. If no production location existed for the company,a SQL constraint error would occur during warehouse creation due to the missing field default_location_dest_id.

This change uses the existing _get_production_location method to raise a clear UserError instead, making the issue easier to understand.

I have seen this on several tickets now so this would prevent future tickets from ending up in our pipe as now the user can just create a production location themselves.

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

Forward-Port-Of: odoo/odoo#206500

Steps: ----- 1. Make an order from a time zone such that does not have the same local date as UTC. For instance, from Mexico at 23h. The next day, the order date will say "Today" instead of yesterday's date. Reason: ------- We were not taking into consideration the current timezone when checking if the UTC date corresponds to the local today's date. Fix: ---- Convert the UTC date to a local date before proceeding with our conditional checks. opw-4699263 Forward-Port-Of: odoo/o

Steps:
-----
1. Make an order from a time zone such that does not have the same local date as UTC. For instance, from Mexico at 23h.

The next day, the order date will say "Today" instead of yesterday's date.

Reason:
-------
We were not taking into consideration the current timezone when checking if the UTC date corresponds to the local today's date.

Fix:
----
Convert the UTC date to a local date before proceeding with our conditional checks.

opw-4699263

Forward-Port-Of: odoo/odoo#207323
Forward-Port-Of: odoo/odoo#206827

Scenario: - edit the website theme and change a font to external font Buda - save and go back to edition and theme tab Result: Infinite spinning when loading the theme tab, and we see an error of AssetsLoadingError as well as an error 400 in console when loading https://fonts.googleapis.com/css?family=Buda URL. Issue: Buda font only has a 300 size, but when loading for the FontFamilyPickerUserValueWidget, we don't specify sizes so google fonts returns an error because there os no 400 size vers

Scenario:
- edit the website theme and change a font to external font Buda
- save and go back to edition and theme tab

Result:
Infinite spinning when loading the theme tab, and we see an
error of AssetsLoadingError as well as an error 400 in console when
loading https://fonts.googleapis.com/css?family=Buda URL.

Issue:
Buda font only has a 300 size, but when loading for the
FontFamilyPickerUserValueWidget, we don't specify sizes so google fonts
returns an error because there os no 400 size version of the font.

This is not an issue when adding the font because we use 300 up to 700:
d0ba6c26e64e711e21b191bdba0ede14abc6afb9

This is also not an issue for self-hosted google font because we load it
with the same parameters: 5145d84dc02d8068a5feaac769f5d83cefc65804

opw-4657897 opw-4497707 opw-4338034 opw-3236787 opw-3584322 opw-3306789

Forward-Port-Of: odoo/odoo#207229

Scenario: add a form with existing date field (for "Send an E-mail" form the field "Scheduled Send Date" for example) and make it hidden. Fill and send the form. Issue: the form is not send and it spin without end Reason: in b9b3a605e0f4c5da3a258c980107d6162da7f44f the code for fixing date format was rewritten as for loop without nested function. But the return that was used to get to next loop iteration, was not converted to a continue, so if there was a date / datetime widget unfill

Scenario: add a form with existing date field (for "Send an E-mail" form
the field "Scheduled Send Date" for example) and make it hidden. Fill
and send the form.

Issue: the form is not send and it spin without end

Reason: in b9b3a605e0f4c5da3a258c980107d6162da7f44f the code for fixing
date format was rewritten as for loop without nested function. But the
return that was used to get to next loop iteration, was not converted to
a continue, so if there was a date / datetime widget unfilled (eg. if it
is hidden in the form) we would unexpectedly exit the function Form.send
without sending the form or enabling the button.

opw-4699541
opw-4746416

Forward-Port-Of: odoo/odoo#207092

**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product in

**Current behavior:**
When receiving product after having billed it already, if: A) the product is valuated,
B) the purchase is in a foreign currency,
C) there is an underlying exchange diff between time of bill and receiption

then the exchange difference account move will occur in the regular exchange account.

**Expected behavior:**
It should be for the stock valuation account.

**Steps to reproduce:**
*with anglo saxon accounting enabled*
1. Create a real-time valuated product invoiced on ordered qty
2. Activate a foreign currency, set some exchange rate for today and tomorrow (unique)
3. Make a purchase for the product, invoice -> post
4. The next day, receive the product
5. Check the exchange journal to see the offending AMLs

**Cause of the issue:**
In this flow, when the receipt is validated, at this point: *from `_validate_accounting_entries()`*
https://github.com/odoo/odoo/blob/7e7c1abeead0d4ef19ec15d50808ab33a642d25e/addons/stock_account/models/account_move.py#L185 the SVL linkage is somewhat broken because the bill's SVL was generated before the receiption's.

It means the exchange diff reconciliation proceeds as "usual" (without the `stock_account` module impacting the process) so the regular journal and accounts are used to record the amounts.

**Fix:**
Add overrides for getting the relevant journal and account(s) inside `_prepare_exchange_difference_move_vals()` in order to prevent `real_time` valuated product moves from generating AMLs in the ordinary exchange account (instead, use the stock journal and stock valuation account resp.)

opw-4655669

Forward-Port-Of: odoo/odoo#206484
Forward-Port-Of: odoo/odoo#204505

**Current behavior:** Using auto valuation and anglo saxon accounting, when a project has some profitability report items for auto valued product, the COGS invoice lines will appear under the revenue section rather than the cost section of the project's profitability report. **Expected behavior:** COGS lines are shown as costs. **Steps to reproduce:** 1. Create a service product that generates a project on sale, on the project template set a specific analytic account 2. Create anothe

**Current behavior:**
Using auto valuation and anglo saxon accounting, when a project has some profitability report items for auto valued product, the COGS invoice lines will appear under the revenue section rather than the cost section of the project's profitability report.

**Expected behavior:**
COGS lines are shown as costs.

**Steps to reproduce:**
1. Create a service product that generates a project on sale, on the project template set a specific analytic account

2. Create another product with real time valuation and assign the COGS account on the product category's expense account

3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it

4. In the project's settings, open the profitability report observe that the invoice line for the cost of goods sold account entry is displayed as a negative revenue, rather than a cost

**Cause of the issue:**
In `sale_project` there is no logic to separate the COGS AMLs from the rest of an invoice's line ids.

**Fix:**
Transform the loop in `_get_revenues_items_from_invoices` https://github.com/odoo/odoo/blob/bb6a4fbb92b1a1a1e13e32b27c4c9f2813570fda/addons/sale_project/models/project.py#L656 into two loops such that the existing one iterates twice.

First iteration collects the `revenues` items data (exactly as it currently does)

Second iteration collects the `costs` items (cogs lines)

And the method will now return a dict of data for both `revenues` report items and `costs` report items (and should be renamed/refactored in master)

opw-4652472

Forward-Port-Of: odoo/odoo#205777
Forward-Port-Of: odoo/odoo#203936

In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test = False`, we can end up in a situation with a traceback because there are multiple edi users if you count archived users Steps to reproduce: - Select company BE Company CoA - Open Settings > Accounting > PEPPOL Electronic Invoicing - Activate Electronic Invoicing (if is not activated) - Go to

In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test = False`, we can end up in a situation with a traceback because there are multiple edi users if you count archived users

Steps to reproduce:
- Select company BE Company CoA
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Activate Electronic Invoicing (if is not activated)
- Go to Accounting / Configuration / EDI Proxy Users
- Select the unique record (demo2peppol)
- Edit the id_client of the record to another one (this must need Odoo Studio or Odoo Inspector > Write > {"id_client": "another"})
- Go to tree view of EDI Proxy Users
- Archive it
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Remove from PEPPOL (archived record will not be deleted)
- Activate Electronic Invoicing Again (now you have one record active and another not)
- Go to Contacts > Search "BE Company CoA" > Select Contact
- Go to Accounting Tab > Customer Invoices section > Enable eInvoice Format (BIS Billing 3.0)
- Go to Contact & Addresses Tab
- Try to add a new Contact type (error while saving)

opw-4572074

Forward-Port-Of: odoo/odoo#206063
Forward-Port-Of: odoo/odoo#201606

Steps to reproduce the issue: - Create a storable product “P1” - Create a Bill of Materials: - Finished product: 1 unit of P1 - Components: - 1 unit of C1 - Create a manufacturing order to produce 10 units of P1 - Confirm the MO - Split the MO into two: - This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002” - For the first MO (WH-MO-001): - Set Quantity Produced to 1. - Validate it and choose to create a backorder. Problem: - The b

Steps to reproduce the issue:
- Create a storable product “P1”
- Create a Bill of Materials:
    - Finished product: 1 unit of P1
    - Components:
        - 1 unit of C1
- Create a manufacturing order to produce 10 units of P1
- Confirm the MO
- Split the MO into two:
    - This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002”

- For the first MO (WH-MO-001):
    - Set Quantity Produced to 1.
    - Validate it and choose to create a backorder.

Problem:
- The backorder is incorrectly named “WH-MO-001-003” instead of the expected WH-MO-003.

- Additionally, the original MO is renamed “WH-MO-001-001”, which is unexpected.

- However, if you perform the same steps on the second MO (WH-MO-002), the backorder is correctly named “WH-MO-003”, and the original name remains unchanged.

Root cause:
- When the original MO is first split, each resulting MO receives a backorder sequence:

    - First split MO (WH-MO-001): backorder_sequence = 1

    - Second split MO (WH-MO-002): backorder_sequence = 2

- When creating a backorder from an MO with backorder_sequence = 1, the following logic is triggered:

    - https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1844

- Since the condition if backorder_sequence > 1 is false for WH-MO-001:

    - https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1782

- So the name + seq_back is added:

    https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1784

opw-4686959

Forward-Port-Of: odoo/odoo#205760

Versions -------- - 18.0+ Steps ----- 1. Open a quotation template; 2. open the Quote Builder tab; 3. click "Download examples". Issue ----- 404 not found Cause ----- For product: - When commit 3e58523 updated the versions of documentation links from 17.0 to 18.0, it overlooked changing the hash part of the url for `pdfquotebuilderexamples.zip`. For sale_pdf_quote_builder: - The version in the url gets added by the `documentation_link` widget, but it doesn't update the ha

Versions
--------
- 18.0+

Steps
-----
1. Open a quotation template;
2. open the Quote Builder tab;
3. click "Download examples".

Issue
-----
404 not found

Cause
-----
For product:
- When commit 3e58523 updated the versions of documentation links from 17.0 to 18.0, it overlooked changing the hash part of the url for `pdfquotebuilderexamples.zip`.

For sale_pdf_quote_builder:
- The version in the url gets added by the `documentation_link` widget, but it doesn't update the hash part of the download link.

Solution
--------
Change it so it links to https://www.odoo.com/documentation/18.0/_downloads/c2c6ce32294dfddffcfefcf2775f7a09/pdfquotebuilderexamples.zip

opw-4680248

Forward-Port-Of: odoo/odoo#205625
Forward-Port-Of: odoo/odoo#205433

Before this fix, there was a non-deterministic error in the main flow tour : ´Uncaught (in promise)undefined´. This issue occured when the loading of "jsvat" took too much time. The user could have time to click on one of the results, which then caused the destruction of the component before the loading was finish. Then after the loading, there is a call to the "ORM service" in ´getSuggestions´ but no luck the component is already destroyed. This error therefore typically occurs in a to

Before this fix, there was a non-deterministic error in the main flow tour : ´Uncaught (in promise)undefined´.

This issue occured when the loading of "jsvat" took too much time. The user could have time to click on one of the results, which then caused the destruction of the component before the loading was finish.

Then after the loading, there is a call to the "ORM service" in ´getSuggestions´ but no luck the component is already destroyed.

This error therefore typically occurs in a tour depending on :
- the quick selection of a result as soon as it appears (thx to the tour)
- the slow network that delays the loading of the lib (nightly builds)

It is likely that this error has been there for longer but was highlighted by changes that affected these timings. Even if the migration from Clearbit to Dun & Bradstreet [1] would be a good culprit.

In this case the main flow tour was impacted with steps flagged "mobile" only at the stage of creating an opportunity in the CRM. But we doesn't exclude to have the same issue for largest screens.

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

runbot-error: 161434

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

### Issue: The operator `<` is not supported between `New` records. However, the `_compute_average_price` sorts a record set by `id`: https://github.com/odoo/odoo/blob/61b20ddc1646b1a1d81d39bcde688f4e3d5d7425/addons/stock_account/models/product.py#L803-L804 This raises a traceback if these records are New. ### Steps to reproduce: - Install stock_account, sale_stock, purchase - Enable sale margins and dropshipping - Create a storable product tracked by Serial numbers: - invoicing po

### Issue:

The operator `<` is not supported between `New` records. However, the `_compute_average_price` sorts a record set by `id`: https://github.com/odoo/odoo/blob/61b20ddc1646b1a1d81d39bcde688f4e3d5d7425/addons/stock_account/models/product.py#L803-L804 This raises a traceback if these records are New.

### Steps to reproduce:
- Install stock_account, sale_stock, purchase
- Enable sale margins and dropshipping
- Create a storable product tracked by Serial numbers:
    - invoicing policy: delivered quantities
    - costing method of the product category: standard
    - Use the dropshipping route and a set a vendor
- Create and confirm a sale order for 1 unit
- Confirm the associated PO
- On the associated dropship add a new line with a demand of 0 for one more unit of your tracked product
- Assign a serial number on both moves
- Try to validate the dropship picking
#### > Traceback: `<` not supported between instnaces of `NewId` and `NewId`

### Fix:

We can not remove the lambda method used in the sorted here: https://github.com/odoo/odoo/blob/61b20ddc1646b1a1d81d39bcde688f4e3d5d7425/addons/stock_account/models/product.py#L803-L804 Because even if the `_order` of `stock.valuation.layer` model is `create_date, id`:
https://github.com/odoo/odoo/blob/61b20ddc1646b1a1d81d39bcde688f4e3d5d7425/addons/stock_account/models/stock_valuation_layer.py#L17 for real records, it and even if the `sorted` method relies on this order for real records: https://github.com/odoo/odoo/blob/19ae561098369739258a00af52582164551920ec/odoo/models.py#L6335-L6339 it is not supported for new records.

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

Forward-Port-Of: odoo/odoo#206692

Since 18.0, the taxes computation engine is managing the round globally. It means we have helpers and tools to manage features based on multiple base lines at a time. The hsn summary was using a custom representation of a base line with an explicit call to the low level _get_tax_details method. This commit removes this custom code to use the generic base lines instead. Also, this commit adds a test in POS to ensure the feature is working. --- I confirm I have signed the CLA and read the P

Since 18.0, the taxes computation engine is managing the round globally. It means we have helpers and tools to manage features based on multiple base lines at a time. The hsn summary was using a custom representation of a base line with an explicit call to the low level _get_tax_details method. This commit removes this custom code to use the generic base lines instead.

Also, this commit adds a test in POS to ensure the feature is working.

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

Forward-Port-Of: odoo/odoo#205245
Forward-Port-Of: odoo/odoo#201253

Steps to reproduce ------------------ 1. Enable self order, and enable presets 2. In self order interface, choose the preset "takeout" that will by default be configured to use time slots. 3. When paying the order, select a time, say 12:00 Observation ----------- In the PoS session interface, go to orders, and observe that this order shows the time as 14:00 (or whatever your tz diff is + 12:00). Reason ------ When assigning a datetime to `preset_time`, we assign it as a local datet

Steps to reproduce
------------------
1. Enable self order, and enable presets
2. In self order interface, choose the preset "takeout" that will by default be configured to use time slots.
3. When paying the order, select a time, say 12:00

Observation
-----------
In the PoS session interface, go to orders, and observe that this order shows the time as 14:00 (or whatever your tz diff is + 12:00).

Reason
------
When assigning a datetime to `preset_time`, we assign it as a local datetime, when it waits to be assigned a UTC datetime. So for instance, if we assign "2025-04-25 12:00:00" to it, it will be interpreted as UTC date an hence in the PoS orders UI, we see it converted to local date and hence a mismatch.

Fix
---
Convert the formatted date string into UTC before assigning it to `preset_time`.

opw-4728248

Forward-Port-Of: odoo/odoo#207426

### Steps to reproduce: - Create a storable product tracked by lot and lot valuated - Create a lot for 10 units of that product in stock - login a user that is not administrator in inventory - Create and confirm a delivery for 1 units of your product - Try to validate the delivery #### > access right error ### Cause of the issue: During the `_action_done` of the `stock.move` we will need to change the valuated price of the product after done: https://github.com/odoo/odoo/blob/6beb

### Steps to reproduce:

- Create a storable product tracked by lot and lot valuated
- Create a lot for 10 units of that product in stock
- login a user that is not administrator in inventory
- Create and confirm a delivery for 1 units of your product
- Try to validate the delivery
#### > access right error

### Cause of the issue:

During the `_action_done` of the `stock.move` we will need to change the valuated price of the product after done:
https://github.com/odoo/odoo/blob/6beb3ea82d75513803ae78f5bc71024313938a97/addons/stock_account/models/stock_move.py#L378 https://github.com/odoo/odoo/blob/6beb3ea82d75513803ae78f5bc71024313938a97/addons/stock_account/models/stock_move.py#L461-L464 However, only admin inventory users have the read access rights to the `stock.valuation.layer` model.

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

Forward-Port-Of: odoo/odoo#207436
Forward-Port-Of: odoo/odoo#204676

steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR

steps to reproduce:
1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`)
2. create a time off type that can only be taken in days
3. create an accrual allocation with the plan and that time off type

The calculation in the dashboard shows the amount of hours as days.

The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case.

task: 4076800

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

Forward-Port-Of: odoo/odoo#207145
Forward-Port-Of: odoo/odoo#176765

https://runbot.odoo.com/odoo/error/163640 Forward-Port-Of: odoo/odoo#207642

https://runbot.odoo.com/odoo/error/163640

Forward-Port-Of: odoo/odoo#207642

Description of the issue/feature this PR addresses: modified labels are not sent to the ETA Current behavior before PR: -> change an invoice line label -> post the invoice -> send to ETA -> only product name is sent to the ETA Desired behavior after PR is merged: -> change an invoice line label -> post the invoice -> send to ETA -> line label is sent to the ETA this is based on this pr: https://github.com/odoo/odoo/pull/200907 --- I confirm I have signed the CLA and read the PR

Description of the issue/feature this PR addresses:
modified labels are not sent to the ETA
Current behavior before PR:
-> change an invoice line label
-> post the invoice
-> send to ETA
-> only product name is sent to the ETA
Desired behavior after PR is merged:
-> change an invoice line label
-> post the invoice
-> send to ETA
-> line label is sent to the ETA

this is based on this pr: https://github.com/odoo/odoo/pull/200907

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

Forward-Port-Of: odoo/odoo#206291
Forward-Port-Of: odoo/odoo#203275

The config param skip_create_bank_account_on_reconcile currently also skips the search. In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port 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#

The config param skip_create_bank_account_on_reconcile currently also skips the search.
In the original commit https://github.com/odoo/odoo/commit/62354663c6622f6d059e36097f0455ab5890b616, it was not the case. It was a mistake during the fw-port

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#206496
Forward-Port-Of: odoo/odoo#206420

Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4 **Steps to reproduce the bug:** - Install the “Sales” module. - Do not enable the "Units of Measure" option in the settings. - Create a new quotation. - In the sale order line, enable the Product Variant field. - Try to create a new “product.product” **Problem:** A validation Error is triggered: ``` The operation cannot be completed - Create/update: a mandatory field is not set. - D

Bug introduced by: https://github.com/odoo/odoo/commit/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4

**Steps to reproduce the bug:**
- Install the “Sales” module.
- Do not enable the "Units of Measure" option in the settings.
- Create a new quotation.
- In the sale order line, enable the Product Variant field.
- Try to create a new “product.product”

**Problem:**
A validation Error is triggered:

```
The operation cannot be completed
 - Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.

Model: Product (product.template) Field: Unit of Measure (uom_id)

```
**Explanation:**
This happens because a default value for the UoM is passed through the
context. As a result, we skip the computation of “uom_id”:
https://github.com/odoo/odoo/blob/2b38c1f446441e04f8d85125a9ec6562d13b7ce8/addons/product/models/product_template.py#L27

However, this default is derived from the field “product_uom” that is
present in the view but restricted to users in the "uom.group_uom"
group. If the current user doesn't belong to this group (if you don't
enable the param in the settings), the field is hidden and its value is
empty, causing the default to be set to False.

https://github.com/odoo/odoo/blob/25d0c760bbfabb3cc7d471b08b5b06fe1cfc2ec4/addons/sale/views/sale_order_views.xml#L537


**Solution:**
Force the computation of “uom_id” by removing “default_uom_id” from the
context when its value is “False”.

opw-4717913

Forward-Port-Of: odoo/odoo#205881

[This commit] used `record.id` as if they were `record.resId` resulting in an issue when trying to delete a tag. How to reproduce: - Use the chatter to send an email using the full composer - add some email recipients - try to remove them using backspace -> traceback This fix correctly renames properties that should be `resId`, and removes the `id` override (`record.id` is a value specific to the relational model from `/web/`). [This commit]: https://github.com/odoo/odoo/commit/1f

[This commit] used `record.id` as if they were `record.resId` resulting in an
issue when trying to delete a tag.

How to reproduce:
- Use the chatter to send an email using the full composer
- add some email recipients
- try to remove them using backspace -> traceback

This fix correctly renames properties that should be `resId`, and removes the
`id` override (`record.id` is a value specific to the relational model from
`/web/`).

[This commit]: https://github.com/odoo/odoo/commit/1f34abc173f07b6d20c08a27ec57c7025cb20562

task-4731774

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Kadam Darji <kmdi@odoo.com>

Forward-Port-Of: odoo/odoo#206302

There was an issue in the `PropertyDefinition:state.propertyDefinition`, which could sometimes not be updated properly, resulting in a traceback after multiple property definition changes. ### How to reproduce: - Open a CRM Lead form view and add a property of type `tags`. - Save and fully reload the form view. - Change the property type to `separator` - Change the property name to another value. - Click outside the popover to close it. => Traceback ``` Cannot read properties of und

There was an issue in the `PropertyDefinition:state.propertyDefinition`,
which could sometimes not be updated properly, resulting in a traceback after
multiple property definition changes.

### How to reproduce:
- Open a CRM Lead form view and add a property of type `tags`.
- Save and fully reload the form view.
- Change the property type to `separator`
- Change the property name to another value.
- Click outside the popover to close it.
=> Traceback
```
Cannot read properties of undefined (reading 'type')
at  PropertiesField.onPropertyDefinitionChange
```

### Technical explanation:
The `propertyDefinition` argument given to `onChange` props of
`PropertyDefinition` component is expected to be modified in place, since it is
used as the `propertyDefinition` state value.
`pick` function creates a shallow copy, therefore using it on
`propertyDefinition` in `PropertiesField:onPropertyDefinitionChange` and
applying changes on that copy (i.e. in `_regeneratePropertyName`) will prevent
these changes to be registered in the
`PropertyDefinition:state.propertyDefinition`, resulting in inconsistent values
with `PropertyField:propertyList`, which would manifest at the next definition
change, since `_getPropertyIndex` would not be able to find the index of the
now obsolete `propertyDefinition`.

task-4743860

Forward-Port-Of: odoo/odoo#206977
Forward-Port-Of: odoo/odoo#206871

When invoicing a pos.order with global discount, the created invoice don't have the correct amount because the sign of the quantity of the discount line is inverted. To identify the sign of the discount_line, we must base it on the sign of the order, not on the line. Forward-Port-Of: odoo/odoo#201385

When invoicing a pos.order with global discount, the created invoice don't have the correct amount because the sign of the quantity of the discount line is inverted. To identify the sign of the discount_line, we must base it on the sign of the order, not on the line.

Forward-Port-Of: odoo/odoo#201385

Add missing codes for payment methods --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207034

Add missing codes for payment methods


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

Forward-Port-Of: odoo/odoo#207034

The certificate and keys models were added in 18.0. A few docstrings could help devs using those methods. Furthermore, a few more checks and robustness were added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202253

The certificate and keys models were added in 18.0. A few docstrings could help devs using those methods.

Furthermore, a few more checks and robustness were added.

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

Forward-Port-Of: odoo/odoo#202253

Steps to reproduce ------------------ 1. Set the default barcode parser to GS1 nomenclature 2. Don't set a fallback parser 3. Scan a non-GS1 compatible barcode Observation: A traceback! Improvement in this PR ---------------------- Instead of the not-much-useful traceback, we show a warning message asking the user to try setting a fallback parser from PoS settings. opw-4739161 Forward-Port-Of: odoo/odoo#206986

Steps to reproduce
------------------
1. Set the default barcode parser to GS1 nomenclature
2. Don't set a fallback parser
3. Scan a non-GS1 compatible barcode

Observation: A traceback!

Improvement in this PR
----------------------
Instead of the not-much-useful traceback, we show a warning message asking the user to try setting a fallback parser from PoS settings.

opw-4739161

Forward-Port-Of: odoo/odoo#206986

Since the widget for non trailing zeros float is used in payroll and payroll does not depend on hr_holidays now, we move the widget to core hr Forward-Port-Of: odoo/odoo#207441

Since the widget for non trailing zeros float is used in payroll and payroll does not depend on hr_holidays now, we move the widget to core hr

Forward-Port-Of: odoo/odoo#207441

Commit 34ba0d3251486a3f7fd16709debb5c2b2d14ffa9 dropped the cast to integer for cart quantities, potentially allowing customers to buy 0.01 quantities of a product, which isn't the expected behavior. This commit casts the values given through the controllers, still keeping the ability for custom code to generate lines with floats as quantities if needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207271

Commit 34ba0d3251486a3f7fd16709debb5c2b2d14ffa9 dropped the cast to integer for cart quantities, potentially allowing customers to buy 0.01 quantities of a product, which isn't the expected behavior.

This commit casts the values given through the controllers, still keeping the ability for custom code to generate lines with floats as quantities if needed.


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

Forward-Port-Of: odoo/odoo#207271

task-4715664 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#205388

task-4715664

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

It seems it was an error of https://github.com/odoo/odoo/commit/077f6d449a660ee6961cce8174c9c6caaf5bc23f. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207465

It seems it was an error of https://github.com/odoo/odoo/commit/077f6d449a660ee6961cce8174c9c6caaf5bc23f.




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

Forward-Port-Of: odoo/odoo#207465

## Issue: Survey's PDF certifications no longer display the company logo when printed by other companies' users. ## Steps to reproduce: - Create a survey with certification and ensure `Require Login` is checked; - Share the survey (copy the `Survey Link`); - In a private navigator (to ensure no login data are saved): - Log in as Demo user; - Answer the survey (using the copied link above); - Go to Surveys / Participations; - Enter the record of your test (`Contact` field shoul

## Issue:
Survey's PDF certifications no longer display the company logo when printed by other companies' users.

## Steps to reproduce:
- Create a survey with certification and ensure `Require Login` is checked;
- Share the survey (copy the `Survey Link`);
- In a private navigator (to ensure no login data are saved):
    - Log in as Demo user;
    - Answer the survey (using the copied link above);
- Go to Surveys / Participations;
- Enter the record of your test (`Contact` field should match Demo's data);
- Open the PDF certification in the chatter.

## Cause:
The company `logo` field is a Binary field related to the partner's `image_1920`.
The retrieval method was changed to access `partner_id.image_1920` directly with `sudo`, since `sudo` does not apply when accessing the related field (`logo`) directly.
However, this change broke the standard certification printing layout, likely due to rendering issues with the direct access method.

## Fix:
Reverts logo access back to the related field `company_id.logo` to restore compatibility with certification printing.
Partial revert of commit 9b4c4ad8d1a238c6f7f4bea52d3f64016a6ff325 as already applied by JKE on Odoo.
Ensures the certification printing is still allowed for other companies' users.

opw-4266445
opw-4657294

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

Forward-Port-Of: odoo/odoo#207196
Forward-Port-Of: odoo/odoo#204262

When the website domain is defined using punycode (e.g., `xn--ingenieurbro-mlb.localhost`), navigating to the Unicode URL (e.g., `Ingenieurbüro.localhost`) would not reflect the updated `robots.txt`. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with punycode (e.g., http://xn--ingenieurbro-mlb.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://Ingenieurbüro.localhost:8069 and notice that the changes are n

When the website domain is defined using punycode (e.g., `xn--ingenieurbro-mlb.localhost`), navigating to the Unicode URL (e.g., `Ingenieurbüro.localhost`) would not reflect the updated `robots.txt`.

Steps to reproduce the issue:

- Navigate to Website > Configuration > Website.
- Set a domain name with punycode (e.g., http://xn--ingenieurbro-mlb.localhost:8069).
- Go to settings and modify the robots.txt file.
- Visit http://Ingenieurbüro.localhost:8069 and notice that the changes are not reflected.

This commit ensures the correct handling of punycode domains so that the robots.txt is properly served, regardless of whether the domain is accessed in Unicode or punycode form.

opw-4641081

Forward-Port-Of: odoo/odoo#206215

**Current behavior before PR:** - Double-clicking on a table border would select the table column if the selection was inside a table cell. - If the selection was outside the table, a traceback will occur. **Desired behavior after PR is merged:** - Now, a table cell is now only selected when the double-click is performed inside the cell, not on its border. task:4730234 Forward-Port-Of: odoo/odoo#206251

**Current behavior before PR:**

- Double-clicking on a table border would select the table column if the selection was inside a table cell.
- If the selection was outside the table, a traceback will occur.

**Desired behavior after PR is merged:**

- Now, a table cell is now only selected when the double-click is performed inside the cell, not on its border.

task:4730234

Forward-Port-Of: odoo/odoo#206251

This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#207245 Forward-Port-Of: odoo/odoo#205940

This commit remove the readonly on the tax_ids field, in the expense_split wizard.

task-4703493

Forward-Port-Of: odoo/odoo#207245
Forward-Port-Of: odoo/odoo#205940

This commit fixes the following two issues in the menu creation dialog: **Issue 1:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu Editor." - Drag a menu item (without dropping it) to the right to create a sub-menu. - The issue is that while dragging the menu item, when the placeholder is in a sub-menu position, the menu item keeps its original width instead of taking the width of a sub-menu item. This is confusing and uncle

This commit fixes the following two issues in the menu creation dialog:

**Issue 1:**

- Install the Website app and go to the homepage.
- In the backend navbar, click on "Site" and then on "Menu Editor."
- Drag a menu item (without dropping it) to the right to create a sub-menu.
- The issue is that while dragging the menu item, when the placeholder is in a sub-menu position, the menu item keeps its original width instead of taking the width of a sub-menu item. This is confusing and unclear from a UX perspective.

| BEFORE  | AFTER |
| ------------- | ------------- |
| ![image](https://github.com/user-attachments/assets/7b89bde2-2b22-4d9c-9665-078bb0906e26)  | ![image](https://github.com/user-attachments/assets/d9cf0b4f-3d5c-4d33-ba3c-08756d580f20)  |

----------------

**Issue 2:**

- Install the Website app and go to the homepage.
- In the backend navbar, click on "Site" and then on "Menu Editor."
- Drag and drop the second menu item to the right to create a sub-menu.
- Drag another menu item (without dropping it) to the right to create a second sub-menu below the first one.
- Without releasing it, continue dragging it to the right.
- The issue is that the placeholder disappears at this point. To make it reappear, the menu item must be moved slightly to the left again. This results in a very poor user experience and makes sub-menu creation messy.

| BEFORE  | AFTER |
| ------------- | ------------- |
| ![image](https://github.com/user-attachments/assets/694d89d1-4391-4ffa-bb5e-21f8d6b1ffc3)  | ![image](https://github.com/user-attachments/assets/2c5e25d4-996a-4fde-9ed0-a52e1ed60923)  |

task-4422810

Forward-Port-Of: odoo/odoo#204436

This error is generated when a user tries to `create new equipment`. Steps to Reproduce : 1. Install the `MRP` and `Maintenance` modules 2. Go to Settings and set the `Barcode Nomenclature` to `Default GS1 Nomenclature`. 3. In Maintenace > Equipments > Machine & Tools > New. `TypeError: expected string or bytes-like object, got 'bool'` The error occurs when the system attempts to parse a False value through `parse_barcode`, which expects a string. This commit resolves the error

This error is generated when a user tries to `create new equipment`.

Steps to Reproduce :
1. Install the `MRP` and `Maintenance` modules
2.  Go to Settings and set the `Barcode Nomenclature` to `Default GS1 Nomenclature`.
3. In  Maintenace > Equipments > Machine & Tools > New.

`TypeError: expected string or bytes-like object, got 'bool'`

The error occurs when the system attempts to parse a False value through `parse_barcode`, which expects a string.

This commit resolves the error by returning the original condition if a value is false.

Sentry:6544673924
OPW : 4725056

Forward-Port-Of: odoo/odoo#206268

The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_

The date used in statement lines is invalid when lines
are created via bank synchronization, and the user has
configured a default date for the Invoice/Bill Date field.

Steps to reproduce:
- Set a default value for the Invoice/Bill Date field.
- Connect to Demo Bank and import the test statement line.
- Check the statement line date; it will use the default
  Invoice/Bill Date value instead of the correct one.

The issue comes from the fact that during the 
`st_line.move_id.write(to_write)`, the date field gets considered 'dirty'
by the ORM (unless it is explicitly set in the vals), and when the
`account.move.line` tries to set-up its date, which is related to the
move, the compute method for the date is triggered as the field was
flagged as dirty.

opw-4662209

Forward-Port-Of: odoo/odoo#204665

### Before this commit: The warning message `Invoice will soon be sent to EDI` was not displayed correctly, resulting in a broken UI at the top of the invoice form. - **UI before fix:**  ### After this commit: The warning UI has been fixed by adding appropriate CSS classes, ensuring proper alignment and styling. - **UI after fix:** ![image](https://github.com/user-attachments/assets/ed558f2b-12fb-

### Before this commit:
The warning message `Invoice will soon be sent to EDI` was not displayed correctly, resulting in a broken UI at the top of the invoice form.

- **UI before fix:** ![image](https://github.com/user-attachments/assets/4be4117a-dd5d-407f-a45d-d9db0ba1b795)

### After this commit:
The warning UI has been fixed by adding appropriate CSS classes, ensuring proper alignment and styling.

- **UI after fix:** ![image](https://github.com/user-attachments/assets/ed558f2b-12fb-4001-b0b1-ba2726c0926b)




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

Forward-Port-Of: odoo/odoo#206983

**Current behavior before PR:** - When gradient image is applied on element other than font or span, applying a gradient color to its child text would trigger a traceback. **Desired behavior after PR is merged:** - Now, if the gradient image is applied on element other than font or span, applying gradient color on its child text will applied gradient color properly. task:4730500 Forward-Port-Of: odoo/odoo#206866 Forward-Port-Of: odoo/odoo#206272

**Current behavior before PR:**

- When gradient image is applied on element other than font or span, applying a gradient color to its child text would trigger a traceback.

**Desired behavior after PR is merged:**

- Now, if the gradient image is applied on element other than font or span, applying gradient color on its child text will applied gradient color properly.

task:4730500

Forward-Port-Of: odoo/odoo#206866
Forward-Port-Of: odoo/odoo#206272

**Before this PR:** - In a fullscreen mode, mail preview was visible only on the top half of the screen. - Traceback when changing name of the image. - 'Create and edit' option when creating a new tag. **After this PR:** - String of `reward_message` will be changed to 'Thank You Message'. - Only 'Create' option will displayed while creating a new tag. - Mail preview will be visible in the center of the screen. - 'Add to Templates' in mass_mailing preview will no longer be visible. T

**Before this PR:**
- In a fullscreen mode, mail preview was visible only on the top half of the screen.
- Traceback when changing name of the image.
- 'Create and edit' option when creating a new tag.

**After this PR:**
- String of `reward_message` will be changed to 'Thank You Message'.
- Only 'Create' option will displayed while creating a new tag.
- Mail preview will be visible in the center of the screen.
- 'Add to Templates' in mass_mailing preview will no longer be visible.

Task-4387904

Forward-Port-Of: odoo/odoo#205930
Forward-Port-Of: odoo/odoo#198470

This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image. Steps to Reproduce: - Install the `web` module. - Go to `Settings`. - In the `companies` section, under Your Company, click on `Update Info`. - Upload an image with dimensions width = 8 and height = 901. - Go back, and in the Companies section, click `Configure Document Layout`. ValueError: height and width must be > 0 This error is due to the current lo

This error occurs when a user attempts to `Configure Document Layout` in settings using a large vertically-oriented image.

Steps to Reproduce:

 - Install the `web` module.
 - Go to `Settings`.
 - In the `companies` section, under Your Company, click on `Update Info`.
 - Upload an image with dimensions width = 8 and height = 901.
 - Go back, and in the Companies section, click `Configure Document Layout`.

ValueError: height and width must be > 0

This error is due to the current logic in `base_document_layout.py`, where the width (w) is computed using int(50 * base_w / base_h). For highly vertical images (e.g., width = 8, height = 901), this calculation results in w = 0, which subsequently causes a ValueError when passed to the resize() function.

This commit resolves the error by using `math.ceil` to compute the width (w) instead of int, ensuring that the value is never zero, even for extremely vertical images.

Sentry-6516888945

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

Forward-Port-Of: odoo/odoo#205017

When submitting message templates to the WhatsApp API, the request could occasionally time out before receiving a response. This resulted in templates being created on Facebook's side, but not registered in Odoo, as the template ID assigned by Facebook was never received. Since template names must be unique, resubmitting the same template fails, leaving the systems out of sync. This commit increases the request timeout to (10s connect, 30s read) to reduce the chance of timeouts. opw-470

When submitting message templates to the WhatsApp API, the request could occasionally time out before receiving a response. This resulted in templates being created on Facebook's side, but not registered in Odoo, as the template ID assigned by Facebook was never received.

Since template names must be unique, resubmitting the same template fails, leaving the systems out of sync.

This commit increases the request timeout to (10s connect, 30s read) to reduce the chance of timeouts.

opw-4706852
opw-4720635

Forward-Port-Of: odoo/enterprise#84209
Forward-Port-Of: odoo/enterprise#83581

Forward-Port-Of: odoo/enterprise#82967

Forward-Port-Of: odoo/enterprise#82967

In [PR 191823](https://github.com/odoo/odoo/pull/191823) in the comunity repo, a new functionality was added to allow a user with salesman permissions to send and print the invoice. However this change had unexpected effects in the mexican localization, precisely in the _clean_cfdi_values function which now removes all values from the dictionary that are not plain text. The complemento's injector was using the addenda value from the dictionary which was a recordset of the l10n_mx_edi.addenda

In [PR 191823](https://github.com/odoo/odoo/pull/191823) in the comunity repo, a new functionality was added to allow a user with salesman permissions to send and print the invoice. However this change had unexpected effects in the mexican localization, precisely in the _clean_cfdi_values function which now removes all values from the dictionary that are not plain text. 

The complemento's injector was using the addenda value from the dictionary which was a recordset of the l10n_mx_edi.addenda model, with these changes, this recordset was removed from the dictionary, causing the complemento to never be added. 

To fix it, the values relevant to the complemento have been marked as unsudo, thus preventing them from being removed in the clean_cfdi_values function.

Forward-Port-Of: odoo/enterprise#83772

### Steps to reproduce: - Accounting dashboard - Click on the three dots of the "Bank" card - Click "import file" - Try importing a CAMT file with the namespace "camt" - Traceback Other issue: - Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1") - Traceback ### Cause: Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace ke

### Steps to reproduce:
- Accounting dashboard
- Click on the three dots of the "Bank" card
- Click "import file"
- Try importing a CAMT file with the namespace "camt"
- Traceback

Other issue:
- Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1")
- Traceback

### Cause:
Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace key because if the key was different from 'ns' the `findall` didn't work.

Second issue: Some banks use their own codes in the CAMT files. The specification has numerous codes which Odoo added in a dictionary, and it reads from this dictionary to get a description. When there is a custom code, Odoo tries to read a key which doesn't exist explaining the traceback.

### Solution:
- Change the way namespace is computed using the tag.

- If the code is not in the dictionary, we take the custom code.

opw-4553152

Forward-Port-Of: odoo/enterprise#82888

fix wrong formulas in different tables: - in "worst churn" under Value, starting the 7th line, the value used was "recurring_monthly" instead of "amount_signed" - in "worst contraction", the 10th line didn't use the list 4 like the rest of the table - in "top expansion", the 10th line didn't use the list 2 like the rest of the table Task: 4711532 Forward-Port-Of: odoo/enterprise#83019

fix wrong formulas in different tables:
- in "worst churn" under Value, starting the 7th line, the value used was "recurring_monthly" instead of "amount_signed"
- in "worst contraction", the 10th line didn't use the list 4 like the rest of the table
- in "top expansion", the 10th line didn't use the list 2 like the rest of the table

Task: 4711532

Forward-Port-Of: odoo/enterprise#83019

Creating an SO requires either sudo or some sort of SO group which is not set by default. In this case it looks like sudo-ing for creation during setup then unsudo-ing works fine. So do that to avoid over-accessing. https://runbot.odoo.com/odoo/error/163657 Forward-Port-Of: odoo/enterprise#84272

Creating an SO requires either sudo or some sort of SO group which is not set by default.

In this case it looks like sudo-ing for creation during setup then unsudo-ing works fine. So do that to avoid over-accessing.

https://runbot.odoo.com/odoo/error/163657

Forward-Port-Of: odoo/enterprise#84272

Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice. task-4588311 Forward-Port-Of: odoo/enterprise#83771 Forward-Port-Of: odoo/enterprise#79775

Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice.

task-4588311

Forward-Port-Of: odoo/enterprise#83771
Forward-Port-Of: odoo/enterprise#79775

With this commit we remove the namespaces that are not used in the cdfi document. Steps: - Create an invoice and send the edi document - Look at the xml -> namespace `xmlns:cce20="http://www.sat.gob.mx/ComercioExterior20"` is included but unused opw-4493568 Forward-Port-Of: odoo/enterprise#83838

With this commit we remove the namespaces that are not used
in the cdfi document.

Steps:

- Create an invoice and send the edi document
- Look at the xml
-> namespace `xmlns:cce20="http://www.sat.gob.mx/ComercioExterior20"`
   is included but unused

opw-4493568

Forward-Port-Of: odoo/enterprise#83838

- Set default `filter_account_type` to 'receivable' in follow-up report view for more relevant results. - Update the selection of default journal types to 'sale', 'bank' and 'cash' for follow-up reports. opw-[4724675](https://www.odoo.com/odoo/project/967/tasks/4724675), [4735031](https://www.odoo.com/odoo/project/967/tasks/4735031) Forward-Port-Of: odoo/enterprise#83513

- Set default `filter_account_type` to 'receivable' in follow-up report view for
  more relevant results.
- Update the selection of default journal types to 'sale', 'bank' and 'cash'
  for follow-up reports.

opw-[4724675](https://www.odoo.com/odoo/project/967/tasks/4724675), [4735031](https://www.odoo.com/odoo/project/967/tasks/4735031)

Forward-Port-Of: odoo/enterprise#83513

Forward-Port-Of: odoo/enterprise#83084 Forward-Port-Of: odoo/enterprise#81187

Forward-Port-Of: odoo/enterprise#83084
Forward-Port-Of: odoo/enterprise#81187

Before this commit, when a sign field type was attached to a model, it could be automatically completed if the sign.request was linked to another model. Steps to reproduce: 1) Create a sign field type: text, model: sale.order, field: reference 2) Add this field in a sign.template. 3) Open a manufacturing order (mrp.production), create a sign request for it 4) sign the MO, the reference field is automatically filled. The method getting the value to fill, don't check the model. As a reus

Before this commit, when a sign field type was attached to a model, it could be automatically completed if the sign.request was linked to another model.

Steps to reproduce:
1) Create a sign field type: text, model: sale.order, field: reference 2) Add this field in a sign.template.
3) Open a manufacturing order (mrp.production), create a sign request
   for it
4) sign the MO, the reference field is automatically filled. The method getting the value to fill, don't check the model. As a reuslt if the same field exists, it will be filled.

taskid: 4672517

Forward-Port-Of: odoo/enterprise#82085

The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83459 Forward-Port-Of: odoo/enterprise#83112

The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set).
A common case would be to create deferred entries with this transaction field set.

opw-4688616

Forward-Port-Of: odoo/enterprise#83459
Forward-Port-Of: odoo/enterprise#83112

The pos.order form view removed the refund button for the inherited view. This can cause issues if other modules depend on that button to add to the arch, so making it invisible would still make the element accessible by xpath. ci error https://runbot.odoo.com/runbot/build/78974416 Forward-Port-Of: odoo/enterprise#84118 Forward-Port-Of: odoo/enterprise#84030

The pos.order form view removed the refund button for the inherited view.
This can cause issues if other modules depend on that button to add to the arch, so making it invisible would still make the element accessible by xpath.

ci error https://runbot.odoo.com/runbot/build/78974416

Forward-Port-Of: odoo/enterprise#84118
Forward-Port-Of: odoo/enterprise#84030

In this commit: - Updated Table 12 HSN Summary to classify HSN data separately for B2B and B2C as per the latest GST advisory. - Previously, all HSN summary data was pushed into Table 12 without distinction. - Now, HSN summary is categorized into B2B and B2C for accurate reporting. Task ID: 4465102 Forward-Port-Of: odoo/enterprise#84218 Forward-Port-Of: odoo/enterprise#80738

In this commit:
- Updated Table 12 HSN Summary to classify HSN data separately for B2B and B2C as per the latest GST advisory.
- Previously, all HSN summary data was pushed into Table 12 without distinction.
- Now, HSN summary is categorized into B2B and B2C for accurate reporting.

Task ID: 4465102

Forward-Port-Of: odoo/enterprise#84218
Forward-Port-Of: odoo/enterprise#80738

In cc759094a32e413cb1b71cbbe7be9dc85ded819f, the follow-up report generation was moved from `_send_email` to `execute_followup`, which is only called during manual follow-up processing. As a result, the report was missing when follow-ups were triggered by the cron. This commit moves the report generation logic to `_execute_followup_partner`, which is called in both manual and automatic (cron) cases. Also, patched `_run_wkhtmltopdf` in `TestAccountFollowupReports` to prevent tests from han

In cc759094a32e413cb1b71cbbe7be9dc85ded819f, the follow-up report generation was moved from `_send_email` to `execute_followup`, which is only called during manual follow-up processing. As a result, the report was missing when follow-ups were triggered by the cron.

This commit moves the report generation logic to
`_execute_followup_partner`, which is called in both manual and automatic (cron) cases.

Also, patched `_run_wkhtmltopdf` in `TestAccountFollowupReports` to prevent tests from hanging, since PDF generation requires multiple workers and tests run with only one.

task-4752110

Forward-Port-Of: odoo/enterprise#84114

- Adding 'invoice_received' as an accepted state in account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display on vendor bills in 17.0, making SAT status no longer remain None. - Making adjustments to functions updating SAT status related fields for vendor bills. - Adding a test for SAT status for creating and cancelling vendor bills. The change necessary to display 'Update SAT' button was already implemented in 17.0 in https://github.com/odoo/enterpr

- Adding 'invoice_received' as an accepted state in account_move.py ->
_compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display
on vendor bills in 17.0, making SAT status no longer remain None.
- Making adjustments to functions updating SAT status related fields for vendor
bills.
- Adding a test for SAT status for creating and cancelling vendor bills.

The change necessary to display 'Update SAT' button was already implemented in
17.0 in https://github.com/odoo/enterprise/commit/931d7b199f1183acfbb42325025a6b62b2e73de1
but not forward ported yet.

task-4368532

Forward-Port-Of: odoo/enterprise#83946
Forward-Port-Of: odoo/enterprise#80201

**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form for a helpdesk team. - Create a menu item for the website, using a URL starting with helpdesk, e.g. `/helpdesk-123-test` - This menu is always invisible to the public user. **Cause** This issue was fixed in previous versions, but it appears the duplicated `_compute_visible` code present

**Issue**
Menu items starting with helpdesk in their URL were not dispalyed to the
public user in some cases.

**Steps to reproduce**
- Have `website_helpdesk` installed.
- Activate the website form for a helpdesk team.
- Create a menu item for the website, using a URL starting with
helpdesk, e.g. `/helpdesk-123-test`
- This menu is always invisible to the public user.

**Cause**
This issue was fixed in previous versions, but it appears the
duplicated `_compute_visible` code present in `website.py` was
not deleted in forward ports of the fix (see enterprise PR 63105).
https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L24-L26
As a result, the menu item starting with `/helpdesk` is matched
as a helpdesk menu, but will logically not be part of the helpdesk
published menus:
https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L30-L32

opw-4560291

Forward-Port-Of: odoo/enterprise#83863
Forward-Port-Of: odoo/enterprise#82824

Steps to reproduce: - starting planning_test_tour => error raised Source: - https://github.com/odoo/enterprise/pull/69888 introduced a new method _get_non_working_days_bounds which computes user_tz but the value can be False and also not coherent with user_tz computed in _calculate_start_end_dates (method from wich this new method is called) Fix: user_tz is computed the same way as its computed in the original method, the code is duplicated as signature cannot be changed in stable. For

Steps to reproduce:
- starting planning_test_tour => error raised

Source:
- https://github.com/odoo/enterprise/pull/69888 introduced a new method _get_non_working_days_bounds which computes user_tz but the value can be False and also not coherent with user_tz computed in _calculate_start_end_dates (method from wich this new method is called)

Fix:
user_tz is computed the same way as its computed in the original method, the code is duplicated as signature cannot be changed in stable.

Forward-Port-Of: odoo/enterprise#83955
Forward-Port-Of: odoo/enterprise#83926

### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occ

### Issue:

It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point.

### Step to reproduce:

- Set up Sendcloud, for a belgian company
- Select bpost and dpd for delivery and returns while loading products
- On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method.
- With an employee confirm the delivery order that was created
#### > A problem occured in the generation of the return label

### Cause of the issue:

The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here:
https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point.

#### Note:

Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels.

opw-4562040

Forward-Port-Of: odoo/enterprise#83436
Forward-Port-Of: odoo/enterprise#83357

Updated test case `test_searching_lot_gs1`. This commit updates the test_searching_lot_gs1 test case to include an assertion ensuring that no lot is returned while searching. Related Community PR: https://github.com/odoo/odoo/pull/206268 Sentry:6544673924 OPW: 4725056 Forward-Port-Of: odoo/enterprise#83920

Updated test case `test_searching_lot_gs1`.

This commit updates the test_searching_lot_gs1 test case to include an assertion ensuring that no lot is returned while searching.

Related Community PR: https://github.com/odoo/odoo/pull/206268

Sentry:6544673924
OPW: 4725056

Forward-Port-Of: odoo/enterprise#83920

In this commit: === - Fixed a traceback that occurred during menu synchronization caused by multiple product.template.attribute.value (PTAV) records found, where only one was expected (singleton error). - The issue was due to having both active and inactive PTAV records linked to a product. task-4753173 Forward-Port-Of: odoo/enterprise#84127

In this commit:
===
- Fixed a traceback that occurred during menu synchronization caused by multiple product.template.attribute.value (PTAV) records found, where only one was expected (singleton error).
- The issue was due to having both active and inactive PTAV records linked to a product.

task-4753173

Forward-Port-Of: odoo/enterprise#84127

The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_write)

The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field.

Steps to reproduce:
- Set a default value for the Invoice/Bill Date field.
- Connect to Demo Bank and import the test statement line.
- Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one.

The issue comes from the fact that during the
`st_line.move_id.write(to_write)`, the date field gets considered 'dirty' by the ORM (unless it is explicitly set in the vals), and when the `account.move.line` tries to set-up its date, which is related to the move, the compute method for the date is triggered as the field was flagged as dirty.

opw-4662209

Forward-Port-Of: odoo/enterprise#83870

The error occurs when attempting to add a date in line in the Salary Rule Parameters Steps to Reproduce: --- - Install the `hr_payroll` module - Payroll > Configuration > Rule Parameters - Create New > History > Add a Line > Add Date Traceback: --- AttributeError: 'bool' object has no attribute 'replace' At [1], this error occurs because `value_id.parameter_value` is False. This happens because first we're adding a date, so `value_id.parameter_value` is initially empty. [1]- ht

The error occurs when attempting to add a date in line in the Salary Rule Parameters

Steps to Reproduce:
---
- Install the `hr_payroll` module
- Payroll > Configuration > Rule Parameters
- Create New > History > Add a Line > Add Date

Traceback:
---
AttributeError: 'bool' object has no attribute 'replace'

At [1], this error occurs because `value_id.parameter_value` is False. This happens because first we're adding a date, so `value_id.parameter_value` is initially empty.

[1]- https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/hr_payroll/models/hr_rule_parameter.py#L101-L102

sentry-6531613276

Forward-Port-Of: odoo/enterprise#83224

`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257 Forward-Port-Of: odoo/enterprise#83667 Forward-Port-Of: odoo/enterprise#83665

`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access.

So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged.

https://runbot.odoo.com/odoo/error/162257

Forward-Port-Of: odoo/enterprise#83667
Forward-Port-Of: odoo/enterprise#83665

These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635 Forward-Port-Of: odoo/enterprise#83676 Forward-Port-Of: odoo/enterprise#83672

These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default.

https://runbot.odoo.com/odoo/error/163635

Forward-Port-Of: odoo/enterprise#83676
Forward-Port-Of: odoo/enterprise#83672

**Before this PR:** The Share panel is not accessible to portal users, but the Share button is still visible to them. **After this PR:** The Share button will no longer be visible in the portal view. Task-4717553 Forward-Port-Of: odoo/enterprise#83306

**Before this PR:**
The Share panel is not accessible to portal users, but the Share button is still visible to them.

**After this PR:**
The Share button will no longer be visible in the portal view.

Task-4717553

Forward-Port-Of: odoo/enterprise#83306