Initial PR: https://github.com/odoo/odoo/pull/194141 It seems the fix above was not enough as it was assumed that connection (or backend in pg terms) were NOT being reused when initiated through `sql_db.connect`. For proper cleanup we need to reach [this part of the code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L1260-L1298) which can be done in 3 ways: - calling UNLISTEN * and committing - closing the connection - aborting the transaction

Initial PR: https://github.com/odoo/odoo/pull/194141

It seems the fix above was not enough as it was assumed that connection (or backend in pg terms) were NOT being reused when initiated through `sql_db.connect`.

For proper cleanup we need to reach [this part of the code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L1260-L1298) which can be done in 3 ways:
 - calling UNLISTEN * and committing
 - closing the connection
 - aborting the transaction (before committing the listen)

`UNLISTEN *` is a good candidate for this, but closing the connection seems to be the safer option.

Forward-Port-Of: odoo/odoo#201814
Forward-Port-Of: odoo/odoo#201401

Previously, the auto_install flag was set on both account and l10n_fr, preventing proper installation of the fiscal localization package. Now, the fiscal localization package is correctly installed when a French company is created and the account module is installed. opw-4630911 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201729 Forward-Port-Of: odoo/odoo#201591

Previously, the auto_install flag was set on both
account and l10n_fr, preventing proper installation of the fiscal localization package.

Now, the fiscal localization package is correctly
installed when a French company is created and the account module is installed.

opw-4630911


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

Forward-Port-Of: odoo/odoo#201729
Forward-Port-Of: odoo/odoo#201591

In commit b81314b we replaced a join on a case with a join on a boolean expression- however this did not materially increase performance (same order of magnitutde). Instead we should have simply used a valued case expression, which permits an entirely different (and much more optimal) query plan- specifically during sequential scans of the warehouse_cte common table expression. *See PR for further details* Forward-Port-Of: odoo/odoo#201318

In commit b81314b we replaced a join on a case with a join on a boolean expression- however this did not materially increase performance (same order of magnitutde).

Instead we should have simply used a valued case expression, which permits an entirely different (and much more optimal) query plan- specifically during sequential scans of the warehouse_cte common table expression.

*See PR for further details*

Forward-Port-Of: odoo/odoo#201318

This commit gives the users access to the XML of an invoice whose submission to JoFotara failed. This allows for better debugging of failed invoices. It also prevents the users from deleting PDFs of successfully submitted invoices. task-4571479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201943 Forward-Port-Of: odoo/odoo#199210

This commit gives the users access to the XML of an invoice whose submission to JoFotara failed.
This allows for better debugging of failed invoices.
It also prevents the users from deleting PDFs of successfully submitted invoices.

task-4571479



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

Forward-Port-Of: odoo/odoo#201943
Forward-Port-Of: odoo/odoo#199210

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 component

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 could become like this:
- Create env
- Wait for services to start
- Start loading chatter bundle
- Lazy services (from chatter bundle) are not yet completely started
- Main components of the lazy bundle are added to the registry
- Lazy services are completely started

It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services.

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

backport of odoo/odoo#201504

Related to: odoo/enterprise#81462

Forward-Port-Of: odoo/odoo#201771

The export is completely wrong when it comes to multiple taxes affecting each others. It would recompute the withholding taxes one by one based on the price subtotal instead of taking into account all other taxes as you would expect. task-4641930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201809 Forward-Port-Of: odoo/odoo#201489

The export is completely wrong when
it comes to multiple taxes affecting
each others.

It would recompute the withholding
taxes one by one based on the price
subtotal instead of taking into account
all other taxes as you would expect.

task-4641930

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

Forward-Port-Of: odoo/odoo#201809
Forward-Port-Of: odoo/odoo#201489

For existing customers, when coretax is installed, the new luxury tax group and its tax will not be loaded into Odoo. During XML generation, it will look for the tax group by XML ID which will not be found and hence resulting to traceback error. To mitigate this issue, we will introduce a post_init_hook to manually create the tax group and not raise exception when env.ref() doesn't find the tax group opw-4635356 --- I confirm I have signed the CLA and read the PR guidelines at www.odo

For existing customers, when coretax is installed, the new luxury tax group and its tax will not be loaded into Odoo. During XML generation, it will look for the tax group by XML ID which will not be found and hence resulting to traceback error. To mitigate this issue, we will introduce a post_init_hook to manually create the tax group and not raise exception when env.ref() doesn't find the tax group

opw-4635356



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

Forward-Port-Of: odoo/odoo#201643
Forward-Port-Of: odoo/odoo#201523

It should be `invoice_sending_failed`, we don't have `invoice_sent_failed` :D (for more info see `ciusro_document.py`, the `state` selection field) task-None Forward-Port-Of: odoo/odoo#201629

It should be `invoice_sending_failed`, we don't have `invoice_sent_failed` :D

(for more info see `ciusro_document.py`, the `state` selection field)

task-None

Forward-Port-Of: odoo/odoo#201629

Documents created in a company folder should by default be assigned to the same company, as it was before sharepocalypse. Editing a folder company should then propagate to the accessible children. Task-4491333 Forward-Port-Of: odoo/enterprise#80591

Documents created in a company folder should by default
be assigned to the same company, as it was before
sharepocalypse.

Editing a folder company should then propagate to the accessible children.

Task-4491333

Forward-Port-Of: odoo/enterprise#80591

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 component

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 could become like this:
- Create env
- Wait for services to start
- Start loading chatter bundle
- Lazy services (from chatter bundle) are not yet completely started
- Main components of the lazy bundle are added to the registry
- Lazy services are completely started

It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services.

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

backport of odoo/enterprise#81327

Related to : odoo/odoo#201771

Forward-Port-Of: odoo/enterprise#81462