### Steps to reproduce:

- In the settings enable purchase > dropshipping
- Create a new user "BOB". Enable debug mode and set it as a portal user. Note: you can click on the wheel to change its password.
- Create a product FP tracked by SN, "BOB" as vendor and a bom of type subcontracting: 1 x COMP (tracked by SN), subcontracted by "BOB"
- On COMP, check the routes "Buy" and "Dropship Subcontractor on Order" and set a vendor price list.
- Create and confirm a purchase order for 2 units of FP for BOB
- A dropship Purchase Order is created for 2 units of COMP > confirm it
- In the Portal view, as BOB, return to the MO related to FP
- Click on the "burger" icon of the move and try to change the qty_producing or set a SN for the finished product.
#### > you trigger and access right error.

### Cause of the issue:

Changing the qty_producing or the serial number of the finished product triggers a call of the `_set_qty_producting`:
https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L793-L796 During this call, the pickings linked to the MO will be fetchded to determine if the MO is waiting for components to arrive or if the reservation can already be done.
https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L1223-L1224 However, the portal user does not have the access right to read this record and you are not saved by the `Stock Pickings Subcontractor`, `ir.rule` as this is a dropdhip.

### Note:
It was not possible to trigger the issue in 17.0 because prior to: https://github.com/odoo/odoo/blob/5fb046e7278778cdbefe179d3258a7185a03a1b8/addons/mrp/models/mrp_production.py#L466 The dropshipping picking was not linked to the MO and hence we didn't try to access the values of any record we didn't have access to.

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

Forward-Port-Of: odoo/odoo#198814

*: portal, website, web_editor

Enhance user experience by resolving UI inconsistencies and ensuring readability and contrast between the dropdown active / hover states and their inner text. 

**Global**
 - Updated hover effects to use `body-tertiary-bg` instead of `gray-100`, aligning with Bootstrap 5.3's styling approach.
- Added color-contrast function's variables to allow easier use in `bootstrap_overridden_frontend`

**Dropdowns**
- Adjusted active state colors to prevent conflicts between the primary active color and dropdown item text color.
- Differentiate two active states: 
  - Active menu entries (current page) ➡️  Primary color
  - Active feedback on click ➡️  color-contrast of background color
- Updated the `o_extra_menu_items` dropdown to adapt the borders to the user theme settings, removing the hardcoded `gray-200` value.

**Search & Misc**
 - Replaced `-webkit-search-cancel-button` with Bootstrap's `btn-close` design introducing a mixin for contextual color adjustments to match the input color.
- Changed portal search input type from `text` to `search` ensuring proper styling and semantic.

task-3969685

| Before | After |
| --- | --- | 
| ![image](https://github.com/odoo/odoo/assets/118886338/aae9ce72-62e9-44a9-87de-8914bd06bb7a) |  ![image](https://github.com/user-attachments/assets/1bb428b9-1d22-4607-9d2d-9abfb87ba311) |
|![image](https://github.com/odoo/odoo/assets/118886338/ed891c37-11bd-4f69-82a2-45d4a235abd1) | ![image](https://github.com/odoo/odoo/assets/118886338/89db4343-9042-43c8-a338-e2f1f50e7b54) |
| ![image](https://github.com/odoo/odoo/assets/118886338/ae95a96c-8243-46f7-981e-dcc0b1f63e43) | ![image](https://github.com/odoo/odoo/assets/118886338/c8c24097-8e6b-47d5-a0bc-aff3c3841a73) |




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

Forward-Port-Of: odoo/odoo#201351
Forward-Port-Of: odoo/odoo#170922

Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems.

First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network.

Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was already processed by the model (i.e. the tag is no longer in the list), but the DOM wasn't updated yet. This could be done more easily then it sounds, by quickly pressing backspace on a many2many_tags with a lot of tags.

The related opw is about the second issue, as the first one isn't obversable functionally. However, testing the second one is really tricky, even impossible without going white-box. We thus wrote a test for the first issue only, as the fix for both is actually the same.

opw-4596936

Forward-Port-Of: odoo/odoo#201667
Forward-Port-Of: odoo/odoo#201164

When importing an xml invoice, we display a generic
error in case of Exception. This is useful from a technical point
of view but this is obscur for the user.
With this commit, in case of a UserError, we add the
error message in the chatter.

Let's assume a wrong configuration and steps like this:

- Belgian demo company, `account_peppol` installed and activated
- Make sure there are no moves in `Vendor Bills` journal
- On the account 600000, set `Allowed Journals` to be any journal
  different from `Vendor Bills`
- From the journal dashboard, vendor bills journal, click on
  `Fetch from peppol`, then go to the bil that has been created
-> In the chatter you will see the error message:
	"Error importing attachment '2_demo_vendor_bill' as invoice (decoder=_import_invoice_ubl_cii)"

This is because we raise the constrains
`account_move_line._check_constrains_account_id_journal_id`, but the
user will never know until we display the UserRrror message in the
chatter.

opw-4513344

Forward-Port-Of: odoo/odoo#201566
Forward-Port-Of: odoo/odoo#200694

…CIG or CUP is present

**Issue:**
When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the e-invoice to the tax agency, even though the data is incomplete.

**Steps to Reproduce:**
1. Install the Accounting app
2. Install the l10n_it_edi module
3. Navigate to Accounting > Customers > Invoices
4. Select or create an invoice
5. Choose a customer with a PA index
6. Open the Electronic Invoicing tab
7. Fill in either the CIG or CUP field, but leave the Origin Document Type empty
8. Click Send & Print
9. No error is displayed and the e-invoice XML can be sent

Expected Behavior: An error should be triggered, preventing the e-invoice from being sent if the Origin Document Type is missing, even when only one of CIG or CUP is present.

Actual Behavior: The system allows sending the e-invoice despite missing critical information, leading to incomplete data submission.

**Root Cause**

The existing validation only checks if both CIG and CUP are missing, but it does not account for cases where only one is filled while the Origin Document is still absent.

**Fix**
The condition has been updated to trigger an error whenever the Origin Document Type is missing, even if only one of CIG or CUP is present.

Opw-4590205

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

Forward-Port-Of: odoo/odoo#198758

Before this commit, when opening and closing emoji picker quickly, it could crash with the following error:

```
TypeError: Cannot read properties of null (reading 'querySelector')
```

Steps to reproduce:
- Open website editor
- Add a new content block
- In content block, add banner with `/banner`
- spam click quickly on the banner icon

This happens because when clicking very quickly on emoji picker button, the `EmojiPicker` component is in a mounted state and the `gridRef.el` is undefined, thus resulting in the crash when attempting `gridRef.el.querySelector`

The grid has no reason to not be in the template. However, the `useRef()` has a special check to determine whether the ref is attached to DOM, and when not then it returns `null`. The website editor uses web editor, which itself mount the emoji picker in a popover. The click handler closes the popover if it was open and re-opens the emoji picker. Close of popover, when too fast, results to destroying popover before the emoji picker, which detaches the emoji picker from DOM, therefore all refs are `null`. The `EmojiPicker` is about to be destroyed, but for a fraction of time it can re-render itself and access to null refs.

Emoji picker relies heavily on template to model its matrice of emojis for keyboard navigation and managing overflow of
the category navbar. That's why mounting the emoji picker results to 2 renderings. Because of quick mount/unmount, overlay and double rendering of emoji picker, all this puts sometimes the emoji picker in a case of being status "mounted", in a fragment, and calling useEffect to set the active emoji in the grid. This requires `gridRef.el`, which is unfortunately `null` because of being in fragment, thus leading to the crash.

This commit fixes the issue by making the code more defensive against `gridRef.el` not be set, to tackle the case the component is in a fragment while it's being unmounted. `navbarRef.el` could also be `null` for a similar reason but instead of useEffect this is triggered from ResizeObserver.

Forward-Port-Of: odoo/odoo#201452

In [1] when the web client was rewritten in OWL, the `noContextKeys` parameter behavior was lost (only the `shadow` `settings` was used). In [2] the `_rpc` was overridden, losing the `noContextKeys` parameter.

Because of each of these, even though the HTML Editor always fetched a `en_US` version of the page for edition, upon save, the current user's language was being used upon save, leading to the loss of translations.

This commit fixes the issue by removing the mentioned keys from the context in the `legacyEnv.session.rpc` rather than getting rid of that parameter completely because since [3] the user context is always included in the rpc context - which would restore the language.

Steps to reproduce:
- Set user's language to Dutch.
- Add Dutch as the default language of a website.
- Create a new Dutch page.
- Drop an accordion snippet.
- Switch website preview to English.
- Translate the first title.
- Save.
- Edit the page with the HTML Editor (English version is edited).
- Make some minor change, even adding a space is enough.
- Save.

=> Dutch text was lost and replaced by the last saved version.

[1]: https://github.com/odoo/odoo/commit/0573acae2306bf5da2005852da9323ddc59e5431#diff-851c304e3f2a64138c1ff0f3de9856184dbfa0114da3fd76af0309eabe72043eR134
[2]: https://github.com/odoo/odoo/commit/55f1680c74d3b64c3319ba114f7ba3e3f7b49be3
[3]: https://github.com/odoo/odoo/commit/2192480ed1262a13db8e6b0dd945ea91dee91aa9

opw-3493355

Forward-Port-Of: odoo/odoo#201306
Forward-Port-Of: odoo/odoo#142894

### Issue: 

MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split.

### Steps to reproduce:

- Create 2 storable products tracked by SN: FP and COMP
- Create a BOM for you final product FP:
    - 1 x COMP
    - 1 operation with an instruction of type "Register Consumed Materials" for COMP
- Put 2 serial numbers in WH/Stock for COMP: SN01, SN02
- Create and confirm an MO for 2 units of FP using that BOM
> SN01 and SN02 should be reserved on the move raw
- Go to the shopfloor to the MO
- Click on Register component SN02 > Validate
- Click on the [+] button of the register Production
- Mark the MO as Done > Close Production
> You trigger a consumption warning dialog telling you that you registered more consumed quantity than expected (2 instead of 1) This dialog should not appear in the first place as you registered only 1 unit but suppose it is ok and continue
- Click on "Set quantities and validate"
- Go back to your MO in the back end
#### > It was closed using SN01 rather than the SN you registered.

### Cause of the issue:

Confirming the MO confirmed the move raw and a reservation was made for 2 units as the MO is not splitted yet. However, since the final product is tracked this MO will end up splitted. When you register consumption, the serial number of one of the move line related to the raw move will be updated and the line will be picked:
https://github.com/odoo/enterprise/blob/d4ff42fbcfa3dd297c6cb838b5b03955f12f02a4/mrp_workorder/models/quality.py#L519-L525 However, since at least one of the move line of the move raw is picked the move its self will become picked:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L208-L212 This is problematic as picked picked move by pass the set_qty_producing so from now if you were to adapt the qty producing of the MO you would not affect the quantity of the raw move (which is currently at 2: one unpicked move line with SN01 and one picked with SN02): https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1218-L1228 Finally, when you click on the Close production, a `_split_productions` process will be started and adpat the demand of the move raw to 1: https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1831-L1832 Since the quantity set on the move exceeds this new demand the consumption warning. Note that at this point the backorders of the initial MO were already created and confirm without you dialog to be resolved so that the reservations of these splitted MO could not reserve the SN01 that is still used by your move. Finally, when you "Set quantities and validate" it will adpat the quantity and unreserve the picked move line as this decrease process does not prioritise to unlink unpicked move lines first:

### Fix:

Since registration process through shopfloor and barcode are expected to create picked move lines which will adpat the picked state of the move and since picking the move will automatically pick all the move line, a move line that is not picked in a picked move is a move line that is not expected to be kept. We therefore unlik these move_lines before adapting the demand of the move_raws in the split production.

### Note:

We also tried 2 other fixes of the issue but aborted these other ideas: 
1) try to keep only picked move line at the Validation of the registration component process but this change of behavior was aborted since if instead of clicking on validate you click on "Continue consumption and then on the top right cross button", you would technically have registered only the first SN but you would fall in the situation as above and trigger the same issue.
2) Adapt the condition of that makes a move raw by pass the _set_qty_producing:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1219-L1221 Since the move is picked for the wrong reason we would instead use: `all(ml.pikced for ml in move.move_line_ids)`
However, this would also require to change the process decrease to unreserve picked move last here:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L361-L365 Changing the loop to
`reversed(move.move_line_ids.sorted(lambda ml: (not ml.picked, ml.id))` And this would not solve the issue starting post 17.0 since we would still bypass the set_qty producing on the next lines:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1223-L1225

Enterprise: https://github.com/odoo/enterprise/pull/79591

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

Forward-Port-Of: odoo/odoo#198599
Forward-Port-Of: odoo/odoo#198175

Steps to Reproduce:
	1.	Create a storable product with inventory tracking and assign a barcode.
	2.	Create an internal transfer from “Partners/Customers” to “Virtual Locations/Inventory Adjustment”.
	3.	This will generate two quants, one in Customers and another in Inventory Adjustment.
	4.	Navigate to Barcode > Inventory Adjustment and scan the product’s barcode.

Issue:

The scan triggers an inventory adjustment for the “Customer” location instead of the correct stock location.

Technical Explanation:
	•	The system fetches all quants related to the product, including those in Vendor, Customer, and Inventory Adjustment locations.
	•	These locations have IDs lower than the stock location (e.g., Customers = 5, Stock = 8).
	•	The front-end caches this data (dbIdCache) and calls _defaultLocation() to determine the location.
	•	Since the cache is ordered by ID, the first location (Customers, ID 5) is incorrectly selected instead of the stock location (8).
	•	As a result, the inventory adjustment is applied to the wrong location.

Proposed Fix:
	•	Filter the results to include only internal locations when fetching quants.
	•	This prevents non-internal locations (Vendor, Customers, Inventory Adjustment) from being selected by default.
	•	If a user needs to adjust inventory for an external location, they must first scan the location barcode before scanning the product.

Task-4596699

Forward-Port-Of: odoo/enterprise#81398
Forward-Port-Of: odoo/enterprise#81107

Steps fo reproduce :
- create a product (in the inventory tab, the route should be 'Manufacture')
- click on the smart button 'bill of materials'
- create a BOM for this product with at least one operation
- in the quality app navigate to Quality Control/Control Points
- create a new control point
- in the field product select the product that you created
- in the operations field select "YourCompany: Manufacturing"
- in the work order operation field select the operation that you wrote in the BOM you created (if multiple operations with the same name make sure that you selected the one linked with the BOM)
- in the type field select "Measure"
- in the norm field enter a unit of measure with at least an upper case
- create a manufacturing order for this product
- open the shop floor app and on the manufacturing order you created select the quality check point

Current Behavior:
The unit of measure appears in lower case. This could change its meaning for instance form MW (mega-watt) to mw (mili-watt)

Expected Behavior:
The unit of measure string should respect the letter case wrote by the user

Cause of the issue:
In the xml file, inside the <span> tag the class was "text-lowercase"

Fix:
I removed this class from the span

https://github.com/odoo/enterprise/blob/43e7aec36ddee8a3ff3de8793427a183dfd29b30/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.xml#L47

opw-4584509

Forward-Port-Of: odoo/enterprise#81274

**Steps to reproduce:**

1.Go to Documents > Configuration > Settings:
  -Enable Accounting (Centralize accounting files and documents)
  -Open Journals and synchronize a chosen journal with a workspace 
2.Create a new activity type with:
        `action`: `Upload Document`
        `folder_id`: The same workspace we set in the settings 
3.Create a journal entry in the journal you chose
4.Add the new activity to the journal entry.
5.Upload a document.

**Issue:**
The attachment is uploaded, but we get a Missing Record error for an `ir.attachment` record, and the activity isn't set to done

**Cause:**
This commit was meant to prevent this issue: https://github.com/odoo/enterprise/commit/6c4bbf2fe0577fe1f4fc9f6a408c5904eb1cf92b

What it is meant to do is to add a `no_document` flag to prevent the creation of two documents when an attachment is uploaded to an activity, since the second one will by unlinked, along with the attachment. See:
https://github.com/odoo/enterprise/blob/a46594b2d3529d86a40a1567e0e4e0207399a3a8/documents/models/mail_activity.py#L41

But a particular case was not included:
  - if the attachment fits at least one of these criteria:
        - attachment of a misc operation
        - first attachment of an invoice
        - xml file after it has been succesfully registered as move attachment
  - if the journal in which the entry was created is synchronized with the activity's workspace

In this case, a second document is created, since we don't check for the flag `no_document` in this flow.

see:
https://github.com/odoo/enterprise/blob/28b6a5d30274f4265c978433b8d02b758d9a032e/documents_account/models/ir_attachment.py#L24

and:
https://github.com/odoo/enterprise/blob/85c139237015a7c3f1233eb9d977ead126b7d7d6/documents_account/models/account_move.py#L87

**Solution:**
Added a check for the `no_document` flag before calling `_update_or_create_document`

opw-4547561

Forward-Port-Of: odoo/enterprise#80662

To reproduce:
- Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation.
- Enable packages in inventory settings.
- New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg).
- Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg).
- Validate the picking.

Current behaviour:
Crashes when trying to create the return label with nondescript error coming from FedEx.

Expected behaviour:
Ideally, a correctly validated picking with generated return labels. However, this appears to currently not be supported by the FedEx REST API... (multi-package single-shot return shipments of print label type)
We compromise and will create the outgoing shipment as usual, but not the return shipment in case of multi-package shipments. A helpful message informing the user of this limitation will be put in the chatter of the picking instead of the generated return label in this specific case.

opw-4556415

Forward-Port-Of: odoo/enterprise#81326

### Issue: 

MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split.

### Steps to reproduce:

- Create 2 storable products tracked by SN: FP and COMP
- Create a BOM for you final product FP:
    - 1 x COMP
    - 1 operation with an instruction of type "Register Consumed Materials" for COMP
- Put 2 serial numbers in WH/Stock for COMP: SN01, SN02
- Create and confirm an MO for 2 units of FP using that BOM
> SN01 and SN02 should be reserved on the move raw
- Go to the shopfloor to the MO
- Click on Register component SN02 > Validate
- Click on the [+] button of the register Production
- Mark the MO as Done > Close Production
> You trigger a consumption warning dialog telling you that you registered more consumed quantity than expected (2 instead of 1) This dialog should not appear in the first place as you registered only 1 unit but suppose it is ok and continue
- Click on "Set quantities and validate"
- Go back to your MO in the back end
#### > It was closed using SN01 rather than the SN you registered.

### Cause of the issue:

Confirming the MO confirmed the move raw and a reservation was made for 2 units as the MO is not splitted yet. However, since the final product is tracked this MO will end up splitted. When you register consumption, the serial number of one of the move line related to the raw move will be updated and the line will be picked:
https://github.com/odoo/enterprise/blob/d4ff42fbcfa3dd297c6cb838b5b03955f12f02a4/mrp_workorder/models/quality.py#L519-L525 However, since at least one of the move line of hte move raw is picked the move its self will become picked:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L208-L212 This is problematic as picked picked move by pass the set_qty_producing so from now if you were to adapt the qty producing of the MO you would not affect the quantity of the raw move (which is currently at 2: one unpicked move line with SN01 and one picked with SN02): https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1218-L1228 Finally, when you click on the Close production, a `_split_productions` process will be started and adpat the demand of the move raw to 1: https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1831-L1832 Since the quantity set on the move exceeds this new demand the consumption warning. Note that at this point the backorders of the initial MO were already created and confirm without you dialog to be resolved so that the reservations of these splitted MO could not reserve the SN01 that is still used by your move. Finally, when you "Set quantities and validate" it will adpat the quantity and unreserve the picked move line as this decrease process does not prioritise to unlink unpicked move lines first:

### Fix:

Since registration process through shopfloor and barcode are expected to create picked move lines which will adpat the picked state of the move and since picking the move will automatically pick all the move line, a move line that is not picked in a picked move is a move line that is not expected to be kept. We therefore unlik these move_lines before adapting the demand of the move_raws in the split production.

### Note:

We also tried 2 other fixes of the issue but aborted these other ideas: 
1) try to keep only picked move line at the Validation of the registration component process but this change of behavior was aborted since if instead of clicking on validate you click on "Continue consumption and then on the top right cross button", you would technically have registered only the first SN but you would fall in the situation as above and trigger the same issue.
2) Adapt the condition of that makes a move raw by pass the _set_qty_producing:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1219-L1221 Since the move is picked for the wrong reason we would instead use: `all(ml.pikced for ml in move.move_line_ids)`
However, this would also require to change the process decrease to unreserve picked move last here:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L361-L365 Changing the loop to
`reversed(move.move_line_ids.sorted(lambda ml: (not ml.picked, ml.id))` And this would not solve the issue starting post 17.0 since we would still bypass the set_qty producing on the next lines:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1223-L1225

Community: https://github.com/odoo/odoo/pull/198175

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

Forward-Port-Of: odoo/enterprise#80821
Forward-Port-Of: odoo/enterprise#79591