The tooling has been introduce in later version of odoo.
It is a problem when somebody switches to older branches without
disabling the tooling as it would then try to commit the tooling config
files.

We just add a few lines in the gitignore to prevent this issue.

closes odoo/odoo#106896

X-original-commit: 15012151
Related: odoo/enterprise#34526
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Steps to reproduce:
- Setup product (
    cost 10$
    Storeable Product
    Standard Price Accounting
    automated valuation
    add account for price difference
)

- Purchase product in foreign currency (set a different price)
- Receive the product
- Create and validate Bill

Bug:
The reception JE is for the cost amount set on the product ($10)
debit and credit value are correct but the amount in currency
is wrong (purchase cost)

After creating the bill the Journal items are not correctly matched
since reconciliation is done on currency amount in the case fo foreign
currency transaction

Fix:
Set the correct amount (cost configured on product page)
in currency amount if costing method is standard

opw-2822366

closes odoo/odoo#106833

X-original-commit: 822b5f88
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Some commands from the powerBox command bar were not working
properly in the e-shop product "terms and conditions" section.

This was due to the isolation of Odoo fields
inside the odoo editor as a all.
Those fields do not always have an editable block element
to apply the command on.

We disable some commands that should not be apear in this context.

We also remove a redundant command (separator) in website pages.

task-2962067

closes odoo/odoo#106348

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

This commit description is in three parts: a generic explanation, a real
use case and the solutions

**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
   https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
   Then, there are two possibilities:
   1. If such environment already exists in the environments list of the
transaction, we reuse it:
      https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
   2. Else, we create a new one and store it in the transaction:
      https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
   https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
   It means that its value won't be recomputed unless we delete it
   https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
   https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
   The functions are added in a stack. So, in the execution order, we
will
   1. Clear the current environment and the registry
   2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
   1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
   2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
   1. E1 is reset (but its lazy properties are not deleted)
   2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)

**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
  https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
  https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316


- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```

**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.

So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.

C1 a40511cd

closes odoo/odoo#106810

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

Steps to reproduce:

1- install ecommerce - payment_stripe
2- configure stripe testing credentials
3- edit main currency to have more decimal places (assume 4 instead
of 2 for USD)
4- add product p to cart (assume p.price = 100 USD)
5- checkout with stripe
6- the price is 10,000 USD instead of 100 USD

Bug:

Stripe expects the amount in the smallest unit possible for the
currency. https://stripe.com/docs/currencies#zero-decimal

This differs from a currency to another according to
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions

`to_minor_currency_units` uses the decimal places of the currency by
default which will produce wrong values

Fix:

use currency exponent table built from
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions



default behavior (for a currency that is not available) is not changed

OPW-3058173

closes odoo/odoo#106130

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Previously, it was only possible to upload a bill, so the partner_id was read
from the vendor in the imported file. Now, it is also possible to upload a
file to create an invoice, so we need to be able to decode the customer in
the imported file.

opw-3072989

closes odoo/odoo#106829

X-original-commit: 7eb401e3
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

If you clicked on a pictogram, then previewed various colors for it by
hovering colors in the colorpicker of the toolbar, the toolbar started
flickering uncomfortably. That's because the selection was changed
at every color change, which was unnecessary.

closes odoo/odoo#106788

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

If you clicked on a pictogram, then changed its color with the text
colorpicker in the toolbar, the toolbar was replaced with the regular
text toolbar, even though what was being edited was the pictogram.
That's because the information of the last media clicked was lost in the
process.

task-3045166

Part-of: odoo/odoo#106788

Since [1] when the search bar was refactored, images can be displayed in
the autocomplete results, and fallback icons are displayed instead of
images for records that have no images.
However, if no module that participates in the results provides actual
images, then the fallback icons are not displayed at all.

This commit makes the fallback icons displayed only based on the "Image"
toggle option of the search bar.
It also disables the hidden display options and enables the visible
ones.

Steps to reproduce:
- Do NOT install website_sale (which is currently the only module that
provides autocomplete results with images).
- Drop a "Search" block.
- Save.
- Type a single letter in the search box. (e.g. "a")
=> Autocomplete results were displayed without their icons.

[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986



task-2951026

closes odoo/odoo#98241

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Comment nodes don't have a `closest` method so when passing one to
`closestElement`, the method crashed.

----

Step to reproduce in website:
- Go to debug mode and to website app
- Click on configuration > websites
- Select a website and in the `custom_code_footer` field add an HTML
  comment
- Go to the website and try to enter edit mode -> Crash

The same error will be visible if you simply enter edit mode and drag &
drop the "Code" snippet and enter an HTML comment inside it.

-----

Step to reproduce in marketing automation:
- Install marketing automation
- Click on a campaign > Add a new activity
- On the mail template field, type something > Create and edit
- Select plain text -> `element.closest is not a function`

----

task-3083797
opw-3081323
opw-3081278a

closes odoo/odoo#106741

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

Bug
===
Currently, we try to enrich the domains even if they are in the
`_MAIL_DOMAIN_BLACKLIST`. IAP always return a "missing data" error
because it can't enrich "gmail.com", etc except for "odoo.com". In that
case the enrichment is successful, but because the domain is
blacklisted, we use the entire email to find the company (and so it
will create a company for each odoo.com email addresses).

The test that was removed was wrong. It works because we mocked the
enrichment response, but in practice it will always return a missing
data error.

Task-3050230

closes odoo/odoo#104621

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

Steps to reproduce:

- Open an invoice
- Enter a long link without spaces in the terms and conditions field
- Save

Issue:
The word doesn't break and spans outside its bounding box, possibly
overlapping with the subtotal footer on the right.

Solution:
Add class `text-break` to the narration field.

opw-3050054

closes odoo/odoo#106625

X-original-commit: 1484765c
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>

When breaking a page from a Carousel or other slider snippet (eg by
hitting the backspace key at the beginning of a page), the editor's
history gets reverted but ends up applying the `active` class to all
pages. This is due is some way to the `_computeHeights` method of the
slider snippet, which applied the class to all pages to observe their
heights, then put them back in place. It seems in the labyrinth of ticks
the history step somehow started from a place where every page was
active, so we reverted back to that. The point where these classes were
applied should have never been observed in the first place since it's
purely technical. Not observing it fixes the bug.

task-3081259

closes odoo/odoo#106696

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

Reproduction:
1. Install Expense, make sure in the product list of test data, we have
Expenses(without cost e.g. 0.00) and Daily Allowance(with cost e.g. 100)
2. Create a new expense with the product Daily Allowance, and attach a
file to the attachment, save expense
3. Edit the created expense, change the product to Expenses and save
4. The UI is not changed and can’t edit the total amount of the expense

Reason: the recomputation of product_has_cost is based on the
unit_amount. However, when there’s an attachment, the recomputation of
unit_amount doesn’t consider the case when the product is changed to one
without standard_price (unit_amount).

Fix: add a condition to make sure when the product is changed from one
with standard_price to one without standard_price, the unit_amount of
expense is recomputed correctly

opw-3051726

Related commit: https://github.com/odoo-dev/odoo/commit/918a5f2cc022994ee08bead25dd79072bf3fba87



closes odoo/odoo#106660

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

Simple refactor in order to make changes to these line trigger the CI/Security

closes odoo/odoo#106309

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

*: website_sale_wishlist

Commit [1] and [2] introduced test tours but did not mark them as test
tours properly, thus showing them to users (who are in debug=tests mode)
by mistake.

[1]: https://github.com/odoo/odoo/commit/7655bface7f9e9bae8579e14e9a87b4f4801cc33
[2]: https://github.com/odoo/odoo/commit/a0c33c5f896718d1c03a6a50c981d6d75ce0d169



closes odoo/odoo#106678

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

Reproduction:
1. Install eCommerce, Events, in the settings of Events, toggle
“Tickets” and “Online Ticketing”
2. Go to Website -> Go to Website -> Event, at the top bar, Customize ->
Track Visitor, turn it off
3. Click on the event “Open wood collection”, also turn off “Track
Visitor”
4. Click on the register button for this event, also turn off “Track
Visitor”
5. Copy the URL of the registration page, open it in an incognito tab.
Don’t go through from the beginning of the main website
6. Register a standard free ticket, enter the information, and click
confirm
7. The website throws a 404 not found error

Reason: when we turn off “Track Visitor” on the event registration page.
If we directly access the registration page, the created visitor’s
access token is not written in the cookies. Thus, when we call
_get_visitor_from_request after redirecting to
event_registration_success, the visitor isn’t retrieved and it causes a
404 not found error. A detailed case study is attached below.

Fix: before the redirection of successful registration, we check if the
logged visitor_uuid is the same as created visitor’s access token. If
not, e.g. the visitor_uuid is not logged, we log it in cookies.

opw-2828682

closes odoo/odoo#101635

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

When an SVG element changes and is filtered by the
`filterMutationRecords` method, the method tries to split its
className (Since [1]). This is not supported by the browser however,
because the className property of an SVGElement is not a String.
Rather, it is an SVGAnimatedString [2].

This commit fixes that by using the getAttribute method instead.
Ensuring that the attribute returned is always a String.

[1]: https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d
[2]: https://developer.mozilla.org/en-US/docs/Web/API/SVGAnimatedString



opw-3077287
opw-3074434

closes odoo/odoo#106671

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

closes odoo/odoo#106646

Related: odoo/enterprise#34433
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Before this commit:
1. Create PO with quantity 10, confirm (creates receipt-1)
2. Receive 2 quantities on first receipt (receipt-1), backorder (receipt-1 is 'done', creates receipt-2)
3. Receive 3 quantities on second receipt (receipt-2), backorder (receipt-2 is 'done', creates receipt-3)
4. Change quantity to 5 in PO
5. An exception is created on all receipts (1, 2 and 3)

In the scenario above, receipt-1 and receipt-2 are partial receipts that are set to 'done'.
It is not necessary to create an exception in these receipts when the quantity is changed to less than originally expected in the PO.
Since the system checks that the new quantity has to be equal or greater than the received quantities, the already received quantities cannot be impacted.

After this commit:
The exception is only propagated to the receipts that are not done.
e.g. in the example above, an exception appears only in receipt-3.

task-2648209

resolves #76297

closes odoo/odoo#106597

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

Before this PR Odoo don't pre-search on location.

closes odoo/odoo#106576

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

Current behavior:
When splitting the order in a pos_restaurant session, the order was not
correctly saved in the backend. It resulted in an order that still had
all the product of the original order and another order with the
correctly splitted products.

Steps to reproduce:
- Start a pos_restaurant session.
- Go to table A and add 3 products to the table.
- Go back to the floor screen
- Go back to the table A
- Split the order in 2
- Click on payment, and go back to the product screen without paying
- Click on the ticket button, and click on the order that was splitted,
  it still contains all the products from the original order.

opw-3061569

closes odoo/odoo#106553

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

Stepts to reproduce:

Go to Time-off app > configuration > Public Holidays.
Try to create a new holiday and select working hours.

Issue:

It will show up all the working hours available for all companies even
if we are not in that company at the moment.

Solution:

We need to take into account the company for this field in order to only
show the working hours available for this specific company. I've added
to the field the `domain="[('company_id', 'in', [company_id, False])]"`
in order to follow the same behavior as next versions.

This issue affects 15.0 and saas-15.2

opw-3068827

closes odoo/odoo#106415

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

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>