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

### 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#80909
Forward-Port-Of: odoo/enterprise#79591

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

When we create a public root, we do:
- Create env
- Wait for services to load
- Create `MainComponentsContainer`

In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already
 available. The problem with the lazy loading chatter bundle is that one of the
 services in the second step is responsible for loading that bundle. So while
 the lazy bundle is loading, new services and main components are being added to
 the registry.

The steps become like this:
- Create env
- Wait for services to start
- Start loading chatter bundle
- Lazy services (from chatter bundle) are not yet completely started
- A main component from lazy bundle is added to the registry (in this case ChatHub) => crash
- Lazy services are completely started

Steps to reproduce:
- Install a module that has portal chatter for example sales
- Go to the portal page of a sale order
- Error: `service mail.store is not available`

This PR defines a new service for each main component to ensure that main components are registered when their dependent services are deployed.

runbot-116358
task-4642192

Related to: odoo/odoo#201504

Forward-Port-Of: odoo/enterprise#81327

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