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

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

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

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

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#201684 Forward-Port-Of: odoo/odoo#201601

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#201684
Forward-Port-Of: odoo/odoo#201601

Before this commit all systray items of website were hidden for users that did not have the Restricted Editor right. This commit limits only some of the items to users having the Restricted Editor right: - Published: unrelated - Mobile preview: unrelated - Website switcher: unrelated - + New: Restricted Editor only - Edit in backend: unrelated - Translate: Restricted Editor only - Edit: Restricted Editor only It therefore now shows the Published button only based on the result of th

Before this commit all systray items of website were hidden for users that did not have the Restricted Editor right.

This commit limits only some of the items to users having the Restricted Editor right:
- Published: unrelated
- Mobile preview: unrelated
- Website switcher: unrelated
- + New: Restricted Editor only
- Edit in backend: unrelated
- Translate: Restricted Editor only
- Edit: Restricted Editor only

It therefore now shows the Published button only based on the result of the `_compute_can_publish` method of the `website.published.mixin`. The default implementation now checks whether the user has write access to the `website_published` field on the record.

Steps to reproduce:
- Install `website_crm_partner_assign`.
- Connect as a user without any Website role, and in Sales, the "User: Own Documents Only" role.
- Go to a partner in the `/partners` page. => "Published" button did not appear.

And on the contrary:
- Connect as a Restricted Editor user without Sales rights.
- Go to a partner in the `/partners` page.
- Click on "Published". => An access right error notification did appear.

task-3175890

Forward-Port-Of: odoo/odoo#201029
Forward-Port-Of: odoo/odoo#112421

During express checkout flows, we don't want to update the pricelist or recompute the prices as the user already accepted an amount. Nevertheless, recent commit 495de30cd273be87ea1a72dcb7bd0376acd6df8e updated the code to use the right orm api to prevent the recomputation, but in a wrong way. The field must be given as is, not as a field name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201774

During express checkout flows, we don't want to update the pricelist or recompute the prices as the user already accepted an amount.

Nevertheless, recent commit 495de30cd273be87ea1a72dcb7bd0376acd6df8e updated the code to use the right orm api to prevent the recomputation, but in a wrong way. The field must be given as is, not as a field name.




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

Forward-Port-Of: odoo/odoo#201774

Forward-Port-Of: odoo/enterprise#81496

Forward-Port-Of: odoo/enterprise#81496

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#81527 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#81527
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

The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This

The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO).

Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place.

This revision changes the flow by simply re-instanciating a new `Model` every time we change the target revision.

Task-4506832

Forward-Port-Of: odoo/enterprise#81446
Forward-Port-Of: odoo/enterprise#77667

Related to odoo/odoo#201029 Now that Can publish is based on access rights, some extra queries are needed when website is installed. Note that the appointment-only counts are unchanged. task-3175890 Forward-Port-Of: odoo/enterprise#81164

Related to odoo/odoo#201029

Now that Can publish is based on access rights, some extra queries are needed when website is installed.

Note that the appointment-only counts are unchanged.

task-3175890

Forward-Port-Of: odoo/enterprise#81164