Description of the issue/feature this PR addresses:
In odoo V17 if a user is creating a holiday request for a time of type that requires no validation, the confirm button is visible during the creation process due to this line https://github.com/odoo/odoo/blob/2876b8300d1f9a740deb0faa02399df2426df402/addons/hr_holidays/views/hr_leave_views.xml#L248

in prior versions this was not the case

https://github.com/odoo/odoo/blob/391a427620b6aec690481fe7c7d0b0326b95ee8c/addons/hr_holidays/views/hr_leave_views.xml#L238


So due to this change in Odoo V17 the confirm button is visible to the user while creating (before saving) so if the user clicks on the confirm button the behavior is it will save the record then set its state to confirm then will call action validate (all in the create function) after the execution of the create is finished it will call `action_confirm` which in turn will raise the user error.

I added a check in the action confirm function to check if the time off requires no validation.
alternatively I can revert the changes and add the `id == False` in the condition for the `action_confirm` button action. 

Current behavior before PR:
A user error message is raised if the user clicks on the confirm button. see issue #160831 

Desired behavior after PR is merged:
No user error message that happens if the user clicks on the confirm button.


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

Forward-Port-Of: odoo/odoo#160839

Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
  modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.

However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.

The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
  the minimum delay that made Google give us good page scoring but it
  may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?

Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:

- **The reasonable risk we take merging this in stable (we considered
  merging in a more recent version but it is needed for some specific
  projects and many websites would benefit from this improvement).**

- Any custom code that added behavior on buttons to be available during
  lazy loading... will just wait for lazy loading with a loading effect
  too now. This should be a good compromise as, again, that lazy loading
  is cached and should not take too long anyway.

Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).

Overall:
- This should not impact (neither improve nor worsen) most websites that
  are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
  experienced from bad internet connections.

Related to task-3770362

Forward-Port-Of: odoo/odoo#159680
Forward-Port-Of: odoo/odoo#158661

**Description of the issue/feature this PR addresses:**
Before this commit the time to unlink an account.move can take lot of time.
The time to unreconcile can take lot of time.

With 1 million `account.partial.reconcile`:
Time to remove 1 `account.full.reconcile` : before 329 ms after 5 ms.
Index size of `account.partial.reconcile` : before 59 Mo after 68 Mo (data size : 112 Mo) (+ 9 Mo)

Before:
![Capture d’écran 2024-03-01 à 14 20 45](https://github.com/odoo/odoo/assets/16716992/a9739ebe-90e4-4918-89b3-81169d9ab49c)
![image](https://github.com/odoo/odoo/assets/16716992/3c21965f-6d85-4457-84c2-502c8a253c6a)

After:
![Capture d’écran 2024-03-01 à 14 20 09](https://github.com/odoo/odoo/assets/16716992/b0daddf5-2333-496e-b7fd-2445365059c3)
![image](https://github.com/odoo/odoo/assets/16716992/698ab885-89d0-4238-9da3-ac0413c8aed0)



@oco-odoo 



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

Forward-Port-Of: odoo/odoo#160709
Forward-Port-Of: odoo/odoo#141307

Steps to reproduce:
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts and create a contact from San Marino:
  * Name: SM customer
  * Country: San Marino
  * Street, City, ZIP: [any]
  * Destination Code: [any]
- Create an invoice:
  * Customer: [the created contact from San Marino]
  * Product: [any]
- Confirm the invoice
- Generate E-invoice XML via "Send & Print" button

Issue:
In the XML, the destination code (i.e. CodiceDestinatario) is the default one for non-Italian customer (i.e. XXXXXXX).
Also, the VAT number (i.e. IdFiscaleIVA) is the default value for countries that are not in the European Union (i.e. OO99999999999).
However, since October 2021, San Marino should be handled differently for Italian electronic invoices.
A specific destination code (i.e. 2R4GTO8) should be used for all customers from San Marino.

Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/

Solution:
For customers from San Marino:
- Keep VAT number
- Set "2R4GTO8" as destination code

opw-3819054




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

Forward-Port-Of: odoo/odoo#160494

due to the absence of IR model data entries for certain account taxes, but with identical tax names, tax types, and scopes, attempts to create standard taxes with the same names alongside IR model data result in a constraint violation, specifically, "tax name must be unique." To address this constraint, we append "old" to the tax name for existing taxes lacking IR model data entries.

see:
https://github.com/odoo/odoo/blob/740fb9ac8c8e121820feeac0e1f25a304e47da9d/addons/account/models/account_tax.py#L202

```
 File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4864, in _create
    records._validate_fields(name for data in data_list for name in data['stored'])
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 1456, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/17.0/addons/account/models/account_tax.py", line 201, in _constrains_name
    raise ValidationError(
odoo.exceptions.ValidationError: Tax names must be unique!
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#161054

When user tries to empty start date or end date in website using editor,
a traceback will appear.

Steps to reproduce the error:
- Install "website_event"
- Go to Website > Events > Open any Event > Register > Edit
- Now try to empty start date or end date > Save

Traceback:
```
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1826, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1824, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 34, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 30, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/website/models/ir_ui_view.py", line 487, in save
    super(View, self).save(value, xpath=xpath)
  File "addons/web_editor/models/ir_ui_view.py", line 257, in save
    self.save_embedded_field(arch_section)
  File "addons/web_editor/models/ir_ui_view.py", line 56, in save_embedded_field
    record.write({field: value})
  File "addons/website_event/models/event_event.py", line 261, in write
    res = super(Event, self).write(vals)
  File "addons/event/models/event_event.py", line 590, in write
    res = super(EventEvent, self).write(vals)
  File "addons/mail/models/mail_thread.py", line 319, in write
    result = super(MailThread, self).write(values)
  File "addons/mail/models/mail_activity_mixin.py", line 248, in write
    return super(MailActivityMixin, self).write(vals)
  File "addons/website/models/mixins.py", line 217, in write
    return super(WebsitePublishedMixin, self).write(values)
  File "addons/website/models/mixins.py", line 136, in write
    return super().write(vals)
  File "odoo/models.py", line 4536, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "odoo/models.py", line 1483, in _validate_fields
    check(self)
  File "addons/event/models/event_event.py", line 570, in _check_closing_date
    if event.date_end < event.date_begin:
```

https://github.com/odoo/odoo/blob/4759c6d1ee09c32381dc56c59c95949fd0e2807c/addons/event/models/event_event.py#L507 Here, When user tries to empty start date or end date,
start date or end date will become "False",
So it will lead to the above traceback.

solution:
A try-catch is used to catch typeerror at write of qweb fields.

sentry-5038057541

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

Forward-Port-Of: odoo/odoo#160744
Forward-Port-Of: odoo/odoo#156707

7bbec42 removes the 'pos_done' state without providing a substitute. A discrepancy arises between the states defined in pos.order and sale.report.

While pos.order can have a 'done' state, this state is not defined in sale.report. Consequently, it is possible to encounter a situation where a state exists in 'sale.report' without being defined in its state field. This inconsistency leads to an error in the web client when attempting to display the state 'done' from 'pos.order', as the system cannot locate a corresponding label for it.

Since we can't add a new state in stable, we'll re-use the sale.order 'sale' state which is the sale.order counterpart of pos.order 'done'.

**steps to reproduce:**
- sales / reporting / sales and go to pivot view
- remove all filters
- on the pivot view, select 'product category'
- click on a cell corresponding to POS (ex: all/saleable/pos)
- click on a line in the list view
    

**before this commit:**

```
Caused by: TypeError: Cannot read properties of undefined (reading '1')
    at get string (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:8393:281)
    at SelectionField.template (eval at compile (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:1500:374), <anonymous>:15:21)
    at Fiber._render (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:940:96)
    at Fiber.render (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:939:6)
    at ComponentNode.initiateRender (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:1007:47)
```

**after this commit:**

the form view is rendered

opw-3816652

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

Forward-Port-Of: odoo/odoo#160432

**Steps to reproduce:**
- Install mrp and purchase
- Go to "Inventory / Configuration / Settings"
- Activate "Storage Locations"
- Go to "Inventory / Configuration / Warehouse Management / Operations Types"
- Edit "Receipts" type by activating "Show Detailed Operations"
- Go to "Manufactoring / Configuration / Settings"
- Activate "Subcontracting"
- Create product: (e.g. Product XYZ)
  * Product Type: Storable Product
- Create a BoM for Product XYZ:
  * BoM Type: Subcontracting
  * Subcontractors: [any] (e.g. Azure Interior)
- Create a PO:
  * Vendor: Azure Interior
  * Products: 2 x Product XYZ
- Confirm the PO
- Open the picking from PO via the Receipt smart button
- In "Operations" tab, set done to 1
- On the picking form, change the destination location (e.g. WH/Stock/Shelf1)
- Save
- In "Detailed Operations" tab, a line should have appeared
- Select the same destination location on that line (i.e. WH/Stock/Shelf1)
- Validate the picking and create a backorder for the remaining quantity to produce
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ (Search Product: XYZ - Group by: Location)
=> The "On Hand Quantity" for Product XYZ is as followed:
     * Virtual Locations/Production: -1.00 (correct)
     * WH/Stock/Shelf1: 1.00 (correct)
- Open the backorder picking from PO via the Receipt smart button
- Record the production of the remaining unit
- Validate the picking
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ

**Issue:**
The "On Hand Quantity" for Product XYZ is as followed:
* Partners/Vendors: -1.00 (incorrect, it should be empty)
* Physical Locations/Subcontracting Location: 1.00 (incorrect, it should be 0.00)
* Virtual Locations/Production: -2.00 (correct)
* WH/Stock/Shelf1: 2.00 (correct)

**Cause:**
When the PO is confirmed, the stock picking and the stock move are created, they both have the same source and destination locations.
However, in an overridden method from "mrp_subcontracting" module, a check is performed on the move to determine if it is a subcontract.
If it is the case, its source location is set to the subcontractor location and so, the source location of the picking and the move is not the same anymore.
When the destination location is changed on the picking, an onchange is triggering an update of the destination location AND the source location of the move to the values coming from the picking, erasing the subcontractor location set on the move.
The issue only happens for the backorder, because the source location update is not propagated to the stock move lines.
In the case of the original picking, the move lines were already created with the subcontractor location as source location.
But when the backorder is created, the move lines are created with the values coming from a move without the subcontractor location.

**Solution:**
Do not propagate "location_id" from the picking to the subcontracting moves.

opw-3777379




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

Forward-Port-Of: odoo/odoo#161011
Forward-Port-Of: odoo/odoo#158442

### Steps to reproduce:

- Create a vendor bill for a partner with a super long name.
- Go to Accounting > Reporting > Partner reports > Aged Payable
- Generate the pdf

#### > If the partner's name is long enough the last columns will not appear

### Cause of the issue:

Pdf are generated in Odoo using wkhtmltopdf. This one takes an html file renders it in Qtweb (shrinking its content to fit a single screen) and making a screenshot to generate a pdf. However, there is a limit to the shrinking applied to the html body. Therefore, if the content is too wide part of it will not appear on the pdf (this can easily been observed using Qtweb (but not with chrome)). Between 16.4 and 17.0 there was a refactoring of the way account reports are handled in Odoo see commit 2d77434 and commit b8209e2. Because of this refactoring, there is currently no width limit for cells of the table used in the body of account reports. As such, if the content of the first column is too wide, every other column will be pushed out of the screen before the pdf is generated. This is exactly what happens here.

### Fix:

We added a max width to cells and a wordbreak option on the css file used for the html in the pdf export of every account reports. This ensures that the content of any cell will not push the other cells outside of the screen before the screen shot.

### Second Issue:

Even with this issue out of the way, it is still possible for the content of the aged partner balance reports to be too wide after the shrink of the hmtl if you use a currency whose symbol is too long. The reason is the same as before coupled with the fact that these reports contain too many columns displaying the currency symbol of the company.

### Second part of the fix:

To fix this second issue, we use a custom css class for the export of the two problematic reports (aged payable and aged receivable) when the currency symbol is too wide.

opw-3749625
---

Forward-Port-Of: odoo/enterprise#58528

Contains four improvements for HMRC flow:
1- Successfully connecting to HMRC now shows a notification to let the user know they can send their reports.
2-  The "send" button in the send HMRC wizard triggers the sending but nothing happens UI wise. Now, the wizard is closed and a confirmation notification is shown.
3- For a user wanting to submit the VAT report for two companies, after switching clicking on the "send to HMRC" button raises an error as the token does not correspond to the correct company. Before, the user had to manually remove their authentication credentials to allow for a new connection to get a new token. Now, if we get an error from HMRC that the agent isn't authorised to submit the report, we clear the credentials ourselves and redirect the user to the login page, so they could get the correct token.
4- Trying to send the report without selecting an obligation returns a traceback error. Now, the send button will not appear unless an obligation is selected.

task-3696341

Forward-Port-Of: odoo/enterprise#55988

To reproduce the issue:
1. Switch to the `Activity` view for the Documents module.
2. Click `+ Schedule Activity`.
3. The dialog box opens up with the list of documents.
4. Try to DRAG & DROP any document list item.
5. We get a TRACEBACK.

Issue:
- The `onRecordClick` and the `onDragStart` events bound on the record rows are
  executed when we DRAG & DROP or click the records from the list of documents.
- When the method(`onDragStart`) is called from inside the `Dialog` scope, the
  `foldersById` in the line of code below returns a singleton object(`{false: {…}}`)
  with `false` being the folder_id of the `All` workspace.
- However, when the same method is called from the list/kanban view
  (i.e. outside of the `Dialog` scope) then the `foldersById` would return an
  object with all of the folderIds present as keys.

- In our case `foldersById[record.data.folder_id[0]].has_write_access` throws a
  traceback because the value of every `record.data.folder_id[0]` is a `Number`
  (as no document can be present inside the `All` workspace), but the
  `foldersById` object only contains the `false` key.

Fix:
- The schedule activity dialog box renders the JS of the list view of the related module. In our case, it renders the base list view from the documents and renders the JS of it.
- We cannot change this in stable so we fix the issue in JS.

After this commit:
- The records are no longer selected.
- We no longer get the traceback.

Task-3727009

Forward-Port-Of: odoo/enterprise#56356

**Current behavior:**
The `rental.schedule` model/view does not have serial number data for order lines which are constructed while the `Rental Transfers` config option is active. This prevents the view from accurately grouping by serial number.

**Expected behavior:**
The schedule view will correctly group the records in this gantt view.

**Steps to reproduce:**
1. Create a new rental product, ensure it has the 'By Unique Serial Number' tracking option

2. Create an on hand instance of this product with a serial number

3. In Rental settings, enable the `Rental Transfers` option

3. Create a new rental order for this product, go to the `Schedule` view in the Rental app, select Group By Serial Number, observe that the new order is listed as having an undefined serial number

**Cause of the issue:**
When the Rental Transfers option is enabled, the wizard which normally tracks rental pickups/returns gets circumvented to instead get organized via stock. The SQL view for the schedule model only looks in the tables managed by this wizard to find lot_ids of products included in rental orders. So when we don't use the wizard, that information never makes it to the proper place.

**Fix:**
Union the current view's table result with another query which will select the data for the excluded records.

opw-3754422

Forward-Port-Of: odoo/enterprise#58986

**Steps to reproduce:** (requires a real certificate and a real CAF)
- Install Accounting and l10n_cl_edi_boletas
- Switch to a Chilean company
- Configure the localization settings with a real certificate and a real CAF
- Create an invoice:
  * Customer: [a Chilean customer] (e.g. Blanco Martin & Asociados)
  * Document Type: (39) Boleta Electrónica
  * Product: [any]
- Confirm the invoice
- Click on "Send Now to SII"
- "SII DTE status" will be "Ask For Status" and "Send Now to SII" will change to "Verify on SII"
- As soon as it changes to "Verify on SII", click on it
- Repeat clicking on "Verify on SII" as soon as it becomes clickable

**Issue:**
At some point, "SII DTE status" will switch from "Ask For Status" to "Rejected", even if the invoice has not been officially rejected.
And as "Verify on SII" link will not be available anymore, it will not be possible to correct the SII DTE status.

**Cause:**
While checking the SII result after clicking on "Verify on SII", we could receive a response with "estado: SOK" and "estadistica: []".
This combination doesn't allow to determine a specific status for the SII DTE and therefore falls back on the default status that is "Rejected".

**Solution:**
If the SII DTE status cannot be determined, we should use "Ask For Status" as a fallback status to allow verifying it again.

opw-3781373

Forward-Port-Of: odoo/enterprise#60284
Forward-Port-Of: odoo/enterprise#59523