Before this commit, the author of the messages in the livechat would only have an avatar if it was an operator. But logged users would not have their avatar displayed. This commit fixes this issue by fetching the avatar when possible. taskid-3006025 Forward-Port-Of: odoo/odoo#102544

Before this commit, the author of the messages in the livechat would
only have an avatar if it was an operator. But logged users would not
have their avatar displayed.

This commit fixes this issue by fetching the avatar when possible.

taskid-3006025

Forward-Port-Of: odoo/odoo#102544

On the smart button where you can see the accounts of the plan, we want to be able to see all accounts of subplans too. We also change the order of the analytic accounts, by plan's complete name then name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101784

On the smart button where you can see the accounts of the plan,
we want to be able to see all accounts of subplans too.
We also change the order of the analytic accounts, by plan's complete name then name.




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

Forward-Port-Of: odoo/odoo#101784

When a m2m field add a context in its arch, it's passed through to the rpcs made to the server. In a m2m situation, while the name_search worked properly, the read operation on a dropdown item select did not provide this context. This PR fixes that. Forward-Port-Of: odoo/odoo#102559

When a m2m field add a context in its arch, it's passed through to the
rpcs made to the server. In a m2m situation, while the name_search
worked properly, the read operation on a dropdown item select did not
provide this context.
This PR fixes that.

Forward-Port-Of: odoo/odoo#102559

This commit fixes the behavior of date, datetime and daterange fields. It was no longer possible to open the date/datetime picker by clicking on the corresponding label, since the inputs were missing the id attribute associated with the label. Now, it is possible again, and hovering the label will correctly highlight the input border of the field. Tests have been added too, to make sure this works properly. Forward-Port-Of: odoo/odoo#102575

This commit fixes the behavior of date, datetime and daterange fields. It was no longer possible to open the date/datetime picker by clicking on the corresponding label, since the inputs were missing the id attribute associated with the label.

Now, it is possible again, and hovering the label will correctly highlight the input border of the field.

Tests have been added too, to make sure this works properly.

Forward-Port-Of: odoo/odoo#102575

Before this commit, editing a domain field with an invalid value for the field type will display a parsing error. The purpose of the commit is to reintroduce the old behaviour of the field, it should not display an error. How to reproduce? - Go to a form view with a domain field (in_dialog=True) - Click on the "Edit Domain" button - Add a domain comparing a field of type int with "01/01/2000" Before this commit: An error is displayed. After this commit: The domain is applied w

Before this commit, editing a domain field with an invalid value for the field type will display a parsing error.

The purpose of the commit is to reintroduce the old behaviour of the field, it should not display an error.

How to reproduce?
- Go to a form view with a domain field (in_dialog=True)
- Click on the "Edit Domain" button
- Add a domain comparing a field of type int with "01/01/2000"

Before this commit:
 An error is displayed.

After this commit:
 The domain is applied with the wrong value.
 If the server considers the domain to be false, then "Invalid domain"
 is displayed.

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

This commit replaces the `group` element containing the "Connect Stripe" button by a `div` element to allow it to contain more elements than the button without having the elements' `attrs` conflicting with each other. task-2982357 See also: - https://github.com/odoo/internal/pull/1862 Forward-Port-Of: odoo/odoo#102455

This commit replaces the `group` element containing the "Connect Stripe" button by a `div` element to allow it to contain more elements than the button without having the elements' `attrs` conflicting with each other.

task-2982357

See also:
- https://github.com/odoo/internal/pull/1862

Forward-Port-Of: odoo/odoo#102455

Before commit: The `jsvat.js` library used to be lazyloaded but was added to the bundle in the manifest during the conversion to owl and the lib was loaded at startup every time. After commit: The `jsvat.js` file is lazy loaded using loadJS when the component is first selected so the lib is only loaded when it is actually needed. The lib is also loaded before running the tests to prevent the asynchronous call from making the tests fail. Forward-Port-Of: odoo/odoo#102555

Before commit:
The `jsvat.js` library used to be lazyloaded but was added to the bundle
in the manifest during the conversion to owl and the lib was loaded at
startup every time.

After commit:
The `jsvat.js` file is lazy loaded using loadJS when the component is
first selected so the lib is only loaded when it is actually needed.

The lib is also loaded before running the tests to prevent the asynchronous
call from making the tests fail.

Forward-Port-Of: odoo/odoo#102555

Fixup of 706db8a79ae3821e8b55f1e52644fbacf6f449ba --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102699 Forward-Port-Of: odoo/odoo#102558

Fixup of 706db8a79ae3821e8b55f1e52644fbacf6f449ba




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

Forward-Port-Of: odoo/odoo#102699
Forward-Port-Of: odoo/odoo#102558

Issue from the pad: > [LNA] on crm.lead formview, add property fields > they do not seem to taken into account in the grid system, meaning the alignment breaks https://tinyurl.com/2jw5km48 **Before:** https://youtu.be/kvZYYmZI8rY **After:** https://youtu.be/HObGrBE8Zmc **Notable change:** Below the `lg` breakpoint, the `.o_inner_group` columns starts to wrap but the properties don't, so we change the class of `.o_property_field` from `col-md-` to `col-lg-`. --- I confirm I have s

Issue from the pad:

> [LNA] on crm.lead formview, add property fields > they do not seem to taken into account in the grid system, meaning the alignment breaks https://tinyurl.com/2jw5km48

**Before:** https://youtu.be/kvZYYmZI8rY
**After:** https://youtu.be/HObGrBE8Zmc
**Notable change:** Below the `lg` breakpoint, the `.o_inner_group`
columns starts to wrap but the properties don't, so we change the
class of `.o_property_field` from `col-md-` to `col-lg-`.


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

Forward-Port-Of: odoo/odoo#102334

Steps : - On a new DB (no demo data). Say created at 15:00. - Go to planning. - Add a shift for today. - Set the dates from 08:00 to 17:00. Issue : The 'Allocated Time' = 02:00. Cause : We used to count from the resource creation min to the departure max. So, in this case, not from 08:00, but from 15:00. While this might seem logical, it confuses users in onboarding. Fix : Calculate the whole time, regardless of the resource lifespan. Notes : - Similar issues solved with this

Steps :
- On a new DB (no demo data). Say created at 15:00. - Go to planning.
- Add a shift for today.
- Set the dates from 08:00 to 17:00.

Issue :
The 'Allocated Time' = 02:00.

Cause :
We used to count from the resource creation min to the departure max. So, in this case, not from 08:00, but from 15:00. While this might seem logical, it confuses users in onboarding.

Fix :
Calculate the whole time, regardless of the resource lifespan.

Notes :
- Similar issues solved with this commit :
> Once the shift validated, the avatar progress bar uses
the same allocated time.
> Same in Project Task gantt view.
- When contract is installed, if the resource does not have a contract, the Allocated Time = 0. Now, it is calculated from the resource calendar.

task-2983993

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

Project portal: prevent showing the `displayed_image_id` to non internal users. task-2895909 Forward-Port-Of: odoo/odoo#97211

Project portal: prevent showing the `displayed_image_id` to non internal users.

task-2895909

Forward-Port-Of: odoo/odoo#97211

Reason for traceback: When an internal user clicks on the 'Sale Order', 'Invoice' or 'Ticket' state button, opens Backend view. But the portal backend does not support chatter. So comes the traceback. In this commit, we open the portal view. task-2973173 Forward-Port-Of: odoo/odoo#101116

Reason for traceback:

When an internal user clicks on the 'Sale Order', 'Invoice' or 'Ticket' state button, opens
Backend view. But the portal backend does not support chatter. So comes the traceback.
In this commit, we open the portal view.

task-2973173

Forward-Port-Of: odoo/odoo#101116

in b1d57adf6ff3 the size of the header added to source files while concatenating them was reduced, but the corresponding offset use when generating source maps was not adapted, causing source maps to drift further and further from the actual source location the further in the compiled asset the line is. This commit fixes that by decrementing the header offset as needed. Forward-Port-Of: odoo/odoo#102569

in b1d57adf6ff3 the size of the header added to source files while concatenating them was reduced, but the corresponding offset use when generating source maps was not adapted, causing source maps to drift further and further from the actual source location the further in the compiled asset the line is.

This commit fixes that by decrementing the header offset as needed.

Forward-Port-Of: odoo/odoo#102569

Currently the "abort" function in the pos_adyen module did not include all the information necessary to cancel the current payment. With this commit this information is added and the status is correctly returned to the JS in order to have the correct status on the payline https://docs.adyen.com/point-of-sale/cancel-a-transaction#cancel-from-register Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I con

Currently the "abort" function in the pos_adyen module did not include all the information necessary to cancel the current payment. With this commit this information is added and the status is correctly returned to the JS in order to have the correct status on the payline

https://docs.adyen.com/point-of-sale/cancel-a-transaction#cancel-from-register

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

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

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

Due to the 'transform: none' applied on images and icons on mobile, some animations do not work in mobile. This commit makes an exception to this rule for animated images/icons. task-2984828 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#100270

Due to the 'transform: none' applied on images and icons on mobile, some animations do not work in mobile. This commit makes an exception to this rule for animated images/icons.

task-2984828

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

*: exhibitor, meet, track Remove the line above online screens of meetings, ehibitors and tracks. Remove css that can be removed. Task-3006773 Forward-Port-Of: odoo/odoo#102120

*: exhibitor, meet, track

Remove the line above online screens of meetings, ehibitors and tracks. Remove css that can be removed.

Task-3006773

Forward-Port-Of: odoo/odoo#102120

The component `section_and_note_one2many` doesn't take all `width` available and so in some case when there is too content or the form view is too small the `table` overflow outside the form. This commit forces this component to take `100%` of the `width` available. Steps to reproduce: * Open Sales * Select a Quotation * Reduce the size (width) on the Browser => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#10

The component `section_and_note_one2many` doesn't take all `width` available and so in some case when there is too content  or the form view is too small the `table` overflow outside the form.
This commit forces this component to take `100%` of the `width` available.

Steps to reproduce:
* Open Sales
* Select a Quotation
* Reduce the size (width) on the Browser => BUG

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

Forward-Port-Of: odoo/odoo#102593

--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102616

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

Forward-Port-Of: odoo/odoo#102616

The commit https://github.com/odoo/odoo/commit/babf7634e0d431471e5b708b937407c8b731b77b broke a previous fix in https://github.com/odoo/odoo/commit/6228500a3f3cdb17286d50f2662f3e7b0226f667 allowing the chatter to grow beyond its original size. This commit restores the `flex-grow: 1` on the chatter's container but also limit its maximum width (like in saas-15.3) to avoid it becoming unreadable. Forward-Port-Of: odoo/odoo#102697

The commit https://github.com/odoo/odoo/commit/babf7634e0d431471e5b708b937407c8b731b77b broke a
previous fix in https://github.com/odoo/odoo/commit/6228500a3f3cdb17286d50f2662f3e7b0226f667
allowing the chatter to grow beyond its original size.

This commit restores the `flex-grow: 1` on the chatter's container but
also limit its maximum width (like in saas-15.3) to avoid it becoming
unreadable.

Forward-Port-Of: odoo/odoo#102697

Forward-Port-Of: odoo/odoo#101954

Forward-Port-Of: odoo/odoo#101954

# [FIX] web: fix kanban useSortable screen width limit ## Reproduce: Go on a kanban view, with enough columns so it goes off the screens. Scroll on the right, try to drag anything beyond the original (before scrolling) limit of the screen. The cards are stuck floating at that limit. Note it didn't prevent the drop to work properly where the mouse was. ## Issue: The useSortable hook gets an owl ref, which is used as a limit to where things can be dragged and dropped. Originaly and logi

# [FIX] web: fix kanban useSortable screen width limit
## Reproduce:
Go on a kanban view, with enough columns so it goes off the screens.
Scroll on the right, try to drag anything beyond the original (before
scrolling) limit of the screen. The cards are stuck floating at that
limit. Note it didn't prevent the drop to work properly where the mouse
was.

## Issue:
The useSortable hook gets an owl ref, which is used as a limit to where
things can be dragged and dropped. Originaly and logically, it was the
current component ref, the renderer. But for some unknown reason, this
space was not getting wider than the initial screen size. It may be a
problem with the flexbox layout.

## Tried solutions:
- A first solution was to add the overflow-x-scroll css property to the
renderer. It works, but now the horizontal scroll bar is no longer
always visible. You have to scroll all the way down to see it. UX wise
this is not acceptable.

- We could remove the clamp mecanism inside useSortable to let the drag
and drop motion go anywhere. This works, but decrease the quality of the
interaction. It looks cheap and not polished.

## Final Solution
Finally, we decided to pass a ref to the o_content div from the layout
component down to the kanban renderer. If the useSortable is given this
ref, it works as intended. While it may seem too much, it is not
unreasonable to propose a reference to the most parent element of the
view contents to the renderer.

# [IMP] web: add edge scrolling behavior to useSortable
In house implementation of automatic scoll when dragging an element to
the edges of its container.

Enterprise PR: https://github.com/odoo/enterprise/pull/32478

Forward-Port-Of: odoo/odoo#101763

1) Before this Commit, While adding journal lines in hr expense the amount per unit was calculated as the total amount of product such as quantity into the price per unit After this Commit, the price per unit was calculated correctly 2) Before this Commit, project > reporting > tasks analysis > drill down the graph/pivot view > list view was editable and able to creatable After this Commit, project > reporting > tasks analysis > drill down the graph/pivot view > list view was not

1)
Before this Commit, While adding journal lines in hr expense the amount per unit
was calculated as the total amount of product such as quantity into the price per
unit

After this Commit, the price per unit was calculated correctly

2)
Before this Commit, project > reporting > tasks analysis > drill down the
graph/pivot view > list view was editable and able to creatable

After this Commit,  project > reporting > tasks analysis > drill down the
graph/pivot view > list view was not editable and able to creatable

3)
Before this commit, in the project, the recurrent boolean was shown twice

After this commit, in the project, the recurrent boolean will show once only


task-3000758


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

Forward-Port-Of: odoo/odoo#101849

before this commit, project task kanban view for some reason are not display the user_ids avatars. after this commit, project task kanban view are display the user_ids avatars. TaskId: 2871552 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#102657 Forward-Port-Of: odoo/odoo#95822

before this commit,  project task kanban view for some reason are not  display
 the  user_ids avatars.

after this commit, project task kanban view are display the user_ids avatars.

TaskId: 2871552

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#102657
Forward-Port-Of: odoo/odoo#95822

The aim of this commit is to improve the test skipping code of the oss modules by avoiding to hardcode the chart_template_ref (xml_id) directly in the error message. Before this commit: The TestOSSSpain test class was failing when the l10n_es module wasn't installed instead of being skipped. After this commit: The TestOSSSpain test class is correctly skipped instead of failing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P

The aim of this commit is to improve the test skipping code of the oss modules by avoiding to hardcode the chart_template_ref (xml_id) directly in the error message.

Before this commit:
The TestOSSSpain test class was failing when the l10n_es module wasn't installed instead of being skipped.

After this commit:
The TestOSSSpain test class is correctly skipped instead of failing.





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

Forward-Port-Of: odoo/odoo#102695
Forward-Port-Of: odoo/odoo#102551

This commit cleans the tax groups: - it removes the negative tax groups - it makes sure that there is only one tax group per tax rate - all the taxes with the same rates are attached to a single tax group This commit splits the taxes to make the distinction between the goods and services. In addition, the fiscal positions are also updated accordingly (make sure to map to another one having the same scope: goods/services and type: sale/purchase). These changes are based on the reliable

This commit cleans the tax groups:
- it removes the negative tax groups
- it makes sure that there is only one tax group per tax rate
- all the taxes with the same rates are attached to a single tax group

This commit splits the taxes to make the distinction between the goods and services.
In addition, the fiscal positions are also updated accordingly (make sure to map to another
one having the same scope: goods/services and type: sale/purchase).

These changes are based on the reliable feedback of LPDE (Didier Six).

In addition, the tax report is updated to the 2022 version and the new tax report lines
are linked to the taxes.

task-2674047

Forward-Port-Of: odoo/odoo#102598
Forward-Port-Of: odoo/odoo#84918

Quantity done will be always editable. Different use case: 1. If there is not location/package/tracing/owner -> same behavior than before 2. If the details are needed: - Immediate transfer. In case of increase the quants are reserved and the `qty_done` on `stock.move.line` is increased depending the reservation. If the quantity couldn't be fully reserve then default `stock.move.line` are create (depending the putaway rules or multiple ones if the products are tracked). In case of decre

Quantity done will be always editable. Different use case:
1. If there is not location/package/tracing/owner -> same behavior than
  before
2. If the details are needed:
- Immediate transfer. In case of increase the quants are reserved and the
`qty_done` on `stock.move.line` is increased depending the reservation.
If the quantity couldn't be fully reserve then default `stock.move.line`
are create (depending the putaway rules or multiple ones if the products
are tracked). In case of decrease, the quantity reserved are unreserve
but the `stock.move.line` are not unlink until the validation.
- Planned transfer. The quantity done will fill the reservation. If the
picking is not assign, it will reserve the quantity needed. In case of
decrease, it will only unreserve the extra quantity (compare to the
initial demand). To unreserve the quantity bellow the intial demand, the
`stock.move.line` could be unlink or use the `unreserve` button.

force_qty in `_action_assign` is needed because we don't reserve only
base on the initial demand (`product_uom_qty`) but sometimes on the
quantity_done.

In order to never block the user. The action_show_details is always
available. If the id is not available, it will save and open the record
(we take the record based on the new existing line with same product
and highest id).

task-id: 2960983

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

When [1] was merged, it did not adapt correctly external providers redirections. As now the /shop pages can be viewed inside an iframe, the external redirections must be opened in the top window. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b task-2687506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102187

When [1] was merged, it did not adapt correctly external providers redirections. 
As now the /shop pages can be viewed inside an iframe, the external redirections must be opened in the top window.

[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

task-2687506


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

Forward-Port-Of: odoo/odoo#102187

Before this commit, in a list view, if you clicked the discard button for an invalid row, it would not be discarded and the discard button would disappear. Why did this happen? Invalid fields in the record were not deleted. How to reproduce? - Go to a list view with a required char field - Edit the char field of a record with an empty string - Click outside the record (it becomes invalid) - Click on the discard button Before this commit: The record is not discarded (its values do

Before this commit, in a list view, if you clicked the discard button for an invalid row, it would not be discarded and the discard button would disappear.

Why did this happen?
Invalid fields in the record were not deleted.

How to reproduce?
- Go to a list view with a required char field
- Edit the char field of a record with an empty string
- Click outside the record (it becomes invalid)
- Click on the discard button

Before this commit:
The record is not discarded (its values do not change and it remains in edit mode) and the discard button disappears

After this commit:
The record is correctly discarded and the discard button disappears

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

Have a form view in a dialog (action in target=new) The create/write of that model throws an error. Before this commit, the "Oh snap!" dialog was displayed, but makes little sense in a dialog. After this commit, the old UserError dialog is displayed. 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:

Have a form view in a dialog (action in target=new) The create/write of that model throws an error.

Before this commit, the "Oh snap!" dialog was displayed, but makes little sense in a dialog.

After this commit, the old UserError dialog is displayed.

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

Inline fields for numeric values should not as wide as they are now, since they tend to be 'close by' another field (e.g. currency, periodicity, etc.) in the same 'row' or included in a text zone - in which case we want the value to be closer to its context, and not completely isolated in a huge area. Forward-Port-Of: odoo/odoo#102567

Inline fields for numeric values should not as wide as they are now, since they tend to be 'close by' another field (e.g. currency, periodicity, etc.) in the same 'row' or included in a text zone - in which case we want the value to be closer to its context, and not completely isolated in a huge area.

Forward-Port-Of: odoo/odoo#102567

Factur-x import is broken since: 4ea13aea05b1d9650a2c9605d24ac7d69583cefa Indeed, for non FR/DE companies, the `_get_xml_builder` is now returning None, thus the import `_create_invoice_from_xml_tree` and `_update_invoice_from_xml_tree` do not work. Forward-Port-Of: odoo/odoo#102776

Factur-x import is broken since: 4ea13aea05b1d9650a2c9605d24ac7d69583cefa Indeed, for non FR/DE companies, the `_get_xml_builder` is now returning None, thus the import `_create_invoice_from_xml_tree` and `_update_invoice_from_xml_tree` do not work.

Forward-Port-Of: odoo/odoo#102776

This relates to bugprovements for v16: https://pad.odoo.com/p/accounta_matata_v16 ### [[FIX] account_intrastat: hide transaction code on amls](https://github.com/odoo/enterprise/commit/44fd31ab20b6d64823669d966ed8734e5980c0a4) The intrastat_transaction_id represents the type of transaction in the intrastat system. This is provided at the level of the account move line. It has been decided that it should be optionally hidden by default. This is as simple as changing the 'optional' a

This relates to bugprovements for v16:
https://pad.odoo.com/p/accounta_matata_v16

### [[FIX] account_intrastat: hide transaction code on amls](https://github.com/odoo/enterprise/commit/44fd31ab20b6d64823669d966ed8734e5980c0a4) 

The intrastat_transaction_id represents the type of transaction in the
intrastat system. This is provided at the level of the account move
line.

It has been decided that it should be optionally hidden by default. This
is as simple as changing the 'optional' attribute on the field.

### [[FIX] account_intrastat: name on intrastat report actions](https://github.com/odoo/enterprise/commit/d9876428e1137e7406088cbaacb0cd73c09b8e5b) 

Correct the name on the existing actions associated with the warnings
displayed on the intrastat report for misconfigured lines.

### [[IMP] account_intrastat: demo data](https://github.com/odoo/enterprise/commit/135d04f03b75876f9c83019e039f7c3da02fceec) 

This commit adds intrastat commodity codes for the demo data
'consu' (i.e. not service) products present in the product
module (intrastat depends on accounting, which depends on product, thus
we can add to these products). Only one of these products requires data
for the intrastat_supplementary_unit_amount field.

### [[FIX] account_intrastat: caret options for intrastat report](https://github.com/odoo/enterprise/commit/df49025f5d2862cf61c9c702b198745488b6256d) 

The intrastat report lines have a caret that should provide the option
of visiting the invoice associated with the line of the report.

This commit specifies the _caret_option_initializer function on the
intrastat report custom handler, which overides the parent definition
and allows the 'View Journal Entry' caret option to be displayed from
the report line.

Forward-Port-Of: odoo/enterprise#32379

Forward-Port-Of: odoo/enterprise#32465

Forward-Port-Of: odoo/enterprise#32465

Before this commit: When we open the documents from the project .task form view, On reloading the current page, we are getting the trace back (active_model not defined). After this commit: we set the active_model as project .task and minimize the trace back. Task_id: 2871552 Forward-Port-Of: odoo/enterprise#32502 Forward-Port-Of: odoo/enterprise#29421

Before this commit: When we open the documents from the project .task form view,
 On reloading the current page, we are getting the trace back
(active_model not defined).

After this commit:  we set the active_model as project .task and minimize
the trace back.

Task_id: 2871552

Forward-Port-Of: odoo/enterprise#32502
Forward-Port-Of: odoo/enterprise#29421

Before this commit, when a subscription line is free (seeling price is 0), the invoice status of the line is 'to invoice'. As it is not desired if the product is free, we decided to force invoice_status to 'no' in this situation. Forward-Port-Of: odoo/enterprise#32495 Forward-Port-Of: odoo/enterprise#32177

Before this commit, when a subscription line is free (seeling price is 0), the invoice status of the line is 'to invoice'. As it is not desired if the product is free, we decided to force invoice_status to 'no' in this situation.

Forward-Port-Of: odoo/enterprise#32495
Forward-Port-Of: odoo/enterprise#32177

As the report lines are rounded differently for the taxes and the bases, when you simply multiply base * rate you can end up to a slight difference with the actual tax amount. The check now ensures that a very minimal error that is more likely to come from the rounding is allowed. As it seems it was the case pre-reportalypse Signed-off-by: Julien Alardot (jual) <jual@odoo.com> [IMP] l10n_be_reports: Put the control lines on another page Simple fix to add a page break before the con

As the report lines are rounded differently for the taxes and
the bases, when you simply multiply base * rate you can end up
to a slight difference with the actual tax amount.

The check now ensures that a very minimal error that is more likely to
come from the rounding is allowed. As it seems it was the case
pre-reportalypse

Signed-off-by: Julien Alardot (jual) <jual@odoo.com>

[IMP] l10n_be_reports: Put the control lines on another page
Simple fix to add a page break before the control_lines when
a page is printed

https://eservices.minfin.fgov.be/intervat/static/help/FR/regles_de_validation_d_une_declaration.htm

Signed-off-by: Julien Alardot (jual) <jual@odoo.com>

Forward-Port-Of: odoo/enterprise#32404

# [FIX] web: fix kanban useSortable screen width limit ## Reproduce: Go on a kanban view, with enough columns so it goes off the screens. Scroll on the right, try to drag anything beyond the original (before scrolling) limit of the screen. The cards are stuck floating at that limit. Note it didn't prevent the drop to work properly where the mouse was. ## Issue: The useSortable hook gets an owl ref, which is used as a limit to where things can be dragged and dropped. Originaly and logi

# [FIX] web: fix kanban useSortable screen width limit
## Reproduce:
Go on a kanban view, with enough columns so it goes off the screens.
Scroll on the right, try to drag anything beyond the original (before
scrolling) limit of the screen. The cards are stuck floating at that
limit. Note it didn't prevent the drop to work properly where the mouse
was.

## Issue:
The useSortable hook gets an owl ref, which is used as a limit to where
things can be dragged and dropped. Originaly and logically, it was the
current component ref, the renderer. But for some unknown reason, this
space was not getting wider than the initial screen size. It may be a
problem with the flexbox layout.

## Tried solutions:
- A first solution was to add the overflow-x-scroll css property to the
renderer. It works, but now the horizontal scroll bar is no longer
always visible. You have to scroll all the way down to see it. UX wise
this is not acceptable.

- We could remove the clamp mecanism inside useSortable to let the drag
and drop motion go anywhere. This works, but decrease the quality of the
interaction. It looks cheap and not polished.

## Final Solution
Finally, we decided to pass a ref to the o_content div from the layout
component down to the kanban renderer. If the useSortable is given this
ref, it works as intended. While it may seem too much, it is not
unreasonable to propose a reference to the most parent element of the
view contents to the renderer.

Community PR: https://github.com/odoo/odoo/pull/101763

Forward-Port-Of: odoo/enterprise#32478

Adapt the layout of the form view Steps to reproduce: * Open Planning * Click on a cell of the row Open Shifts => BUG Forward-Port-Of: odoo/enterprise#32504

Adapt the layout of the form view

Steps to reproduce:
* Open Planning
* Click on a cell of the row Open Shifts => BUG

Forward-Port-Of: odoo/enterprise#32504

*: cleaning, merge Forward-Port-Of: odoo/enterprise#32407

*: cleaning, merge

Forward-Port-Of: odoo/enterprise#32407

Reason for traceback: When an internal user clicks on the 'Sale Order', 'Invoice' or 'Ticket' state button, opens Backend view. But the portal backend does not support chatter. So comes the traceback. In this commit, we open the portal view. task-2973173 Forward-Port-Of: odoo/enterprise#31779

Reason for traceback:

When an internal user clicks on the 'Sale Order', 'Invoice' or 'Ticket' state button, opens
Backend view. But the portal backend does not support chatter. So comes the traceback.
In this commit, we open the portal view.

task-2973173

Forward-Port-Of: odoo/enterprise#31779

_* = industry_fsm, industry_fsm_sale, planning, helpdesk 1. industry_fsm{_sale}: change the visibility condition of the `Sign` button - Currently, the visibility of the `Sign` button is only dependent on the fact that a worksheet has been added. - This commit changes this condition so that it will be visible if a timesheet, a product or a worksheet is added. 2. improve the planning calendar front view This commit ensures that: - The buttons

_* = industry_fsm, industry_fsm_sale, planning, helpdesk

1. industry_fsm{_sale}: change the visibility condition of the `Sign` button
 
     - Currently, the visibility of the `Sign` button is only dependent on the fact
          that a worksheet has been added.
     - This commit changes this condition so that it will be visible if a timesheet,
        a product or a worksheet is added.

2. improve the planning calendar front view
       This commit ensures that:
     - The buttons displayed to start with a capital letter. in the planning  
      -    The no event message is no more display
     - We have used camel case letters in the planning calendar front view button and removed the 
       no event message.
      - Full calendar button label: Today, Month, Week, List
   
3. helpdesk
    - Remove the helpdesk team name form the customer rating

4. change planned dates visibility
      - As we want to encourage the use of the Gantt for planning tasks, the fields are removed from the form view.
      - As project sharing does not display the Gantt view, the fields are preserved in the form view but the visibility is changed so that they are only displayed when one of them are set.

task-2895909

Forward-Port-Of: odoo/enterprise#30006

When the german localisation is installed and we are not in a german company using fiscal module. The override of the function '_finalizeValidation' in Payment Screen does not correctly call the parent method. So we now check that we are in the german fiscal module conditions to call what is specific to this localisation. Forward-Port-Of: odoo/enterprise#32512

When the german localisation is installed and we are not in a german company using fiscal module. The override of the function '_finalizeValidation' in Payment Screen does not correctly call the parent method.

So we now check that we are in the german fiscal module conditions to call what is specific to this localisation.

Forward-Port-Of: odoo/enterprise#32512

It was unnecessary since FormViewDialog can be used instead now and error prone as it could be opened in many other ways. Forward-Port-Of: odoo/enterprise#32498

It was unnecessary since FormViewDialog can be used instead now and error prone as it could be opened in many other ways.

Forward-Port-Of: odoo/enterprise#32498

Steps to reproduce the bug: - Let's consider an helpdesk team HT with ID=1 - Let's consider a sales team ST with ID=1 - Delete ST - From the dashboard of Helpdesk app, create a ticket in HT - An window action will be call with context">{'default_team_id': active_id} - Create a customer on the fly by specifying his name and email - Save Bug: An error was raised because crm.team with ID=1 didn't exsit opw:2990781 Forward-Port-Of: odoo/enterprise#32021

Steps to reproduce the bug:

- Let's consider an helpdesk team HT with ID=1
- Let's consider a sales team ST with ID=1
- Delete ST
- From the dashboard of Helpdesk app, create a ticket in HT
- An window action will be call with context">{'default_team_id': active_id}
- Create a customer on the fly by specifying his name and email
- Save

Bug: An error was raised because crm.team with ID=1 didn't exsit

opw:2990781

Forward-Port-Of: odoo/enterprise#32021

The community commit modifies the way worked hours are calculated. This commit adapts some tests to it. task-2983993 related: https://github.com/odoo/odoo/pull/102392 Forward-Port-Of: odoo/enterprise#32378

The community commit modifies the way worked hours are calculated. This commit adapts some tests to it.

task-2983993
related: https://github.com/odoo/odoo/pull/102392

Forward-Port-Of: odoo/enterprise#32378

This commit removes the timesheet timer from the timesheet entries that are related to time-off. This removes the ability of the user to edit the timesheeted amount by running the timer. This is a small design overlook that now should make the timesheet app more robust to unexpected user input. task-3007842 Forward-Port-Of: odoo/enterprise#32357

This commit removes the timesheet timer from the timesheet entries that are related to time-off. This removes the ability of the user to edit the timesheeted amount by running the timer.

This is a small design overlook that now should make the timesheet app more robust to unexpected user input.

task-3007842

Forward-Port-Of: odoo/enterprise#32357

I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#32069

I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#32069

Purpose ======= Improve the UI and the redirection for logged in users. Specifications ============== Hide the livechat button from knowledge since it should not appear nor be accessible. Redirect anonymous users on the login page if they are trying to access an existing but unpublished article. To prevent a broken UI look, adapt the size of the portal users virality message and hide it on mobile devices. Task-2936605 Forward-Port-Of: odoo/enterprise#32462

Purpose
=======
Improve the UI and the redirection for logged in users.

Specifications
==============
Hide the livechat button from knowledge since it
should not appear nor be accessible.

Redirect anonymous users on the login page if
they are trying to access an existing but
unpublished article.

To prevent a broken UI look, adapt the size
of the portal users virality message and hide it on mobile devices.

Task-2936605

Forward-Port-Of: odoo/enterprise#32462