sale_renting_planning: fix shift state after creating rental order
--------
**Steps to Reproduce:**
Create a shift in Planning.
Click New Order.
Save and confirm the rental order.
Check the shift in Planning it is still in draft.

**Issue:**
The shift stays in draft even after the rental order is confirmed.

**Cause**
When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status.

**Fix:**
Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button.

 sale_renting_planning: fix access error on clicking new order button
----------------
steps to reproduce:
user has no sale access (only planning access)
create a new shift
click on 'New Order' or 'ADD to Last Order' button
access error occurs

cause:
the 'New Order' and 'Add to Last Order' buttons were visible to users without
sales access rights.

issue:
The buttons open the sale order form view, but users without sales access cannot
read sale orders data, resulting in access errors.

fix:
Hide both buttons for users who do not have sale access rights.
task-5075839

Forward-Port-Of: odoo/enterprise#112373
Forward-Port-Of: odoo/enterprise#99642

*: stock_barcode_mrp, stock_barcode_picking_batch

## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.

## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
     - Delivery Orders.
     - Manufacturing Orders
     - Batch Pickings
     - Inventory Count
- From any of these open a record
  (e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.

## Cause of the Issue:
- When switching views inside the Barcode client action,
  the FormController calls `setDisplayName(this.displayName())`.
  In some cases, this returns an empty string, overwriting the
  previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
  preventing the controller from retrieving a proper name.

## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.

TaskID: 4978997

Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165

**Issue**:
Even if the currency rate is changed on the invoice, the today currency rate is used
while generating stock landed cost.

**Steps to reproduce**:
- Enable two currencies (ex: Dollar and Euro)
- Enable Landed Costs on the settings
- Create a service product
- Create a bill for that product for 100 dollar and click the Landed Costs check box
- Change the currency rating (ex: 1 USD = 0.5 euro) and confirm the bill
- Click on "Create Landed Costs"
-> The cost is not 200

**Cause**:
While creating the landed cost:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L21
it uses `_convert` from the currency:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L35
which gets the `conversion_rate` defined on the currency, regardless whether `is_invoicing` is true:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/odoo/addons/base/models/res_currency.py#L294
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move.py#L6350-L6351

**Solution**
It is safe to replace the `convert` calls by the `currency_rate` of the `Account.move.line` since:
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move_line.py#L735-L747
`currency_rate` will be set as `_get_conversion_rate` when not invoicing.
Also add rounding since `_convert` is called with `round=True` by default.

opw-6047031

Forward-Port-Of: odoo/odoo#256394

Issue:
Export XML button doesn't produce the same file as the send button.

Steps to reproduce:
- Company in Spain with Peppol (work with any Peppol country)
- Partner in Croatia
- Select eInvoice Type as "EU Standard (Peppol Bis 3.0)"
- Create an invoice
- Confirm it
- Click on the Wheel -> Download

Current behavior:
- without l10n_hr_edi: only "PDF" and "PDF without Payment"
- with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file

Cause:
"Export XML" button appear only if:
- there is a default ubl option for the partner country
- there is an XML attached to the invoice when clicked it exports the corresponding one.

Whereas, the 'send' button rely on:
1) the partner defined edi format,
2) the default ubl option for the partner country
3) "ubl_bis3"

To be noted:
The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice.

opw-5943500

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

Forward-Port-Of: odoo/odoo#253650

# How to reproduce
- Install the eLearning module
- Log in as a portal user
- Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course)
- Go to Courses > View your profile (on the right side) > Edit Profile
- Edit any value and confirm by clicking on the Update button

# The problem
The popup is not saved and a warning notification is displayed with : "You are not allowed to modifiy 'User' (res.users) records"

# Why
In 19.0, there was no access rights problem because the write operation was done in `sudo` due to this code that checked that every edited field was safe :

https://github.com/odoo/odoo/blob/4f77b4c8f7a3ee9f85f045eea02a5749affd4b6a/odoo/addons/base/models/res_users.py#L615

This was the case because we preventively filtered only the safe fields in the save controller :

https://github.com/odoo/odoo/blob/355643291e2f4bb05185b996adce6e1f403ecbd4/addons/website_profile/controllers/main.py#L153

In 19.1 though, this commit totally changed the way the acces rights for the fields of the user model were handled :

https://github.com/odoo/odoo/commit/a816d151ae16afc62d7980cedc492942bc181884

One of the purpose of this improvement was to make sure a `sudo` is not automatically introduced and rather should be done explicitely when it is needed.

# Proposed solution
We first check that the current user can modifiy the specified user. If that is the case, we write with `sudo`

opw-6032339

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

### Steps to reproduce:

- Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`)
- Create + confirm a purchase order for 1 unit of the kit product at 60
- Validate the delivery

#### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10

There are two issues with purchased kit valuation addressed in this PR:

### Issue 1:

Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38

This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented  as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share:
https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48

### Fix of this issue:

We set the digits to `False` for stability reason as the columns have 
been initiallised as "numeric" values and needs to stay numeric:
https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650

Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end:
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76
https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227

In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`.

### Issue 2:

While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30

Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit).

### Fix of this issue:

We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore).

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

Forward-Port-Of: odoo/odoo#253734
Forward-Port-Of: odoo/odoo#252034