#### [FIX] account_peppol: disallow disabling services
Currently it is possible to disallow any services in the configuration.
This can lead to complicance issues; i.e. if someone disables "BIS Billing 3.0".

1. Ensure Peppol is activated (test mode or production; not demo)
2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Configure Peppol Services
3. Any service can be disabled.

This commit hides the button to open the service wizard.
(Also in the wizard it is now not possible to disable services anymore.)

#### [FIX] account: generation of print-related entries in cog menu
Before this commit:
The dynamic generation of the print related entries in the cog menu
does not work correctly.

Problem / Solutions:
There is a check in the javascript that does not work as intended.
Thus the entries are not added to the cog menu in all cases.
The check was intended to only block it for "new" records (not saved yet);
to avoid issues in case the move has no id yet.
After this commit we just check the id directly.

#### [FIX] account_edi_ubl_cii: missing parenthesis in invoice_edi_format
Follow-up to commit 860c0974f9b541be63f4079ef52366f91c1994ce .
There we improved the eInvoice format labels for clarity.
But 2 label were formatted differently than the others.
This commit fixes that.

#### References
task-4737164

Forward-Port-Of: odoo/odoo#233629
Forward-Port-Of: odoo/odoo#233382

**Description of the issue/feature this PR addresses:**

When a user has deleted the Odoo Oauth provider, an error occurs when restoring the database. 

**Current behavior before PR:**

You'll get this error:

```
odoo.service.db.restore_db(dbname, backup, copy, **extra_kwargs)
File "<decorator-gen-27>", line 2, in restore_db
File "/opt/ou/odoo/odoo/service/db.py", line 44, in if_db_mgt_enabled
return method(self, *args, **kwargs)
File "/opt/ou/odoo/odoo/service/db.py", line 360, in restore_db
env['ir.config_parameter'].init(force=True)
File "/opt/ou/odoo/addons/auth_oauth/models/ir_config_parameter.py", line 13, in init
oauth_oe = self.env.ref('auth_oauth.provider_openerp')
File "/opt/ou/odoo/odoo/api.py", line 611, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2059, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "/opt/ou/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2052, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: auth_oauth.provider_openerp
Error: External ID not found in the system: auth_oauth.provider_openerp

```

**Desired behavior after PR is merged:**

No error will occur

The afflicted versions are AFAIK, **16.0**, **17.0**, **18.0**, and **19.0**


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

Forward-Port-Of: odoo/odoo#233633

Issue
-----
After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity.

Steps to reproduce
-----
- Unarchive MTO route
- Create a stored product
	- Routes MTO & Manufacturing
	- Empty BoM
- Create a Sale Order for 3 units of the product & confirm it
- Go to the linked MO and split it in 2 (quants of 1 and 2)
- Confirm both MOs (and produce)
- Go to the sale's delivery
> The delivery's move only shows 1 unit of the product

Why the move quantity is only 1
-----
After confirming the first of the 2 backorder productions, when we manufacture the product, we go through

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054

Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

Which creates a SML for the delivery move when reserving it

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971

This in turn triggers the computation of the move's quantity since it depends on the move's lines

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383

Our move ends up with a quantity of 1.

When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

This means we don't create a new SML for the delivery move, so the quantity stays at 1.

Why there is no move_dest_id
-----
When splitting the production, we go through

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829

We create new a MO and SM for the backorder. The SM is created here

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915

When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656

So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78

In the write, we get to a line where we access the production's state

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931

This triggers a recompute of the field.

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552

In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800

The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f).

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167

-----
Ticket:
opw-4865082

Forward-Port-Of: odoo/odoo#233114
Forward-Port-Of: odoo/odoo#223792

Currently POS crashes with the Italian localization if they delete a product line.

Steps to reproduce:
-------------------
* Install l10n_it_pos and switch to the IT company
* Create a pos and configure Italian printer
* Open shop
* Add a product to cart
* On the numpad try deleting the line
> Observation, pos crashes

Traceback: TypeError: Cannot read properties of undefined (reading 'tax_details')

Why the fix:
------------
When first hitting the delete button we will put the price unit to 0. With that we have
```
const reduced_base_lines = Object.values(base_line_map).filter( (base_line) => !floatIsZero(base_line.price_unit, base_line.currency_id.decimal_places));
```
returning an empty list. Utlimately making `reduce_base_lines_to_target_amount` return an empty list. `[][0]` returns `undefined` and we were passing `[undefined]` in parameters of `fix_base_lines_tax_details_on_manual_tax_amounts`, we enter the loop with undefined and try to access some variables.

We also set `l10n_it_epson = False` in order to avoid recursively looping.

opw-5184113

Forward-Port-Of: odoo/enterprise#98229

Issue:

In this bug, workorder duration inverse is causing some time_ids to be deleted.

To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
   - First one 10:00 -> 12:00
   - Second one 10:00 -> 11:00
    
5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked

Cause:

The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.

To be specific this is the compute function override:
https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766

In which duration is calculated using get_duration:
https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837

Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.

However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400

As a result, if time_ids overlap:
new_order_duration < old_order_duration

As a result some time_ids will be unlinked and some will have duration changed.

Fix:

Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```

As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899

The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.

In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.


opw-5082477

Forward-Port-Of: odoo/odoo#230328

#### Issue:

In this bug, workorder duration inverse is causing some time_ids to be deleted.

To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
   - First one 10:00 -> 12:00
   - Second one 10:00 -> 11:00

5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked

#### Cause:

The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.

To be specific this is the compute function override: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766

In which duration is calculated using get_duration: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837

Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.

However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals: https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400

As a result, if time_ids overlap:
new_order_duration < old_order_duration

As a result some time_ids will be unlinked and some will have duration changed.

#### Fix:

Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```

As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899

The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.

In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.

However, this might cause another issue:
If `order.duration` is not computed yet, and inverse method `_set_duration` is called, then `get_duration` inside `_set_duration` will be called before the `get_duration` in compute method. As a result there might be a small unexpected time difference between `old_order_duration` and `new_order_diuration`. To avoid that inside `get_working_duration` we can use cursor now instead:
```diff
+ now = self.env.cr.now()
- now = datetime.now()
```

opw-5082477

Forward-Port-Of: odoo/enterprise#96632