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

Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels and Export Documents
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Set up commercial invoice (/invoice) to be sent to another printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Validate the delivery
> Observation: Nothing prints, jobs are sent to CUPS bu not printing

Why the fix:
------------
https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196

As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message.

In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46

Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing.

Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message.

opw-4546715

Forward-Port-Of: odoo/enterprise#83481
Forward-Port-Of: odoo/enterprise#82094

**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

### Step to reproduce:

- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
    - 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units

### Cause of the issue:

When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case  there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.

opw-4562965

Forward-Port-Of: odoo/enterprise#83555
Forward-Port-Of: odoo/enterprise#81818

Issue -->

When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search.

Solution -->

Move the `qty_to_order <= 0` check after the search produces a recordset for `("trigger", "=", "manual")`. This avoids unnecessary computations.

Benchmarks -->

For this benchmark, we'll assume the worst case, where every orderpoint on the database has trigger set to `auto`. The number of seconds represents the time taken to open the Replenishment view. 

| # of auto trigger orderpoints | Before | After |
|--------|--------|--------|
| 12.2k | 155.58 s | 4.49 s |
| 6k | 59.87 s | 3.78 s | 

opw-4606704

Forward-Port-Of: odoo/odoo#203182

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

Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request.
This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test.

Checking the logs:

2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow
2025-04-11 04:56:57,155 13 INFO 78181121-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /test_sale_product_configurators/tests/test_sale_product_configurator.py:TestProductConfiguratorUi.test_02_product_configurator_advanced

That indicates that we are in the case where the request don't have a cookie, despite the route being called from a chrome.

It is most likely due to the fact that the browser cookie are cleared at the end of a browser js call, before navigating to about:blank

2025-04-11 04:56:57,119 13 INFO 78181121-16-0-all odoo.addons.test_sale_product_configurators.tests.test_sale_product_configurator.TestProductConfiguratorUi: Deleting cookies and clearing local storage

It is actually easy to reproduce by adding a sleep before navigating to about:blank in browser.clear(). We can see that the websocket route is still called periodically at the end of a test. This error will occur when this request is made just between
the cookies are cleared and the page navigates to about:blank.

One possibility is to avoid to clear the cookie since the user profile is deleted after the browser is stopped, but unfortunately in this version the browser is kept between tests of the same class.

It is maybe not sufficient but navigating to a blank page before removing the cookies should reduce the possibility of having a request without cookie reaching the server. In this case a sleep after about:blank, before clearing the cookie shows that we don't have repeated call to /websocket anymore.

Another possibility is to check if the request is a websocket request and to not open a cursor in that case if we don't have a cookie identifying the test. This cannot be done for all requests since it is possible that some call are made when generating a pdf, or any call that would open a TestCursor without being inside a browser_js or url_open

Combining both solution should hopefully highly reduce this error. 

A final decision was made to also forbid any request coming after a browser_js.
- browser_js is the main source of request reaching the server asynchronously. Other ways to create a request on the server is synchronous with the test and will wait for the result.
- After a browser js, it is unlikely to make another request outside an url_open or browser_js. It was the case for some xmlrpc requests, the dirty solution was to make the test non strict during this request. Those tests could still be a small cause of randomness.

Note: The explicit deletion of the session cookie is also removed, it is not  needed since all cookies are cleared just after, and having a request that could reach the server without session cookies feels a little like a good solution to have random access error.

Forward-Port-Of: odoo/odoo#206933
Forward-Port-Of: odoo/odoo#206006

### Steps to reproduce:
	- Create a leave type that creates timesheet
	- Create a leave for a flexible employee for 4 days
	- Check the timesheet created for this leave
	- Notice the amount of this timesheet is 83 hours not 32

### Cause:
When creating a timesheet or a work entry for a leave we get the difference between the start and the end date in milliseconds and divide it by 3600 to get the hours.

Timesheet:

https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_mixin.py#L208-L213

Work entry:

https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L522-L525

This doesn't work for flexible hours as when fetching attendance intervals for flexible employee we return one big block for the whole period as there is no attendance intervals for the flexible employees.

https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L370-L376

### Fix:
When fetching the attendance intervals for flexible employee we return the hours per day as duration hours not the diff between the start and the end date of the period. We only use the diff between the dates in case of fully flexible. Then we use this duration hours in timesheet and work entry creation

opw-4628296

Forward-Port-Of: odoo/odoo#207299
Forward-Port-Of: odoo/odoo#206252

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