This change reorganizes how widgets are registered internally, separating widget details from the visual components that display them. It should make future maintenance and development more consistent across many Odoo apps, with little to no direct impact on day-to-day users.

Before this commit, the widget's description was stored on the component and this component was then registered.

Now, an object describing the widget is used on registration the same way as it is done for views since b828cfc.
This split the component's description (props, template, ...) of the widget's description ( component, extractProps, ...) and makes it clearer.

Part of task: 3179751

The specific classes used to render the trigger icon should be as localized as possible (not used in js and xml if not necessary). We also take the opportunity to simplify the widget `state` items. At this occasion, we also eliminate the flicker that could occur with the icon of a triggered question when deleting its trigger. Task-3151916 Forward-Port-Of: odoo/odoo#111134

The specific classes used to render the trigger icon should be as
localized as possible (not used in js and xml if not necessary).
We also take the opportunity to simplify the widget `state` items.

At this occasion, we also eliminate the flicker that could occur
with the icon of a triggered question when deleting its trigger.

Task-3151916

Forward-Port-Of: odoo/odoo#111134

## Current behaviour In Field Services, when selecting a task and applying let's say the ending time of 15:34, when the date picker shows up the minutes were set to 0, because 34 is not any multiple of the `timePickerIncrement` (which is 5 by default). ## Expected behaviour Even if the minutes are not a multiple of the `timePickerIncrement`, we should round to the closest one. ## Steps to reproduce - Install Field Services - Fields Services > Planning > By Project > Day - Choose a tas

## Current behaviour
In Field Services, when selecting a task and applying let's say the ending time of 15:34, when the date picker shows up the minutes were set to 0, because 34 is not any multiple of the `timePickerIncrement` (which is 5 by default).

## Expected behaviour
Even if the minutes are not a multiple of the `timePickerIncrement`, we should round to the closest one.

## Steps to reproduce
- Install Field Services
- Fields Services > Planning > By Project > Day
- Choose a task, and play around with the minutes of either starting and ending (you need to save each time to see the effect)
- If the minutes are a multiple of `timePickerIncrement` = 5, then there is the correct selection, but for everything else it is 0.

## Reason for the problem
When rendering the date range picker, only if the minute is exactly
a multiple of timePickerIncrement and only then it is selected.
For all other cases nothing is selected, therefor the first item is chosen by default.
Also the date used for computation is the one set on the record when opening the form view,
not the one from the input field on the form.

## Fix
When opening the date range picker, we read the values from the input fields,
and update the view. This will also round the minutes to the closest multiple
of `timePickerIncrement`, and doing a rollover if necessary (X:59 -> X+1:00).

## Affected versions
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- master
---
opw-3103490

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

Forward-Port-Of: odoo/odoo#110399

When chaining multiple moves (like in a multi-step delivery), if products are reserved on the previous moves of the chain, the products won't appear as "Reserved" in the forecast report, leading to inconsistencies between reservation done in stock and the one showed in the report. Steps to reproduce : - Enable multi-step deliveries for this warehouse - Put enough quantity in stock for a single product - Create a Sale Order, validate it and the validate the firsts pickings (i.e. pick/pack t

When chaining multiple moves (like in a multi-step delivery), if products are reserved on the previous moves of the chain, the products won't appear as "Reserved" in the forecast report, leading to inconsistencies between reservation done in stock and the one showed in the report.

Steps to reproduce :
- Enable multi-step deliveries for this warehouse
- Put enough quantity in stock for a single product
- Create a Sale Order, validate it and the validate the firsts pickings (i.e. pick/pack transfers)
- Create another Sale Order, validate it. Check that the quantity is reserved in the first picking (i.e. pick transfer)
- Go to the forecast report, only the first SO will me marked as "Reserved from Stock", even if both are.

opw-3074572

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

Forward-Port-Of: odoo/odoo#112442
Forward-Port-Of: odoo/odoo#107939

Problem: In a list view, editing a record and then clicking an action button on that record does not save the edited field values. Expected behaviour: Changes applied to the record must be saved before executing the button action. Solution: The 46bd694c8a67f25470a911c1eb04e0bf2e17a5f7 commit in master solves this problem (TaskID-3132960). We will backport it and add a test for our use case. How to reproduce: - Go to a list view with one text field and one button action per record -

Problem:
In a list view, editing a record and then clicking an action button on that record does not save the edited field values.

Expected behaviour:
Changes applied to the record must be saved before executing the button action.

Solution:
The 46bd694c8a67f25470a911c1eb04e0bf2e17a5f7 commit in master solves this problem (TaskID-3132960). We will backport it and add a test for our use case.

How to reproduce:
- Go to a list view with one text field and one button action per record
- Edit the text field
- Click on the button action

Before this commit:
The value of the text field has been restored. We lost our modification.

After this commit:
The record has been saved.

TaskID: 3168517

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

Before this commit, the email added to the blacklist was the value of the email after the deactivation of the user. It may lead to blacklist the wrong email when the deactivation change the email after this commit, like phone number, we keep the value of the email prior the deactivation which the real email to blacklist --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113068 Forward-Port-Of: odoo/odoo#112894

Before this commit, the email added to the blacklist was the value of the email after the deactivation of the user.

It may lead to blacklist the wrong email when the deactivation change the email

after this commit, like phone number, we keep the value of the email prior the deactivation which the real email to blacklist





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

Forward-Port-Of: odoo/odoo#113068
Forward-Port-Of: odoo/odoo#112894

#### Summary of changes: - When migrating, if a `Tax Mapping of Fiscal Position` already exists (for example, when manually created), any update of the module would raise a traceback trying to violate a uniqueness constraint. This commits fixes that #### Link to task: - opw-[3166338](https://www.odoo.com/web#id=3166338&menu_id=4720&cids=2&action=333&active_id=70&model=project.task&view_type=form) #### Traceback: ```python Traceback (most recent call last): File "/home/odoo/src/od

#### Summary of changes:
- When migrating, if a `Tax Mapping of Fiscal Position` already exists
(for example, when manually created), any update of the module would
raise a traceback trying to violate a uniqueness constraint.
This commits fixes that

#### Link to task:
- opw-[3166338](https://www.odoo.com/web#id=3166338&menu_id=4720&cids=2&action=333&active_id=70&model=project.task&view_type=form)

#### Traceback:
```python
Traceback (most recent call last):
  File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1289, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-14>", line 2, in new
  File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 478, in load_modules
    processed_modules += load_marked_modules(cr, graph,
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 371, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 235, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/home/odoo/src/odoo/16.0/odoo/modules/migration.py", line 177, in migrate_module
    migrate(self.cr, installed_version)
  File "/home/odoo/src/odoo/16.0/addons/l10n_es/upgrades/5.1/post-migrate_update_taxes.py", line 7, in migrate
    update_taxes_from_templates(cr, 'l10n_es.account_chart_template_common')
  File "/home/odoo/src/odoo/16.0/addons/account/models/chart_template.py", line 184, in update_taxes_from_templates
    _update_fiscal_positions_from_templates(company, chart_template_id, new_taxes_template)
  File "/home/odoo/src/odoo/16.0/addons/account/models/chart_template.py", line 145, in _update_fiscal_positions_from_templates
    chart_template._create_records_with_xmlid('account.fiscal.position.tax', tax_template_vals, company)
  File "/home/odoo/src/odoo/16.0/addons/account/models/chart_template.py", line 842, in _create_records_with_xmlid
    return self.env[model]._load_records(data_list)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4357, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4279, in _load_records_create
    return self.create(values)
  File "<decorator-gen-126>", line 2, in wrapper
  File "/home/odoo/src/odoo/16.0/odoo/api.py", line 410, in _model_create_multi
    return create(self, arg)
  File "/tmp/tmpp7dgs3jk/migrations/util/orm.py", line 200, in wrapper
    return f(*args, **kwargs)
  File "/tmp/tmpp7dgs3jk/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
    return super().create(vals_list)
  File "<decorator-gen-65>", line 2, in create
  File "/home/odoo/src/odoo/16.0/odoo/api.py", line 410, in _model_create_multi
    return create(self, arg)
  File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_fields.py", line 665, in create
    recs = super().create(vals_list)
  File "<decorator-gen-13>", line 2, in create
  File "/home/odoo/src/odoo/16.0/odoo/api.py", line 410, in _model_create_multi
    return create(self, arg)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3936, in create
    records = self._create(data_list)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4117, in _create
    cr.execute(
  File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 315, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "account_fiscal_position_tax_tax_src_dest_uniq"
DETAIL:  Key (position_id, tax_src_id, tax_dest_id)=(131, 750, 750) already exists.
```
#### Other references:
- upg-[485850](https://upgrade.odoo.com/web#id=485850&action=150&model=upgrade.request&view_type=form&cids=1&menu_id=107)




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

Forward-Port-Of: odoo/odoo#112787
Forward-Port-Of: odoo/odoo#112505

Before this commit: 1. Set up an EasyPost shipment setup, using "Canada Post" as the Carrier Type and "XpresspostUSA" as the Default Service Level. 2. Create a SO with a US customer (like Deco Addict) 3. "Add Shipping" using the button and choose the one created in 1. 4. When you try to "Get Rate" using the EasyPost shipment, the API does always return the same error: ``` Easypost returned an error: Unable to proceed, 'customs_info' is required for international shipments, shipments boun

Before this commit:
1. Set up an EasyPost shipment setup, using "Canada Post" as the Carrier Type and "XpresspostUSA" as the Default Service Level.
2. Create a SO with a US customer (like Deco Addict)
3. "Add Shipping" using the button and choose the one created in 1.
4. When you try to "Get Rate" using the EasyPost shipment, the API does always return the same error:
```
Easypost returned an error:
Unable to proceed, 'customs_info' is required for
international shipments, shipments bound for US
military bases, or US territories. Please see
https://www.easypost.com/docs/api#customs for more information.
```

After this commit:
As no commodities were set, `_customs_info` will return an empty dictionary.
To solve that, we set the `DeliveryPackage` commodity value on its initialisation to compute the customs information the way it should.

opw-3104305

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

Forward-Port-Of: odoo/odoo#108689

Since the transition of the inventory adjustments view to owl in https://github.com/odoo/odoo/commit/350a7a0d6f4816ee75676b80a9a5b9769bf80fe6, a bug was introduced in the inventory adjustments view. To reproduce: - Go to inventory adjustments page - Enter a 0 quantity in any of the Counted Quantity lines. - Press enter/tab/shift-tab to confirm. When focussing out of the field using the mouse after editing the field value, the difference field gets updated automatically, however when usi

Since the transition of the inventory adjustments view to owl in https://github.com/odoo/odoo/commit/350a7a0d6f4816ee75676b80a9a5b9769bf80fe6, a bug was introduced in the inventory adjustments view.

To reproduce:
- Go to inventory adjustments page
- Enter a 0 quantity in any of the Counted Quantity lines.
- Press enter/tab/shift-tab to confirm.

When focussing out of the field using the mouse after editing the field value, the difference field gets updated automatically, however when using a keypress as above, the field just stays the same.

Solved by adding overridden `onKeydown` behaviour in the `counted_quantity_widget` similar to the existing `onInput` behaviour.

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

Forward-Port-Of: odoo/odoo#112978

Install a database with many langs, arab, french, english, ... Keep english as the default lang. Start a shell and validate a sale-order using the superuser. On the web client, the sale order has been validated in arab instead of in english. In 16.0 the `context_get` method was changed to ensure there was always a lang set in the returned context. It used the following fallback order: context > request. The solution was partial because in case there was no request to extract a lang from, no l

Install a database with many langs, arab, french, english, ... Keep english as the default lang. Start a shell and validate a sale-order using the superuser. On the web client, the sale order has been validated in arab instead of in english.

In 16.0 the `context_get` method was changed to ensure there was always a lang set in the returned context. It used the following fallback order: context > request. The solution was partial because in case there was no request to extract a lang from, no lang was set on the context.

In a recent 16.0 fix (f2523c4a), the mechanism was changed to fix the previous problem. The fallback order became: context > request > first installed lang. This solution is sub-optimal because the first installed lang isn't always the best pick. e.g. when you have a mostly english company but that arab is installed for some website pages, arab is selected instead of english (the langs are alphabetically sorted)

In this work, the fallback order is changed once again:

  1. The lang set on the user's profile if activated
  2. The prefered lang extracted from the user's browser if activated
  3. (new) The lang of the user's current company if activated
  4. (new) English if activated
  5. The first lang (ordered by ISO code) if any
  6. English

The 3rd should cover most of ill-cases. For the 4th step, we assume that english is prioritaty to other installed langs when no lang standout.

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#111632
Forward-Port-Of: odoo/odoo#110275

https://github.com/odoo/odoo/commit/b7232b14b7f2423241b24b4eef1300f1a1b425cf#diff-78f3e1847de8ca0acf28d72a412947a549acdb08142d1dadf7646363d7972cb0R760 wrongly removed the assignation of the field in the compute function Forward-Port-Of: odoo/odoo#113159

https://github.com/odoo/odoo/commit/b7232b14b7f2423241b24b4eef1300f1a1b425cf#diff-78f3e1847de8ca0acf28d72a412947a549acdb08142d1dadf7646363d7972cb0R760 wrongly removed the assignation of the field in the compute function

Forward-Port-Of: odoo/odoo#113159

Before this commit, the online plane icon when the user is on leave had the same color as background. As a result, the plane icon was not visible. This commit fixes the issue by adding the missing `text-primary` classname, which adds the green color to state "online". Task-3196190 Forward-Port-Of: odoo/odoo#113191 Forward-Port-Of: odoo/odoo#113177

Before this commit, the online plane icon when the user is on leave had the same color as background. As a result, the plane icon was not visible.

This commit fixes the issue by adding the missing `text-primary` classname, which adds the green color to state "online".

Task-3196190

Forward-Port-Of: odoo/odoo#113191
Forward-Port-Of: odoo/odoo#113177

Before this commit: if a different `web.base.url` is set with `web.base.url.freeze`, during the first synchronization of Google calendar it will show a mismatch URL error. The problem is that we send the `redirect_uri` based on the `web.base.url` in the `_get_authorize_uri` function. The solution is to use the request root URL instead. opw-3101741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112982 Forward-Port-Of:

Before this commit: if a different `web.base.url` is set with `web.base.url.freeze`, during the first synchronization of Google calendar it will show a mismatch URL error. The problem is that we send the `redirect_uri` based on the `web.base.url` in the `_get_authorize_uri` function.

The solution is to use the request root URL instead.

opw-3101741

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

Forward-Port-Of: odoo/odoo#112982
Forward-Port-Of: odoo/odoo#111336

**Steps to reproduce the bug:** - Create a storable product “P1” - Update the qty to 100 - Create a Transfer: - product: P1 - type: Delivery order - qty: 1 unit - Mark as to do - Reserve the Qty - Create a seconde transfer: - product: P1 - type: Delivery order - qty: 5 unit - Mark as to do - Reserve the Qty - qty done: 2 unit - Create a batch picking with the 2 transfer - Try to validate the batch **Problem:** A traceback is tr

**Steps to reproduce the bug:**
- Create a storable product “P1”
- Update the qty to 100
- Create a Transfer:
    - product: P1
    - type: Delivery order
    - qty: 1 unit
    - Mark as to do
    - Reserve the Qty

- Create a seconde transfer:
    - product: P1
    - type: Delivery order
    - qty: 5 unit
    - Mark as to do
    - Reserve the Qty
    - qty done: 2 unit

- Create a batch picking with the 2 transfer
- Try to validate the batch

**Problem:**
A traceback is triggered: “ValueError: min() arg is an empty sequence”:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L73

Because when validating the first picking, the `_action_done` function is triggered, so moves that do not have qty done will be cancelled

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L1524-L1529


Therefore, the reserved qty will be unreserved, and the `stock.move.line` will be unlinked

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L1442

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L724


**Solution:**
We get the `date` from the `stock.move.line` to use it only when we have subcontracted production, we can therefore add a check before accessing them

opw-3159876

Forward-Port-Of: odoo/odoo#113022
Forward-Port-Of: odoo/odoo#112564

By following these steps: - Drop a block table of content on a page - Disable the visibility of the block in desktop view => A traceback is displayed. This is because for scrollspy to work properly, the elements that it handles must be visible (no display: none). Unfortunately, we put a display none when the block must be invisible for a certain device and the width of the screen is the one of this device. Since it is quite complex to prevent all the cases where the block could become

By following these steps:
- Drop a block table of content on a page
- Disable the visibility of the block in desktop view

=> A traceback is displayed.
This is because for scrollspy to work properly, the elements that it
handles must be visible (no display: none). Unfortunately, we put a
display none when the block must be invisible for a certain device and
the width of the screen is the one of this device. Since it is quite
complex to prevent all the cases where the block could become invisible,
we patch the scrollspy component of bootstrap so that it has a similar
behavior as in version 4.X. (not cause an error if the navigation
element is no longer in the DOM or is no longer visible).

The error is only visible since [the migration from bootstrap 4 to
bootstrap 5] because to add the class, bootstrap 4 did it with the
JQuery addClass() function which does not cause an error if the element
on which it is called does not exist. Now, bootstrap 5 does the same
thing in pure JS with classList.add() on elements that meet the
requirements (visible) which causes an error if the element on which it
is called is not defined (this is the case before this commit because
the TOC was not visible).

---

From [this commit], it is possible to define the visibility of blocks
according to the device on which the page is displayed (either hide on
mobile, or hide on desktop). This change has brought two problems on the
table of content block:
1. The sub-component s_table_of_content_main (the right part) can be
invisible, which does not make sense.
2. The sub-component of s_table_of_content_main can be invisible but it
did not change the navbar of the TOC.

This commit prevents hiding the main part of the TOC and rebuilds the
navbar of the TOC according to the device visibility of its
sub-components.

---

Since [this commit], it is possible to have a block only displayed on
mobile screens. This feature can break the steps snippet by following
these steps:
- Drop a steps snippet in a page
- Set the third step to be visible only on mobile

=> The connectors are broken.
This commit fixes this issue by only considering steps that are visible
in desktop view for connectors drawing.

---

[the migration from bootstrap 4 to bootstrap 5]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2

task-3116227
opw-3135927

Forward-Port-Of: odoo/odoo#110595

Description of the issue/feature this PR addresses: The X report of a PoS is a resume of the sales/refunds and other information of the session. It can be printed at any moment of the session. The Z report is the same as the X report with a bit more information like the starting and the ending datetime of the session. It can only be printed after the end of a session. The Z report can only be printed with the Swedish and Belgian localization at the moment and the goal is to make it availab

Description of the issue/feature this PR addresses:
The X report of a PoS is a resume of the sales/refunds and other information of the session.
It can be printed at any moment of the session.
The Z report is the same as the X report with a bit more information like the starting and
the ending datetime of the session. It can only be printed after the end of a session.
The Z report can only be printed with the Swedish and Belgian localization at the moment
and the goal is to make it available in the standard version. This PR also adds some information to the 
reports like the different invoices done during the session and also changes the layout of the reports
to be more readable if there is a lot of different products sold or a lot of different invoices done.

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

Forward-Port-Of: odoo/odoo#112270

Since 4d2b04a843c27981e44d6f932d7cf7e6838b4b9d, invoices auto-generated on Sales Order payment were not sent to customers. Invoices are only marked as 'posted' in the override of `_reconcile_after_done` in account_payment which means `_send_invoice` must be called after the super call s.t. the invoices are correctly posted before being sent. opw-3158620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113205

Since 4d2b04a843c27981e44d6f932d7cf7e6838b4b9d, invoices auto-generated on Sales Order payment were not sent to customers.

Invoices are only marked as 'posted' in the override of `_reconcile_after_done` in account_payment which means `_send_invoice` must be called after the super call s.t. the invoices are correctly posted before being sent.

opw-3158620



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

Forward-Port-Of: odoo/odoo#113205

Clicking on draw in the signature dialog should clear whatever is already drawn on the canvas. task-3040855 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#106082

Clicking on draw in the signature dialog should clear whatever is already drawn on the canvas.

task-3040855

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

1. Install [Expenses], [Indian - Accounting], [Accounting] on Apps 2. [Settings] [Users & Companies] [Companies] - create a company based in India with address there 3. Enter [Expenses], [CREATE] - create and add an employee w contact info (private address) in India - set paid by: Company, write an amount, category > [CREATE REPORT] - [SUBMIT TO MANAGER] [APPROVE] [POST TO JOURNAL ENTRIES] 4. Click on the [Journal Entry] created at the top right corner Issue: No Place of Supply which h

1. Install [Expenses], [Indian - Accounting], [Accounting] on Apps
2. [Settings] [Users & Companies] [Companies]
- create a company based in India with address there
3. Enter [Expenses], [CREATE]
- create and add an employee w contact info (private address) in India
- set paid by: Company, write an amount, category > [CREATE REPORT]
- [SUBMIT TO MANAGER] [APPROVE] [POST TO JOURNAL ENTRIES]
4. Click on the [Journal Entry] created at the top right corner

Issue: No Place of Supply which hinders the client

Resolve by: providing one by default and enable their further revision

Impacted versions: 16.0 up to master

opw-3168426

Forward-Port-Of: odoo/odoo#112616

This PR fix a traceback that occur when pressing space-bar while the confirm dialog for deleting a link preview is open. task-3196494 Forward-Port-Of: odoo/odoo#113231

This PR fix a traceback that occur when pressing space-bar while the confirm dialog for deleting a link preview is open.

task-3196494

Forward-Port-Of: odoo/odoo#113231

9fcf3de6a9f10d4171 broke `--log-level=debug_sql` (`Too many values to unpack`). 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#113230

9fcf3de6a9f10d4171 broke `--log-level=debug_sql`
(`Too many values to unpack`).

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

This commit fixes the shared-worker feature detection with using the browser object alias. Steps to reproduce: - Log to Odoo back-end with a device without a shared-worker support like Chrome on an Android device => traceback link: https://caniuse.com/mdn-api_sharedworker Forward-Port-Of: odoo/odoo#113223

This commit fixes the shared-worker feature detection with using the
browser object alias.

Steps to reproduce:

- Log to Odoo back-end with a device without a shared-worker support
  like Chrome on an Android device => traceback

link:

https://caniuse.com/mdn-api_sharedworker

Forward-Port-Of: odoo/odoo#113223

Currently, the vat label value comes from the company's country instead of this customer's country. So in this commit, we set the customer's country vat label in an error message. Forward-Port-Of: odoo/odoo#109603

Currently, the vat label value comes from the company's country instead of this customer's country.

So in this commit, we set the customer's country vat label in an error message.

Forward-Port-Of: odoo/odoo#109603

When the product configurator is opened, the focus is always on the custom value input, which may scroll down the configurator and make the user miss attributes Steps to reproduce: 1. Install Sales 2. Go to Settings > Sales > Product Catalog and enable Product Configurator and save 3. Go to Sales > Products > Products and open product 'Cabinet with Doors' 4. Go to the 'Attributes & Variants' tab and create and edit an attribute 'Custom' 5. Add a value 'Notes' and check 'Is custom value'

When the product configurator is opened, the focus is always on the custom value input, which may scroll down the configurator and make the user miss attributes

Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product Configurator and save
3. Go to Sales > Products > Products and open product 'Cabinet with Doors'
4. Go to the 'Attributes & Variants' tab and create and edit an attribute 'Custom'
5. Add a value 'Notes' and check 'Is custom value' and save
6. Add the value to the product and save
7. Open product 'Customizable Desk', in the 'Sales' tab, add 'Cabinet with Doors' to the Optional Products and save
8. Create a new quotation and add product 'Customizable Desk'
9. The product configurator opens up with the focus on the 'Custom' attribute input, if the window has a small height, it scrolls down to that input

Solution:
Remove the focus on the custom value input

Problem:
The focus was made on the input of custom values

opw-3057390

Forward-Port-Of: odoo/odoo#113213

While trying to fix an XML export issue (see : https://github.com/odoo/enterprise/commit/ea651f0a93316ea2a54ddc20ec09e47d73a234e5), we omitted to skip the increment in the sequence number, resulting in failed validation by the tax authorities. Forward-Port-Of: odoo/enterprise#37293

While trying to fix an XML export issue (see : https://github.com/odoo/enterprise/commit/ea651f0a93316ea2a54ddc20ec09e47d73a234e5), we omitted to skip the increment in the sequence number, resulting in failed validation by the tax authorities.

Forward-Port-Of: odoo/enterprise#37293

Before this pr, in the accounting setting there was a missing space between two labels and their associated fields. By doings some css, this pr resolves the issues. task-id: 3188507 Forward-Port-Of: odoo/enterprise#37314 Forward-Port-Of: odoo/enterprise#37136

Before this pr, in the accounting setting there was a missing space between two labels and their associated fields. By doings some css, this pr resolves the issues.

task-id: 3188507

Forward-Port-Of: odoo/enterprise#37314
Forward-Port-Of: odoo/enterprise#37136

This commit makes the signature frame be hidden when opening the signature dialog in draw mode. The reasoning for this is that users try to fit into the "lines" too much when signing, which adds friction as they will tend to try several times. Therefore, we should let them use the canvas as they choose. This commit also reduces the opacity of the frame, and adds a tooltip for the frame checkbox, as the frame doesn't appear anymore when in draw mode. task-3040855 Forward-Port-Of: odoo/ente

This commit makes the signature frame be hidden when opening the signature dialog in draw mode. The reasoning for this is that users try to fit into the "lines" too much when signing, which adds friction as they will tend to try several times. Therefore, we should let them use the canvas as they choose.

This commit also reduces the opacity of the frame, and adds a tooltip for the frame checkbox, as the frame doesn't appear anymore when in draw mode.

task-3040855

Forward-Port-Of: odoo/enterprise#34023

This module adds all the needed fields to comply with SII's format for exportation invoices (document type 110) when the goods are tangible goods. Even when quantity of packages is inherent to stock application, we need a field for this in the invoice, taking into account that there may be users without the inventory application installed and to keep a less complex logic. @Danisan @fvz-odoo @jco-odoo Forward-Port-Of: odoo/enterprise#37000 Forward-Port-Of: odoo/enterprise#34031

This module adds all the needed fields to comply with SII's format for exportation invoices (document type 110) when the goods are tangible goods.
Even when quantity of packages is inherent to stock application, we need a field for this in the invoice, taking into account that there may be users without the inventory application installed and to keep a less complex logic.
@Danisan @fvz-odoo @jco-odoo

Forward-Port-Of: odoo/enterprise#37000
Forward-Port-Of: odoo/enterprise#34031

Task: 959 **Description of the issue**: "FCE Transmission Option" is not saved when the user sets it. **Video commenting the problem**: https://drive.google.com/file/d/1ozrW7e5hG_507av_l9AyyjjxIQHGBOCp/view **Steps to reproduce**: 1) Create an invoice with document type 203 2) Set FCE Transmission Option with an option. 3) Save the invoice. **Desired behavior**: After making the steps mentioned above it is necessary to save the option selected in the field "FCE Transmission Opt

Task: 959

**Description of the issue**:
"FCE Transmission Option" is not saved when the user sets it.

**Video commenting the problem**:
https://drive.google.com/file/d/1ozrW7e5hG_507av_l9AyyjjxIQHGBOCp/view

**Steps to reproduce**:
1) Create an invoice with document type 203
2) Set FCE Transmission Option with an option.
3) Save the invoice.

**Desired behavior**:
After making the steps mentioned above it is necessary to save the option selected in the field "FCE Transmission Option" when the invoice is saved.

Forward-Port-Of: odoo/enterprise#36169

When exporting an empty report, IsNihil node is mandatory, as a replacement of OSSDeclarationInfo. This failed to validate the validation made by the Belgian government when submitting the file. xsd files can be found here: https://finances.belgium.be/fr/E-services/Intervat/documentation-technique OPW 3164390 Forward-Port-Of: odoo/enterprise#37286

When exporting an empty report, IsNihil node is mandatory, as a replacement of OSSDeclarationInfo. This failed to validate the validation made by the Belgian government when submitting the file.

xsd files can be found here: https://finances.belgium.be/fr/E-services/Intervat/documentation-technique

OPW 3164390

Forward-Port-Of: odoo/enterprise#37286

Before, depending on the version of the Windows IoT used, Worldline Interface could trigger a traceback because of the incompatible path used This PR fixes this issue and works with the latest version of IoT Windows at this day [Task 3196519](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#37288

Before, depending on the version of the Windows IoT used, Worldline Interface could trigger a traceback because of the incompatible path used

This PR fixes this issue and works with the latest version of IoT Windows at this day

[Task 3196519](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#37288

An AttributeError 'account.report' object has no attribute action_redirect_to_bank_statement_form' traceback occurs in account_report/account_bank_reconciliation_report: action_redirect_to_bank_statement_form was caught by a sentry. Because the function action_redirect_to_bank_statement_form was changed to action_redirect_to_bank_statement_widget [(see commit)](https://github.com/odoo/enterprise/commit/45c67defa3cb853f73dfbc25d70cb285f1825dfe#diff-979492c14b50bae3cdfd83a7927dd1eb3be2b9b5dac8578

An AttributeError 'account.report' object has no attribute action_redirect_to_bank_statement_form' traceback occurs in account_report/account_bank_reconciliation_report: action_redirect_to_bank_statement_form was caught by a sentry. Because the function action_redirect_to_bank_statement_form was changed  to action_redirect_to_bank_statement_widget [(see commit)](https://github.com/odoo/enterprise/commit/45c67defa3cb853f73dfbc25d70cb285f1825dfe#diff-979492c14b50bae3cdfd83a7927dd1eb3be2b9b5dac8578b29481d18b833700a)

sentry: https://drive.google.com/file/d/1nQFOBYjqGc7ultl4O3KxfOHwdc7Lpik7/view?usp=sharing

sentry-3770025459

Forward-Port-Of: odoo/enterprise#37208

…ntment Before, the name did not show in title because the appointment type is in 'random'. It only showed at the end of the process, once the appointment was confirmed. This is not appropriate when sharing a link for a single user. Indeed, the user will never be sure its link works since its name will not appear unless they take an appointment. Therefore, we allow showing the name of the user for random appointment types even if the appointment is in random assign mode. There is no real r

…ntment

Before, the name did not show in title because the appointment type is in 'random'. It only showed at the end of the process, once the appointment was confirmed. This is not appropriate when sharing a link for a single user. Indeed, the user will never be sure its link works since its name will not appear unless they take an appointment.

Therefore, we allow showing the name of the user for random appointment types even if the appointment is in random assign mode. There is no real randomness for single-user links.

We now show the name in title, as well as the user's details card in the 'Details' screen, and their picture if the option is set in backend.

Task-3165885

Forward-Port-Of: odoo/enterprise#36674