Until now, it is impossible to do <g:title>xxx</title> because qweb will autoclose the <g:link> because it checks if link is a void element instead to check g:link. Now we check the el_tag instead of unqualified_tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159476

Until now, it is impossible to do <g:title>xxx</title> because qweb will autoclose the <g:link> because it checks if link is a void element instead to check g:link.

Now we check the el_tag instead of unqualified_tag.




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

Forward-Port-Of: odoo/odoo#159476

Current behavior: When trying to print a receipt offline, the image will not be loaded and you get a traceback. Now the receipt is printed, and an error is logged in the console if the images couldn't be loaded Steps to reproduce: - Add a logo to the company - Launch PoS - In the browser devtools network tab turn the connection down - Do an order, and try to print the receipt - You get a traceback and the receipt is not printed opw-3811663 --- I confirm I have signed the CLA and

Current behavior:
When trying to print a receipt offline, the image will not be loaded
and you get a traceback.
Now the receipt is printed, and an error is logged in the console if
the images couldn't be loaded

Steps to reproduce:
- Add a logo to the company
- Launch PoS
- In the browser devtools network tab turn the connection down
- Do an order, and try to print the receipt
- You get a traceback and the receipt is not printed

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

Forward-Port-Of: odoo/odoo#162451

These will be used in the new service tax calculation and EDI modules. task-3660574 Forward-Port-Of: odoo/odoo#156017

These will be used in the new service tax calculation and EDI modules.

task-3660574

Forward-Port-Of: odoo/odoo#156017

Context: in 17.0 we enabled mass download for invoices. We expect this download to create a zip with all PDF invoices and their related xml files. Steps to reproduce: 1. Install l10n_fr 2. Create two invoices to french partners 3. Send & Print the two invoices and select 'Factur-x" and "Download" 4. A .zip file is generated with two PDF but only **one** XML file "factur-x.xml" Cause: The name of the XML file for the factur-x XML file is not specific to related invoice, it gets overrid

Context: in 17.0 we enabled mass download for invoices. We expect this download to create a zip with all PDF invoices and their related xml files.

Steps to reproduce:
1. Install l10n_fr
2. Create two invoices to french partners
3. Send & Print the two invoices and select 'Factur-x" and "Download"
4. A .zip file is generated with two PDF but only **one** XML file "factur-x.xml"

Cause:
The name of the XML file for the factur-x XML file is not specific to related invoice, it gets overriden each time it is generated.

See: https://github.com/odoo/odoo/pull/137382

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

A previous commit broke the smtp authentication using a TLS certificate and we only figured it out after that a client created a support ticket several weeks later. It turns out that there are actually no test that do validate the various ways outgoing mail servers can be configured. In this work we add a test suite where a local smtp server is started and controlled during the test execution. This makes it possible to test all the possible outgoing mail server configurations, including TLS.

A previous commit broke the smtp authentication using a TLS certificate and we only figured it out after that a client created a support ticket several weeks later. It turns out that there are actually no test that do validate the various ways outgoing mail servers can be configured.

In this work we add a test suite where a local smtp server is started and controlled during the test execution. This makes it possible to test all the possible outgoing mail server configurations, including TLS.

We chose [aiosmtpd](https://aiosmtpd.readthedocs.io) which is a pure-python lightweight SMTP server that aims at providing a programming API that is well suited to be used inside unittests.

[task-3703209](https://www.odoo.com/web#id=3703209&menu_id=4722&action=333&active_id=4872&model=project.task&view_type=form)
[opw-3640374](https://www.odoo.com/web#id=3640374&menu_id=6444&action=5050&model=project.task&view_type=form&cids=1)

Forward-Port-Of: odoo/odoo#151483

Description of the issue/feature this PR addresses: This commit is a performance fix to improve the speed of opening the pos kiosk or QR code. `_get_attributes` method of pos_self_order's product.product extension will call `self.env["pos.session"]._get_attributes_by_ptal_id()` every time it is called. For *N* products, `_get_attributes` is called *N* times. This can lead to slow performance for high enough *N*, because `_get_attributes_by_ptal_id` method is slow, because it makes many `read

Description of the issue/feature this PR addresses:
This commit is a performance fix to improve the speed of opening the pos kiosk or QR code.

`_get_attributes` method of pos_self_order's product.product extension will call `self.env["pos.session"]._get_attributes_by_ptal_id()` every time it is called. For *N* products, `_get_attributes` is called *N* times. This can lead to slow performance for high enough *N*, because `_get_attributes_by_ptal_id` method is slow, because it makes many `read` calls to product.attribute.value

This commit lifts the call to `_get_attributes_by_ptal_id` higher in the call stack, so that it is only called once as opposed to *N* times. It passes its result into `_get_attributes` via context, which will re-call `_get_attributes_by_ptal_id` if it wasn't in context for backwards compatibility reasons.

attributes must be deep copied within `_get_attributes`, because `_add_price_info_to_attributes` mutates the values within, which would invalidate future calls. The deep copy gives a fresh instance for each call, and only copies the applicable attributes so it shouldn't be large.

In this particular customer's DB they have 1376 product.product records and their pos config's pricelist (id 36) has 1572 rules in it.

Overall, based on the benchmarks below, this commit makes loading the pos about 4-5 times faster.

Benchmarks:

__Before commit__

_Customer DB_
product.product count == 1376
SQL query count ~= 5034
Time to load pos ~= 44 sec

_Customer DB with more products_
product.product count == 3792
SQL query count ~= 9359
Time to load pos ~= 96 sec

__After commit__

_Customer DB_
product.product count == 1376
SQL query count ~= 2360
Time to load pos ~= 8 sec

_Customer DB with more products_
product.product count == 3792
SQL query count ~= 3906
Time to load pos ~= 22 sec


Current behavior before PR:
Slow loading of pos kiosk/QR code

Desired behavior after PR is merged:
Faster loading of pos kiosk/QR code

opw-3758923

Forward-Port-Of: odoo/odoo#162962
Forward-Port-Of: odoo/odoo#159551

Prior to this commit, the presence of an invalid order in the browser cache could prevent the PoS from loading. This issue typically arises after a database upgrade, where changes in fields can render unpaid orders in the cache unloadable. This commit resolves this issue by discarding any problematic unpaid orders that can no longer be loaded. opw-3874858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162408

Prior to this commit, the presence of an invalid order in the browser cache could prevent the PoS from loading. This issue typically arises after a database upgrade, where changes in fields can render unpaid orders in the cache unloadable. This commit resolves this issue by discarding any problematic unpaid orders that can no longer be loaded.

opw-3874858

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

Forward-Port-Of: odoo/odoo#162408

Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= - Open with firefox - Go to settings , document layout - Added some `tab` in the footer or any html field - save - Open with chrome - Go to settings , document layout - click save without doing anything - error Origin of the issue: ==================== When calling sanitize in the

Issue:
======
If you have some tabs in a html_field, opening  with a different browser
may cause an issue when saving the document layout.

Steps to reproduce the issue:
=============================
- Open with firefox
- Go to settings , document layout
- Added some `tab` in the footer or any html field
- save
- Open with chrome
- Go to settings , document layout
- click save without doing anything
- error

Origin of the issue:
====================
When calling sanitize in the constructor, the tabs size doesn't change
because we didn't add the class `odoo-editor-editable` which doesn't
make the `editable` dirty since no changes has been made. When calling
save, `cleanForSave` will be called with a clone of the `editable` so in
sanitize it won't matter since the element is not connected to the dom
so again no changes and the edtior still no dirty, after that ,
`onWillUpdateProps` of  `Wysiwyg` will be called and we will set the
value of the editor by the new value which will call `resetContent` of
`odooEditor` and it will sanitize the editable but this time it has the
class `odoo-editor-editable` so the finally the sizes of the tabs will
be changed and the editable will become dirty. Now `onWillUnmount` in
`html_field` will be called and since the field is dirty it will commit
changes as a normal save , but a traceback will occur since the
component is already destroyed.

Solution:
=========
Add the class `odoo-edtior-editable` before the call to sanitize to mark
the field as dirty from the start and will be updated with the new sizes
of tabs on the first commit and not in the commit of `onWillUnmount`.

opw-3742423

Forward-Port-Of: odoo/odoo#156898

Create a Vendor Bill Add on the invoice line a vehicle Confirm In "Journal Items" tab hit 'Cut-Off' Fill the necessary info and create journal items Issue: Created journal items will not have the vehicle id opw-3802919 Forward-Port-Of: odoo/odoo#162914 Forward-Port-Of: odoo/odoo#159434

Create a Vendor Bill
Add on the invoice line a vehicle
Confirm
In "Journal Items" tab hit 'Cut-Off'
Fill the necessary info and create journal items
Issue: Created journal items will not have the vehicle id

opw-3802919

Forward-Port-Of: odoo/odoo#162914
Forward-Port-Of: odoo/odoo#159434

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified. 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#162581

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified.

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

Those were broken by the theme update for 17.0, in particular at [1]. Indeed the underline colors were defined using `text-XXX` classes to use the theme colors, relying on the fact that the default color of HR elements used the `currentColor`. Now they use the `currentColor` but very faded... making those underline colors uglier and for one of them, basically invisible. As a stable fix, this updates the XML to make the border use the `currentColor` as before in new mega menus... although they

Those were broken by the theme update for 17.0, in particular at [1]. Indeed the underline colors were defined using `text-XXX` classes to use the theme colors, relying on the fact that the default color of HR elements used the `currentColor`. Now they use the `currentColor` but very faded... making those underline colors uglier and for one of them, basically invisible.

As a stable fix, this updates the XML to make the border use the `currentColor` as before in new mega menus... although they do not work as well in 17.0 as they did in 16.0. This will be reviewed in master to use better colors and a more reliable and beautiful way.

[1]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364e

Forward-Port-Of: odoo/odoo#163011

The test needs to set `product_id` field in order to check user's access. However, the field is not visible without enabling product variants, which makes the test fail in an environment with no demo data. This commit fixes the issue by adding the MRP manager to the 'product.group_product_variant' group. The issue was introduced in #162107 . Related build error: https://runbot.odoo.com/web#id=61998&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form Description of t

The test needs to set `product_id` field in order to check user's access. However, the field is not visible without enabling product variants, which makes the test fail in an environment with no demo data. This commit fixes the issue by adding the MRP manager to the 'product.group_product_variant' group.

The issue was introduced in #162107 .

Related build error:

https://runbot.odoo.com/web#id=61998&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form

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

Before this commit when we have a synced event with google and then we toggle the all-day field changes didn't reflect on google side This happened because google uses two separate fields for start/end. 1. dateTime (used for normal events) 2. date (used for all-day events) when one of them is set, the other must be null. Before this commit when we did a patch update, we set only one, but forget about the other which raises an error. Task: 3681668 ============================== I

Before this commit when we have a synced event with google and then we toggle the all-day field
changes didn't reflect on google side

This happened because google uses two separate fields for start/end.
1. dateTime (used for normal events)
2. date (used for all-day events)

when one of them is set, the other must be null.
Before this commit when we did a patch update, we set only one, but forget about the other which raises an error.

Task: 3681668

==============================
I couldn't find it in google calendar api documentation supporting my claim. But I based my conclusion on these facts:

1. when sending a get request to google API for all-day events it would look like this, we can observe that for both start/end it doesn't have a `dateTime` but only `date`.
```js
{
    "kind": "calendar#event",
    "etag": "\"3420874125486000\"",
    "id": "11qeiguv96iei6nkd4helg421b",
    "status": "confirmed",
    "htmlLink": "https://www.google.com/calendar/event?eid=MTFxZWlndXY5NmllaTZua2Q0aGVsZzQyMWIgYWxhaEBvZG9vLmNvbQ",
    "created": "2024-03-14T10:39:50.000Z",
    "updated": "2024-03-14T17:24:22.743Z",
    "summary": "all day from google",
    "creator": {
        "email": "alah@odoo.com",
        "self": true
    },
    "organizer": {
        "email": "alah@odoo.com",
        "self": true
    },
    "start": {
        "date": "2024-03-20"
    },
    "end": {
        "date": "2024-03-21"
    },
    "transparency": "transparent",
    "iCalUID": "11qeiguv96iei6nkd4helg421b@google.com",
    "sequence": 2,
    "reminders": {
        "useDefault": false
    },
    "eventType": "default"
}
```

2. When doing the same for an event that is not marked as all-day. we would get this
```js
{
    "kind": "calendar#event",
    "etag": "\"3420880154840000\"",
    "id": "6ngnlju6nofaa0h478nkqgrhna",
    "status": "confirmed",
    "htmlLink": "https://www.google.com/calendar/event?eid=Nm5nbmxqdTZub2ZhYTBoNDc4bmtxZ3JobmEgYWxhaEBvZG9vLmNvbQ",
    "created": "2024-03-14T18:14:37.000Z",
    "updated": "2024-03-14T18:14:37.420Z",
    "summary": "aaa",
    "creator": {
        "email": "alah@odoo.com",
        "self": true
    },
    "organizer": {
        "email": "alah@odoo.com",
        "self": true
    },
    "start": {
        "dateTime": "2024-03-14T15:00:00+02:00",
        "timeZone": "Africa/Cairo"
    },
    "end": {
        "dateTime": "2024-03-14T16:00:00+02:00",
        "timeZone": "Africa/Cairo"
    },
    "iCalUID": "6ngnlju6nofaa0h478nkqgrhna@google.com",
    "sequence": 0,
    "reminders": {
        "useDefault": true
    },
    "eventType": "default"
}
```

so on google side, it's either `date` or `dateTime` but not both. Hence when doing a patch update for either `date` or `dateTime` we should unset the other.

Forward-Port-Of: odoo/odoo#157664

Original issue: 1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1" 3) Archive company A 4) In the company selector, make "main" the active company. It will auto-select branch B as well. 5) Open the tax report, and try clicking the "Closing Entry" button ==> The button is disabled ; it shouldn't be. This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches

Original issue:

1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1"
3) Archive company A
4) In the company selector, make "main" the active company. It will auto-select branch B as well. 5) Open the tax report, and try clicking the "Closing Entry" button ==> The button is disabled ; it shouldn't be.

This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches_with_same_vat searches for sub-branches, doing

self.env['res.company'].sudo().search([('id', 'child_of', current.root_id.ids)])

In our example, this search will return main, B and A1. We then compare that with the company selector, which only contains main and B.

This configuration of companies does not make sense functionally speaking, as a branch whose parent is inactive will not be usable anyway. Therefore, we now archive all the sub-branches when archiving a company.

opw-3877368
task-3878070

Forward-Port-Of: odoo/odoo#162638

Before this fix, any XRechnung xml will raise a warning when being submitted on https://erechnungsvalidator.service-bw.de/. The warning states: "[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen." This is because the version 3.0.1 has been released. issue-160644 Forward-Port-Of: odoo/odoo#162187

Before this fix, any XRechnung xml will raise a warning when being submitted on https://erechnungsvalidator.service-bw.de/.

The warning states: "[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen."

This is because the version 3.0.1 has been released.

issue-160644

Forward-Port-Of: odoo/odoo#162187

This test can sometimes fail randomly ``` FAIL: TestProfiling.test_sync_recorder Traceback (most recent call last): File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder self.assertEqual(stacks_methods, [ AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']] First differing element 11: ['__exit__', '_remove']

This test can sometimes fail randomly

```
    FAIL: TestProfiling.test_sync_recorder
    Traceback (most recent call last):
    File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder
        self.assertEqual(stacks_methods, [
    AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']]

    First differing element 11:
    ['__exit__', '_remove']
    ['__exit__', 'stop']

    First list contains 2 additional elements.
    First extra element 12:
    ['__exit__']

    [['a'],
    ['a', 'b'],
    ['a'],
    ['a', 'c'],
    ['a', 'c', 'd'],
    ['a', 'c'],
    ['a', 'c', 'd'],
    ['a', 'c'],
    ['a'],
    [],
    ['__exit__'],
    -  ['__exit__', '_remove'],
    -  ['__exit__'],
    ['__exit__', 'stop']]
```

Since we don't care about the last lines, just remove them from the assertion.

Forward-Port-Of: odoo/odoo#163016

…countries All these countries use the chart of accounts that is defined in l10n_syscohada. The system for the loading of chart template wasn't planned to inherit from another module, and so the loading of the templates had to be adapted. This commit add the tax report for each localization, and taxes to be able to fill it. task-2841655 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I

…countries

All these countries use the chart of accounts that is defined in l10n_syscohada. The system for the loading of chart template wasn't planned to inherit from another module, and so the loading of the templates had to be adapted.

This commit add the tax report for each localization, and taxes to be able to fill it.

task-2841655

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

Issue: Have a grouped list view with several page, go to the next page, open a group and click on a record to open it in form view. Click on the breadcrumb to go back to the list: the offset is lost, and we're back in page 1. After this commit, the offset is correctly kept. opw~3851390 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.

Issue:
Have a grouped list view with several page, go to the next page, open a group and click on a record to open it in form view. Click on the breadcrumb to go back to the list: the offset is lost, and we're back in page 1.

After this commit, the offset is correctly kept.

opw~3851390

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#162969
Forward-Port-Of: odoo/odoo#162844

**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system employs alerts resembling `this field 'partner_name' is mandatory for the action 'actionName'`. However, this alteration has led to a bug where in certain forms exhibit an undefined action name value, particularly evident when users attempt to modify specific forms containing

**Step to reproduce:**
  - Go to /jobs (install website_hr_recruitment)
  - Go on a job offer
  - Click on the "Apply" button
  - Edit the form
  
  **Purpose:**
  
Since the implementation of commit [1], our system employs alerts resembling `this field 'partner_name' is mandatory for the action 'actionName'`. However, this alteration has led to a bug where in certain forms exhibit an undefined action name value, particularly evident when users attempt to modify specific forms containing required fields. The bug manifests when an alert is triggered, and the action name becomes undefined due to the condition `this.modelCantChange` evaluating to `true` within the `willStart` function. Consequently, invoking `_super` results in the return of `willStart` without assigning a value to `currentActionName`.
  
  **After this commit:**
  
 Now, before returning the function, it sets a value for `currentActionName` and then proceeds with the necessary steps. This prevents the issue where an action was `undefined`.
  
  [1]: https://github.com/odoo/odoo/pull/120874/commits/491a25b2baaa415a9bc26340eba5a11af8605411
  
  task-3680483

Forward-Port-Of: odoo/odoo#162468
Forward-Port-Of: odoo/odoo#157501

When the module "sale_product_configurator" is not installed, an AttributeError is raised Steps to reproduce: - Install the "point_of_sale" app, the "pos_self_order_sale" module and remove the "sale_product_configurator" module - Go to settings -> point of sale -> Self ordering: QR Menu -> preview web interface Cause: The field "optional_product_ids" is provided by the module "sale_product_configurator" which is not a dependency of this module opw-3850421 --- I confirm I have s

When the module "sale_product_configurator" is not installed, an AttributeError is raised

Steps to reproduce:
- Install the "point_of_sale" app, the "pos_self_order_sale" module and remove the "sale_product_configurator" module
- Go to settings -> point of sale -> Self ordering: QR Menu -> preview web interface

Cause:
The field "optional_product_ids" is provided by the module "sale_product_configurator" which is not a dependency of this module

opw-3850421


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

Forward-Port-Of: odoo/odoo#161921

In some databases, customers have changed the `reconcile` value of an account from its standard `False` value to `True`. This action causes related journal items, which are partially reconciled, to raise the following constraint error. during the upgrade process: ``` You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending ``` so we delete changes in the `reconcile` values from the reload to avoid overriding user customer setting & t

In some databases, customers have changed the `reconcile` value of
an account from its standard `False` value to `True`.
This action causes related journal items,
which are partially reconciled, to raise the following
constraint error.
during the upgrade process:
```
You cannot switch an account to prevent
the reconciliation if some partial reconciliations are still pending
```
so we delete changes in the `reconcile` values from the reload
to avoid overriding user customer setting & triggering the
constraint error.

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

Problem --------- Because of this PR: 155896, the customer default value for the UBL export values has been modified from commercial partner to partner. However, in 16.0+, some constraints have been added to verify that some fields were properly set up before generating the XML. Those restrictions clash with the said changes. Indeed: 1 - Create NO company 2 - Set up UBL on invoice journal 3 - Create a new NO customer and set up UBL in the same way 4 - Create an invoicing address for t

Problem
---------
Because of this PR: 155896, the customer default value for the UBL export values has been modified from commercial partner to partner.

However, in 16.0+, some constraints have been added to verify that some fields were properly set up before generating the XML. Those restrictions clash with the said changes.

Indeed:
1 - Create NO company
2 - Set up UBL on invoice journal
3 - Create a new NO customer and set up UBL in the same way 4 - Create an invoicing address for that customer
5 - Create an invoice for with the customer set as the invoice address set up in step 3.
6 - Send & Print with UBL selected

>> An error is added to the export errors while it should not.

Solution
---------
Use the commercial partner when checking constrains of all fields other than addresses.

OPW-3848367

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

Forward-Port-Of: odoo/odoo#162366
Forward-Port-Of: odoo/odoo#160523

Surveys cannot be created in batch without `session_code` because it must be unique across surveys. Technically, using a 5-digit codes makes it unlikely that a collision occurs with records created without explicit session_code (see Survey._get_default_session_code's iterative process). See runbot 55709 See also related runbot 25041 Task-3829536 Forward-Port-Of: odoo/odoo#159882

Surveys cannot be created in batch without `session_code` because it must be unique across surveys.

Technically, using a 5-digit codes makes it unlikely that a collision occurs with records created without explicit session_code (see Survey._get_default_session_code's iterative process).

See runbot 55709
See also related runbot 25041

Task-3829536

Forward-Port-Of: odoo/odoo#159882

Prior to this commit, there were scenarios where sync orders did not contain an order, leading to a failure when reading its state. This commit introduces a check to ensure the order exists in sync before its state is read, thereby preventing this error. opw-3856451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162943

Prior to this commit, there were scenarios where sync orders did not contain an order, leading to a failure when reading its state. This commit introduces a check to ensure the order exists in sync before its state is read, thereby preventing this error.

opw-3856451

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

Forward-Port-Of: odoo/odoo#162943

Reduce the survey questions page in every display mode and the print page display to be the half screen size. This is done to match the previous results page improvements. Also reducing the font size of the "Thank you" message and the print page questions and sections titles to best match the new half screen display. related odoo/odoo#152263 Task-3789479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156665

Reduce the survey questions page in every display mode and the print page display to be the half screen size. This is done to match the previous results page improvements.

Also reducing the font size of the "Thank you" message and the print page questions and sections titles to best match the new half screen display.

related odoo/odoo#152263

Task-3789479

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

Forward-Port-Of: odoo/odoo#156665

Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as this code should not be reached with these file types. The reason this occurs is because we check for the file extension when deciding to post process an image, but when we get to initializing the ImageProcess object, we then check the actual file structure to verify the type of file. This is a

Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as this code should not be reached with these file types.

The reason this occurs is because we check for the file extension when deciding to post process an image, but when we get to initializing the ImageProcess object, we then check the actual file structure to verify the type of file.

This is a workaround for the time being, but should not be a final solution in future versions.

Adding a null check on img.image in the _postprocess_contents method in order to avoid attempting to access the size of this image when it is null.

Raises a user error in order to trigger the catch and exit the code while logging the error and 'Post processing ignored:'.

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

Forward-Port-Of: odoo/odoo#156209

To reproduce: - Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance" - Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))" - Another expression of any engine labelled 'dudu' ==> Try opening the first report; it loads forever. This i

To reproduce:

- Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance"

- Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))"

    - Another expression of any engine labelled 'dudu'

==> Try opening the first report; it loads forever.

This is because the bound expression is only searched in the expressions of the active report ; not in the expressions loaded from other reports. In our case, the aggregation needing the bound is from the second report, so the bound belongs to its report as well. The looping occurs because that value, since it's not present in the first report's evaluated data, is considered as not yet computed, and the computation is continuously delayed at the end of the treatment queue, causing it to never become empty.

Forward-Port-Of: odoo/enterprise#59236
Forward-Port-Of: odoo/enterprise#58339

This adds tax calculation and EDI support for service transactions. All new functionality was added in new modules because this is taking place in a stable release. Avatax has different endpoints for submitting and cancelling service invoices. These two endpoints have fairly similar payloads so various overrides were made to remove/add information from the goods payloads to make them compatible with the service endpoints. A new account.external.tax.mixin l10n_br_is_service_transaction field i

This adds tax calculation and EDI support for service transactions. All new functionality was added in new modules because this is taking place in a stable release.

Avatax has different endpoints for submitting and cancelling service invoices. These two endpoints have fairly similar payloads so various overrides were made to remove/add information from the goods payloads to make them compatible with the service endpoints. A new account.external.tax.mixin l10n_br_is_service_transaction field is used to determine whether to follow the old, existing goods flow or go through the new service flow.

The biggest difference is that service invoices go through an extra, asynchronous validation step. To achieve this, invoices that are successfully submitted end up in a new "pending" state. After this, their status can be checked with
button_l10n_br_edi_get_service_invoice(). This function is also called periodically with a cron.

In master, these modules will be merged into the already existing modules and deleted.

task-3660574

Forward-Port-Of: odoo/enterprise#57868

Before this commit, when a churned contract was cancelled, the subscription_state was not reset. The resulting filter on SO would be confusing: Group by subscription_state > state After this commit, the churned order subscription-state is reset to draft or renewal quotation when canceled. This allow to reset the canceled order to quotation and to be able to restart the flow if necessary. Forward-Port-Of: odoo/enterprise#59960

Before this commit, when a churned contract was cancelled, the
  subscription_state was not reset. The resulting filter on SO would be
  confusing:
  Group by subscription_state > state
  
  After this commit, the churned order subscription-state is reset to
  draft or renewal quotation when canceled. This allow to reset the
  canceled order to quotation and to be able to restart the flow if
  necessary.

Forward-Port-Of: odoo/enterprise#59960

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified. Forward-Port-Of: odoo/enterprise#61137

The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified.

Forward-Port-Of: odoo/enterprise#61137

In the VAT listing report, a customer might have a turnover of more than 250€ but wasn't added in the report due to missing information such as country or a VAT number. This commit adds a warning with those customers on top of the report with a link to view and edit them. task-3249107 Forward-Port-Of: odoo/enterprise#53550

In the VAT listing report, a customer might have a turnover of more than 250€ but wasn't added in the report due to missing information such as country or a VAT number. This commit adds a warning with those customers on top of the report with a link to view and edit them.

task-3249107

Forward-Port-Of: odoo/enterprise#53550

## Description: Previously, the list reinsertion dialog overlooked converting user input to integers, causing JavaScript to treat numbers as strings. Consequently, unintended concatenation occurred, resulting in excessive record insertion. This PR addresses the issue by enforcing integer conversion on user input, ensuring precise record insertion. Task ID: [3833909](https://www.odoo.com/web#id=3833909&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forw

## Description:

Previously, the list reinsertion dialog overlooked converting user input to integers, causing JavaScript to treat numbers as strings. Consequently, unintended concatenation occurred, resulting in excessive record insertion.

This PR addresses the issue by enforcing integer conversion on user input, ensuring precise record insertion.

Task ID: [3833909](https://www.odoo.com/web#id=3833909&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#61021
Forward-Port-Of: odoo/enterprise#60642

Before this commit, subscription tour didn't work due to technical changes. This commit aims to fix the tour, by adapting to the new changes. Task: 3679337 Forward-Port-Of: odoo/enterprise#58613

Before this commit, subscription tour didn't work due to technical changes. This commit aims to fix the tour, by adapting to the new changes.

Task: 3679337

Forward-Port-Of: odoo/enterprise#58613

Some tests have an additional query, making runbot fail in no-demo mode. This is to investigate but we can already ix tests. Runbot-62058 Runbot-62057 Runbot-62056 Runbot-62055 Forward-Port-Of: odoo/enterprise#61129

Some tests have an additional query, making runbot fail in no-demo mode. This is to investigate but we can already ix tests.

Runbot-62058
Runbot-62057
Runbot-62056
Runbot-62055

Forward-Port-Of: odoo/enterprise#61129

Welcome missing report 1.1 (For Cash) and 1.2 (For bank) This reports are generated from `cash flow statement` report and is based on `bank.statement.line` closes odoo/enterprise#60974 Forward-Port-Of: odoo/enterprise#61093

Welcome missing report 1.1 (For Cash) and 1.2 (For bank)

This reports are generated from `cash flow statement` report and is based on `bank.statement.line`

closes odoo/enterprise#60974

Forward-Port-Of: odoo/enterprise#61093