The messaging interface was updated internally to align with the next version of Odoo's web framework. This helps keep Discuss-related features maintainable and ready for future upgrades without changing the user experience.

In preparation to using OWL v2 in discuss code

Task-2694189

community: https://github.com/odoo/odoo/pull/80033

The barcode and QR code scanning library was moved out of the Enterprise web area so it can be shared by more Odoo apps. This makes it easier for future features to reuse the same scanning capability consistently across editions.

This commit is a follow-up to the move of the ZXing library (used for
QR/Barcode decoding) from `web_enterprise` to `web` so it can be reused
in other modules (see PR odoo/odoo#79991).

Change motivated by odoo/odoo#78204

Forward-Port-Of: odoo/enterprise#22403

Forward-Port-Of: odoo/enterprise#22403

This commit changes the visibility condition of the invoicing tab in project form view when `helpdesk_sale_timesheet` module is just installed in the db. Because, when a project is linked to a helpdesk team, the invoicing tab should be visible when the project is billable and partner is set (same condition given in `sale_timesheet` module). Steps to reproduce: ================== 1) install `helpdesk_sale_timesheet` module in empty database. 2) Create a helpdesk team 3) Enable "Timeshe

This commit changes the visibility condition of the invoicing tab in
project form view when `helpdesk_sale_timesheet` module is just
installed in the db. Because, when a project is linked to a helpdesk
team, the invoicing tab should be visible when the project is billable
and partner is set (same condition given in `sale_timesheet` module).

Steps to reproduce:
==================
1) install `helpdesk_sale_timesheet` module in empty database.
2) Create a helpdesk team
3) Enable "Timesheets" option in "Track & Bill Time" section and save.
4) Go to the project linked to the helpdesk team
5) Select a partner

Expected Behavior:
=================
The invoicing tab should be visible.

Actual Behavior:
===============
The invoicing tab is not visible.

task-2647164

Forward-Port-Of: odoo/enterprise#22396

This fix is exactly the same as the one that was done for l10n_cl_edi in https://github.com/odoo/enterprise/pull/21503 and https://github.com/odoo/enterprise/pull/20868 . The logic is duplicated between modules and affected by the same issues. The UnexpectedXMLResponse exception which was added in l10n_cl_edi was not yet caught in l10n_cl_edi_stock, so if the condition was raised it would result in a traceback in the UI. This exception is caught the same way as in l10n_cl_edi now. Bec

This fix is exactly the same as the one that was done for l10n_cl_edi in
https://github.com/odoo/enterprise/pull/21503 and https://github.com/odoo/enterprise/pull/20868 .
The logic is duplicated between modules and affected by the same issues.

The UnexpectedXMLResponse exception which was added in l10n_cl_edi was not
yet caught in l10n_cl_edi_stock, so if the condition was raised it would
result in a traceback in the UI. This exception is caught the same way as
in l10n_cl_edi now.

Because the token being invalid was only checked after the response had been
analyzed, and unexpected responses cause the function to return and keep the
SII status the same, the invalid token would not get cleared. Like for
l10n_cl_edi, checking for an invalid token response before analyzing the response
and clearing the token if it was invalid fixes this. No retry was implemented
like in l10n_cl_edi, so if this happens the user needs to verify twice and after
that the SII status will update.

Forward-Port-Of: odoo/enterprise#22340
Forward-Port-Of: odoo/enterprise#21554

EDI documents often fail to send, this enables the download of generated XML to debug and analyse the cause Task-2669041 Forward-Port-Of: odoo/enterprise#22381 Forward-Port-Of: odoo/enterprise#21970

EDI documents often fail to send, this enables the download of generated XML to debug and analyse the cause
Task-2669041

Forward-Port-Of: odoo/enterprise#22381
Forward-Port-Of: odoo/enterprise#21970

- Install Peruvian localization as explained here: https://www.odoo.com/documentation/15.0/applications/finance/accounting/fiscal_localizations/localizations/peru.html - In Accounting settings, select "Digiflow" or "SUNAT" as Signature Provider - Create an invoice, confirm it and send it to be processed by E-invoicing service The XSD validation fails with the following error: "XSD validation failed: :1:0:ERROR:SCHEMASV:SCHEMAV_CVC_DATATYPE_VALID_1_2_1: Element '{http://www.w3.org/2000/09

- Install Peruvian localization as explained here:
https://www.odoo.com/documentation/15.0/applications/finance/accounting/fiscal_localizations/localizations/peru.html
- In Accounting settings, select "Digiflow" or "SUNAT" as Signature Provider
- Create an invoice, confirm it and send it to be processed by E-invoicing service

The XSD validation fails with the following error:
"XSD validation failed: :1:0:ERROR:SCHEMASV:SCHEMAV_CVC_DATATYPE_VALID_1_2_1:
Element '{http://www.w3.org/2000/09/xmldsig#}DigestValue': 'b've6OuQoJteW+YQZMkBQiCzej+Vs=''
is not a valid value of the atomic type '{http://www.w3.org/2000/09/xmldsig#}DigestValueType'."

The digest value should be decoded to be accepted by "Digiflow" and "SUNAT".

opw-2683955
opw-2687521
opw-2689068

Forward-Port-Of: odoo/enterprise#22307

Forward-Port-Of: odoo/enterprise#22352

Forward-Port-Of: odoo/enterprise#22352

### Expected Behaviour When making a new subscription, the client should be added only when validating the subscription (passing it to the "in_progress stage", not in draft. And it should then be removed from the follower in case the subscription is passed back to "draft", so that, in case of a change of client, we won't conserve the old client as follower ### Observed behaviour From V13, everytime we change the client, the new one is added as a new follower, while the old one stay as a

### Expected Behaviour

When making a new subscription, the client should be added only when validating the subscription (passing it to the "in_progress stage", not in draft. And it should then be removed from the follower in case the subscription is passed back to "draft", so that, in case of a change of client, we won't conserve the old client as follower

### Observed behaviour

From V13, everytime we change the client, the new one is added as a new follower, while the old one stay as a follower, leading to sending mail to people not related to the final subscription

### Reproducibility

This bug can be reproduced following these steps:
1. Create a new subscription with a client
2. Set a new client
3. Edit the subscription, change the client and save
4. Check the followers

### Problem Root Cause

The problem comes from the fact we set the client as follower each time we got through the "write" method of the subscription (called whenever something is changed), without regarding what as been changed and the current subscrption stage. Moreover, nothing was made to unset an old client as a follower, even when changind the client ID. Finally, the client ID was still editable even in a "in_progress" subscription.

### Related issue
- opw-2667755

Forward-Port-Of: odoo/enterprise#22309
Forward-Port-Of: odoo/enterprise#22241

…cument app Since commit 079e0ca, when you select a spreadsheet in the document kanban view and you click on the download button, the spreadsheet it not downloaded. Forward-Port-Of: odoo/enterprise#20956

…cument app

Since commit 079e0ca, when you select a spreadsheet in the document kanban view
and you click on the download button, the spreadsheet it not downloaded.

Forward-Port-Of: odoo/enterprise#20956