Commit 7fbb337e introduced performance slowdown when reconciling a
bank statement line with multiple invoices. This is due to the
compute function being called a lot of times and each time need to
trigger a search for CABA moves (even if the company do not use
cash basis).

This commit aims to not trigger the search if the company do not use
cash basis and add some domain conditions on indexed fields to speed up
the search when it's a cash basis company.

opw-3013391

closes odoo/odoo#106402

X-original-commit: 9d6db3af
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Co-authored-by: Arnaud-Sibille <arsi@odoo.com>

1/ When approving / refusing a leave spanning multiple days, the
   overtimes were only recomputed for the starting date and not the
   whole period.

2/ Overtimes should be computed whatever the kind of time off that's
   been taken (Absence or Other).

task-3073155

closes odoo/odoo#106298

Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#105637

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Provide a hook for clean specification of additional fields, without
relying on risky default dict method parameters.

Use the existing `_group_by_sale` to cleanly add additional
"group by" information.

Partial backport of 740a507d

closes odoo/odoo#105246

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>

Currently in Sale/Orders/Sales Teams menu , The Sales Analysis dashboard
have text overflow bug for large numbers in USD/EUR this bug might be
rare but in currency like Yuan or VND its common

closes odoo/odoo#104782

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Usecase to reproduce:
- Product A with Vendor supplier lead time=1day
- Product B with same Vendor supplier lead time=4days
- Launch the replenishment report for both products at the same time

Current Behavior:
The expected arrival is correct but the order date deadline is today - 3
days

Wanted Behavior:
Same but the order date dead line is today

It happens because it does the minimum of expected arrivals - max of
supplier delays. However the supplier delays are already correctly
apply on each procurement (correct expected arrival). To know the
correct order deadline we should instead take the minimum date planned
with the related supplier delay.

opw-2822588

closes odoo/odoo#90586

X-original-commit: 1d542b91
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

In large database with lot of user, the browser don't respond.

closes odoo/odoo#106631

X-original-commit: 0f597b3a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When creating draft deferred entries in a reconcilable account,
we should not attempt to reconcile them, because only posted entries
can be reconciled.

closes odoo/odoo#106565

X-original-commit: edaf019e
Signed-off-by: William André (wan) <wan@odoo.com>

In this commit [1] (merged in 16.0) a bugfix has been made in the
`removeSlide` function but this one should have been applied on all
supported versions because the bug it fixes is present on all versions.
The bug it fixes is the following:
- Drop a carousel block on a page
- Remove the *first* slide

=> There is no active indicator.

Moreover, the bugfix made in 16.0 [1] introduces another error: when a
slide is removed from the carousel the indicators are not in a correct
state anymore.

Following the same steps with the changes of [1]:
- Drop a carousel block on a page
- Remove a slide

=> Indicators are no longer consistent with the slides so tracebacks
appear during the carousel slides. The list of indicators must have on
each element a `data-slide-to` attribute which must reflect the
position of the slide (starting with 0).

So this commit is to backport the fix from 16.0 [1] to 14.0 and to fix
the new bug that [1] introduces.

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



task-3040931
opw-3051615

closes odoo/odoo#106611

X-original-commit: 16405934
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:

(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)

- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button

=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.

opw-2967706

closes odoo/odoo#106455

X-original-commit: 076d7ac7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Because of css limitation, the child of a parent that define a
text-decoration cannot "neutralize" that decoration defined by its
parent with a css property (ie. the text-decoration cannot be
overridden).

When a block define an inline style or any tag that have a class, the
method `formatSelection` tries to "neutralize" the style by calling
`addNeutralStyle`. As it is impossible to "neutralize" the style for
underline nor strikeThrough, there is no method `addNeutralStyle`
defined for those properties.

Before this commit the method `formatSelection` was crashing because
`addNeutralStyle` was not defined.

Task-3002123

closes odoo/odoo#105953

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Only active boms should be returned by the domain even if
they match a product id.

closes odoo/odoo#106449

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

closes odoo/odoo#106447

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Steps to reproduce:
- edit RFQ model with studio
- add a toggle widget to the product list
- activate/deactivate the toggle multiple times on different products

Bug:
sometimes the element on the widget is undefined when trying to rerender

Fix:
check the element is defined before trying to render it

opw-3013024

closes odoo/odoo#103186

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When a one2many is used as a search default, its label has to be fetch
via a name_get in order to get a correct display of the facet
corresponding to that field in the search bar. It turns out that the
search model did not wait properly the return of the name_gets before to
start to compute the facets.

closes odoo/odoo#106522

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

In Factur-X, there is no way to represent a tax "price_include" because
every amounts should be tax excluded.

Currently in Factur-X, a line with a tax price_include = True will be
incorrectly exported. Indeed, the Factur-X.xml is generated by setting the
GrossPriceProduct as the price_unit. In Factur-X, this amount (and the others
in the line details) should be tax excluded. Thus, it's wrong to set the
GrossPriceProduct as the price_unit.

To fix this, the GrossPriceProduct should be the price_unit if no tax
price_include = True is set, otherwise, the gross price = price_unit/(1+tax/100).

This way, the Factur-X file will be consistent with the norm.

Note that the import of a Factur-X xml will thus try to pick taxes with price_include = False,
and the price_unit will be tax excluded. If no matching tax with price_include = False is
retrieved, a tax with price_include = True is searched, if found, the price_unit is
recomputed accordingly. In both cases, the lines subtotals are the same.

opw-3032382

closes odoo/odoo#106465

X-original-commit: 649e0f2d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

- Currently the label of the lines is not limited to the number of characters. When the user gives a name that is too long, the graph will not be displayed.
- This commit limits the number of labels, if exceeded it will display as ...

closes odoo/odoo#106149

X-original-commit: 11dc2cec
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>

The default hours of a time off created from the Day view would be the
range of hours that was selected in the calendar view, thus resulting in
leaves of half an hour.

closes odoo/odoo#106513

Signed-off-by: Kevin Baptiste <kba@odoo.com>

update to this PR[1]

BUG:
some discounts are still displayed on the middle of the order

FIX:
move all discounts to the end

[1]:https://github.com/odoo/odoo/pull/102700


opw-2985632

closes odoo/odoo#106508

X-original-commit: af8cc475
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

This reverts commit https://github.com/odoo/odoo/pull/106401/commits/bff333873c77e4879f6b991ed67ed9986f8dbf8e



It was not a bug.
Users are automatically added to the Time Off Responsible group when they are added as approvers on an employee
If the user does not have the access rights it is because they have been manually removed.

opw-3062225

closes odoo/odoo#106505

Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#106466

X-original-commit: 94dd698d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>

Before this commit:
 If we remove a payment line using an Adyen payment method,
 `pending_adyen_line()` return `undefined`.
 With the `_poll_for_response` still being executed,
 it will pop some JS traceback each call with:
 ```js
 TypeError: Cannot read properties of undefined (reading 'terminalServiceId')
 ```

After this commit:
 No JS traceback loop

OPW-3032391

closes odoo/odoo#106431

X-original-commit: 52a517ca
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

PG12 introduced an optimization for CTEs that automatically inlines
CTEs if they are only refered once in the parent query. Prior to that
CTEs were always materialzed, meaning that PG created a sort of temp
table on the fly to store the result of the CTE's evaluation.

Whereas this leads to performance improvements in general, in the
particular case of _select_companies_rates this inlining becomes a
performance bottleneck. This is because while the currency_rate CTE
is only refered once in both purchase_report and product_margin,
the join condition (cr.date_end is null or cr.date_end > ...)
requires evaluating the CTE's date_end subquery twice. This, combined
with the fact that in PG12 the planner goes for a Nested Loop JOIN instead
of a HASH Join in PG10 makes the performances of the whole query
much worse in PG12 than in PG10.

Adding an ORDER BY (or an OFFSET 0, the resulting plan is the same)
creates a kind of optimization fence that forces PG to evaluate the
subquery first using its own plan. This removes the need to rescan the
subquery each time the Merge JOIN filter has to be applied, which
is a good strategy in this specific situation.

The same result could be achieved by adding the keyword "MATERIALIZED"
in the CTE definition. The issue is that this keyword did not exist
in PG 10 so using it would require to check the PG version at runtime
from python.

Examples of query timings change before and after PR:

Number of POs | Before PR | After PR
      2000    |     7s    |    345ms
      7000    |     23s   |    1.1s

opw-2930578

closes odoo/odoo#106086

X-original-commit: 8b7a3941
Signed-off-by: Raphael Collet <rco@odoo.com>

Bug:
- enable wave transfers
- Kanban view should not have a create button

Fix:
removed the button

opw-2978078

closes odoo/odoo#99970

Signed-off-by: Adrien Widart <awt@odoo.com>

First correction: force a simple order to `read_group` in order to avoid
useless joints on table product_template and ir_translation when the
grouping key is a Many2One.

Second correction: add an index on workorder's `state` field. The
get_conflicted_workorder_ids() method search for ready workorders that
are in conflict relate to their planning. The state value is searched to
many times to not index it

closes odoo/odoo#106436

Task: 2852423
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

The user could make the mistake to put a large number in the `Guests`
input in the POS order and this is not validated, even an number more large
for the capacity of an integer, raising an uncontrolled error:

`psycopg2.errors.NumericValueOutOfRange: integer out of range`

this commit is adding a validation error in order to limit the number of `Guests`
with the maximum number for an integer:  2**31 - 1

closes odoo/odoo#105393

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Steps to reproduce:
    - install the "hr_holidays" module;
    - remove the "Time Off Responsible" group of a user (activate developer mode);
    Remark: the user must not be an "Administrator" or a "Time Off Officer"
    - for an employee add this user as approvers for time off;
    - with a user which matches the employee, request time off;
    - if the user, whose rights have been removed, has "Handle in Odoo" in his preferences, he will receive a notification;
    - try to approve the demand of employee leave.

Issue:
    The user does not have access rights but he has been chosen as approver.

Cause:
    It is possible to select any user to approve leaves without checking if he has the access rights.

Solution:
    Add a domain to be able to select only users who are in the "Time Off Responsible" group.

opw-3062225

closes odoo/odoo#106401

Signed-off-by: Kevin Baptiste <kba@odoo.com>

If the method `_auto_install_l10n` is called programmatically on a DB
where the localization has already been installed, useless processing is
performed by `button_install`.

Do not call this method if no module need to be installed.

closes odoo/odoo#106381

X-original-commit: 11e9d3f1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Commit 40b32b39 open the bom overiew
report with a fallback to the product template in case the bom is a
defined on a template without any variant (the product template has
dynamic attribute variant).

This commit adapts the product model (product or template) on report's
links

closes odoo/odoo#106349

Related: odoo/enterprise#34314
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce:
- Create a price list with different currency and discount with "show price and discount to the customer"
- On the website select this pricelist and try to select the booth

Issue:
The displayed price will not be the correct one

Note:
This is an issue discovered during the correction of https://github.com/odoo/odoo/pull/101375 (forward-port of https://github.com/odoo/odoo/pull/85640

)
It allows to have the correct price depending of the currency of the pricelist applied.
Now the unlink of the rate makes the new rate directlt effective. There is no need of having a `new_company` anymore.

Summary:
- view modification in `website_event_booth_sale` -> price of selected booth,  simplification of comparison for the `<del>`
- view modification in `website_event_sale` : simplification of comparison for the `<del>`
- backend test modification in `website_event_[booth_]sale` common: addapt the rate; take out useless `new_env`; simplified pricelists creation
- tour test addition:  added the tour for essential use cases in event and event_booth; simplified the command so it is more readable

related ticket:
opw-2766997

closes odoo/odoo#101559

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

The method `package_without_carrier` depends on `package_carrier_type`

closes odoo/odoo#106378

Signed-off-by: Adrien Widart <awt@odoo.com>

After this [commit](https://github.com/odoo/odoo/commit/f6ceac07a077531c873f0715b8de5c384bb06ae5

),
when the user clicks on `Orders` in a session of a POS,
the method is retrieving the all orders from backend to the POS
and it's calling to the backend one time per each
table per each floor configured in the POS.

Then if you have 4 floors, with 30 tables on each floor,
only by clicking in Orders,
it calls 120 times the method to the backend.

With this change, only one call is made to open Orders and synchronize
the orders from server

closes odoo/odoo#104930

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

On large database this can take 700 ms per moves. After a few ms.

closes odoo/odoo#106361

X-original-commit: c9209664
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Co-authored-by: Laurent Smet <las@openerp.com>

On the ticket https://github.com/odoo/odoo/pull/101547

 a constraint was added to prevent the user from changing the product type if some moves have already been made.
This was done because changing the type creates inconsistencies (like breaking the valuation).
However, it currently only checks if there are moves on the current company, when it should check in all companies.
This can be fixed by adding sudo.

closes odoo/odoo#106320

X-original-commit: e8bb4a50
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

This fix moves the logic of this commit (#d5330c2f) to the correct
module.

opw-3049098

closes odoo/odoo#106327

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Steps to reproduce the bug:
- Create a storable product “P1”:
    - Variant: Color: Black and white
    - BOM 1:
        - product variant: P1 - White
        - Type: Kit
        - Consumable: C1
     - BOM 2:
        - product variant: P1 - Black
        - Type: Kit
        - Consumable: C1
- Create another kit product “P2” without variants

- Create an SO:
    - Add “P1 - white”, “P1 - black”, “P2”
    - Confirm the SO

- Go to the delivery → validate it Print the delivery slip

Problem:
only product "P2" is displayed in the report.

The `product_id.name` is used as `move.name`:
https://github.com/odoo/odoo/blob/16.0/addons/sale_stock/models/sale_order_line.py#L333



but then only compare it with the name of the `product_template` set in
the bill of material to filter the moves.

Solution:
Check if the `move.name` is equal to the `product_id.display_name`
set in the bill of materialale au product_id set dans la bill of
material.

opw-3051639
opw-3047822

closes odoo/odoo#105490

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Non EU vendor bills are sent to the Tax Agency as self-invoices,
so the partner actually is the seller, but the same checks on the
VAT must apply as it was the buyer.

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#106285

X-original-commit: 8c18b870
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>

closes odoo/odoo#105388

Signed-off-by: Masereel Pierre <pim@odoo.com>

The dimensions UoM of the carrier packaging is useless: it is not the
one used in the requests and there is not any conversion

To reproduce the issue
(Need delivery_fedex. Use demo data. Enable debug mode)
1. In Shipping Methods, edit 'Fedex US':
    - Package Weight Unit: KG
    - Debug Requests: True
2. Edit its Fedex Package Type:
    - Height: 1m
    - Width: 1m
    - Length: 1m
    - Package Code: YOUR_PACKAGING
3. Create a SO with a US partner and one product
4. On the SO
    - Add Shipping
    - Select 'Fedex US'
    - Click on 'Get Rate'
5. In Logging, open the request sent

Error: the dimensions of the packaging are expressed with "CM" but they
are not converted:
```xml
<ns0:Dimensions>
	<ns0:Length>1</ns0:Length>
	<ns0:Width>1</ns0:Width>
	<ns0:Height>1</ns0:Height>
	<ns0:Units>CM</ns0:Units>
</ns0:Dimensions>
```

When encoding the packaging in the request, the UoM defined on the
packaging (meter) is ignored. Instead, we define a length UoM depending
on the UoM of the weight and we don't convert any dimension:
https://github.com/odoo/enterprise/blob/e4fd13a0e073b9855864b7fabc26bc05b9a5fd19/delivery_fedex/models/fedex_request.py#L172-L178
There is even a `TODO` about the issue.

It will be the same with the other carriers. For instance, with UPS:
https://github.com/odoo/enterprise/blob/c9899f7860cd19c86f215d6dcea89f73b51433f3/delivery_ups/models/ups_request.py#L98-L102


We use the UoM of `ups_package_dimension_unit` and do not convert the
dimensions.

We can't implement the dimensions conversion on stable versions, since
it will break all existing packagings. So, as temporary solution, we can
simply hide the useless UoM defined on the packagings.

OPW-3053048

closes odoo/odoo#106268

X-original-commit: 35107443
Related: odoo/enterprise#34248
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>