Invalid taxes could lead to invalid results from the
`_prepare_edi_tax_details` fonction. For instance: a tax without tax
repartition lines will be disregarded, which in turns leads to an
invalid xml being generated.

opw-3175701

closes odoo/odoo#116359

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

Steps to reproduce:
Launch a contract which has an end date
scheduled for the next day for an employee
and manually activate the "HR Contract: update state" cron.

Issue:
Running contracts are closed one day in advance.

Solution:
Correct the condition which selects contracts to close.

opw-3217616

closes odoo/odoo#116346

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

Step to reproduce:

1. create a product
2. duplicate it and change its translation (but DO NOT change the product name)
3. create a transfer for that new product without a contact
4. print delivery slip

Bug:
the db's product name is used instead of the translated name
(i.e. "original product name (copy)")

FIX:
when partner id is not set in picking, then default to the user's language

opw-3141202

closes odoo/odoo#116392

Signed-off-by: Tiffany Chang <tic@odoo.com>

In case we retrieve the maximum number of documents the IAP server
can send, we retrigger the cron to receive more documents, until
we get them all.

Parameter `recipient_codice_fiscale` wasn't used at all, download is
related to the proxy user which is determined by authentication on the
IAP proxy.

See odoo/iap-apps#583

closes odoo/odoo#116373

Signed-off-by: Josse Colpaert <jco@odoo.com>

Create an misc journal entry with 1000 as debit and a tax.
The tax line is linked to a refund tax repartition line.

Open the manual reconciliation widget and do the same.
The tax line is linked to an invoice tax repartition line.

When dealing with tax grids, the resulting tags set on the journal items are not the same.
This is because the given price_unit is not following the sign of the debit/credit column.
Indeed, a positive amount means you are adding something on the credit column.

opw-3236208

closes odoo/odoo#116387

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

HTTPS certificate IoT issues can be complicated to troubleshoot
as the information are not visible/given.
This PR aim to share this information on the IoT box homepage.
As there is a lot of possible causes for a given problem,
a code is used that will be explained/detailed in Odoo's
IoT documentation:
https://github.com/odoo/documentation/pull/3818



OPW-3227004

closes odoo/odoo#114993

Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>

Register a ph contact with vat 123-456-789-012
Validation Error will raise

Currently we use check the PH vat against regexp \d{3}-\d{3}-\d{3}-\d{5}
This seems to be not correct according to the official documentation
https://serp-p.pids.gov.ph/publication/public/view?slug=taxpayer-identification-number-tin-its-development-and-importance-in-tax-administration



"""
12 digit number (E.g. 123 456 789 002), of which the first digit
identifies type of taxpayer (0 for corporations, 1-9 for individuals
and other businesses), second to eighth digits are sequential numbers
between 0 and 9, ninth digit is a check number, last three digits are
000 for individuals and head office of businesses and 001-999 for
branches of businesses, if any
"""

The TIN should be a 9 digit code + 3 for the branch code

opw-3141793

closes odoo/odoo#111519

Signed-off-by: Josse Colpaert <jco@odoo.com>

Insteadeither is added without space, adding spacing between the words.

Insteadeither  --> Instead either

closes odoo/odoo#115319

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

Steps to reproduce:
- have a damaged pdf (such as in the ticket)
- Create Bill B and attach it to it
- in the list view of bills select multiple bills
- Print - Original Bills
-> Error => Ok
- Select only the Bill B
- Print - Original Bills

Issue:
You cannot print only one invoice

Cause:
Since https://github.com/odoo/odoo/commit/266a8e2a8abf936d5fbd45752ddf492d92e6a397


we are checking if the PDF's are readable before trying to merge them.
But in this case, since there is only one PDF, we don't want to
merge it

Solution:
Skip the readable_pdf check for only one pdf

opw-3142646

closes odoo/odoo#114576

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Odoo 14 uses BS v4.3.1
but `col-sm-offset-3` is a is BS class version 3 causing
a error in the message alignment because the offset in BS
4 is `offset-sm-3`

closes odoo/odoo#116142

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

Before this commit, the compute method was not returning the value for the
field karma_flag field, and thus it was returning compute method failed to
assign value error.

After this commit, the compute method will return correctly set the value
for karma_flag field from the forum.

closes odoo/odoo#116141

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

This commit fixes several bugs with the navbar and the header templates:

- The "right" alignment options didn't work with most headers. This was
due to a missing CSS rule.

- The "right/left" alignment option was reversed with the "vertical"
header template.

- The navbar collapse style was broken with the "Hamburger Full" header
template.

- This commit hides the alignment options in cases where they have no
effect ("Hamburger Full" or "Magazine" header template + not
"off-canvas"). It also changes the options label to "Mobile Alignment"
when the alignment only impacts the mobile view (since this commit =>
[1], the "alignment" option no longer only impacts the mobile view,
depending on the templates, it can also impact the "desktop" view).

- The text section of the "Magazine" header template had no background
color (It was transparent after scrolling the page).

- The "off-canvas" navbar was not positioned correctly with several
header templates (e.g. "Boxed" header template).

[1]: https://github.com/odoo/odoo/commit/2a1aa808e939eeaa3caec6a1a82e19f023f1d010



opw-2951315

closes odoo/odoo#106764

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

Before this commit, the sub-menus that appear when the mouse hovers them
were not displayed correctly. The public widget which is in charge of
positioning the sub-menu (`menuDirection`) could not work because the
dropdowns were opened manually (which is not recommended) and so, the
`show.bs.dropdown` event was never triggered which prevented the public
widget from aligning the sub-menu items correctly.

Steps to reproduce the bug:
- Have a long sub-menu in the last position of the navbar.
- In edit mode align the navbar elements to the right.
- Enable the option to have the sub-menus displayed at hover.
- Save the page.

=> When hovering the sub-menu, it opens on the right and overflows the
page while there is enough space on the left.

task-2904507

closes odoo/odoo#115153

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

Since [this commit], some JS code tries to open the sub-menus in the
right direction so that the page overflow is limited. Unfortunately,
languages that read from right to left (RTL) were not supported by this
code, which left some sub-menus of the navbar overflowing when there was
room to open them without overflowing (on the other side).
Steps to reproduce the bug:
- Have a sub-menu in the last but one position of the navbar with long
strings of characters.
- Align navbar items to the right.
- Have an RTL language installed on your website.

=> When you open the sub-menu in RTL, it opens on the wrong side and
causes an overflow of the page.

[this commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438

task-2904507

Part-of: odoo/odoo#115153

Current behavior:
When a discount is applied on a product because of a pricelist. The base
price is displayed without applying the default pricelist on it.

Steps to reproduce:
- Create product A with price of 10€
- Create pricelsit PL1 that change price of product A to 7€(fixed price)
- Create pricelist PL2 based on PL1 that use a formula to apply 10% on
  all products.
- Change PoS default pricelist to PL1 and make PL1 and PL2 available on
  the PoS.
- Open a PoS session and add product A to the order. Price should be 7€.
- Apply PL2 on the order.
- The product line shows that the price was 10€ has been discounted to
  6.30€. The base price should be 7€.

opw-3200027

closes odoo/odoo#115368

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

This issue was caught in sentry.
When we try to create or update an invoice by uploading an `.xlsx` attachment,
it raises an Error as it will go to convert it into XML tree because the
concerned LOC will check `xml` in `mimetype` of attachment which is
`application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`.

sentry-3929855076

closes odoo/odoo#115653

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

Same issue as in https://github.com/odoo/odoo/pull/80263

, but for allowed account types.

Lines with the `display_type` field assigned, are sections or notes which do not even have an associated account, thus they should not raise the constraint error.

closes odoo/odoo#115269

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

When a delivered product was owned by an external partner, we should not
generate any COGS line

OPW-2884211

Backport of 47734939
OPW-3151987
OPW-3164944

closes odoo/odoo#115731

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

.. to other deeper logic.

As spotted on the ticket, if there is an ARCHIVED outgoing
email server and an invoice is created after clicking
on the smart button  of a Contact,
the active_test=False is propagated and the email is sent
using the archived outgoing mail server.

The propagation of this context key can impact a lot of
other logic and is even more risky in accounting.

Reverting fe9b460d29d6537e0c14af54ba31d935c746810b
is solving the issue.
The main error reported on 2853525 that led to this previous
commit seems also solved somewhere else (that I did not find)

opw-3217999

closes odoo/odoo#115894

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

Issue:

- Go to website > edit mode > add a form
- On one of the form fields, add a placeholder > save
- Change language > translate > impossible to translate the placeholder.

The fix on [1] was added to prevent interacting with inputs in editable
zones. This prevents translating attributes on those inputs too (using
the AttributeTranslateDialog) so the goal of this commit is to add
an exception to the restriction in [1], when input attributes are
translated.

[1]: https://github.com/odoo/odoo/commit/3e598a8014966e1a07a08d53bf85050b458e05a6



task-3042522

closes odoo/odoo#106198

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Current behavior:
If you create a product tracked by serial number and set an owner on the
product. If you make an order from the PoS with this product, the owner
wouldn't be set correctly on the picking created from the PoS.

Steps to reproduce:
- Create product A, tracked by serial number, storable, and available in
    the PoS.
- Add some quantity of product A with an owner (e.g. "Owner A").
- Create a PoS order with product A.
- Validate the order.
- Close the PoS session, go to the picking created from the PoS order
  there will not be any owner set on the picking.

opw-3206618

closes odoo/odoo#115199

Signed-off-by: Engels Robin (roen) <roen@odoo.com>

So fat, the default sale and purchase taxes were so on the
account.accounts depending on the user type id.
These taxes were meant to be used as default taxes on products
and not accounts, so this is not right.
It also is an issue since the default tax isn't visible
on the COA list until the user add it from the optional fields.

Task id # 3223731

closes odoo/odoo#114892

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

In the Accounting app, on the Dashboard in the 'Customer Invoices' card, the indicator 'to check' has incorrect amount when multi currency is activated.

Step to reproduce the issue:
 - create an invoice in another currency than the one of the company
 - check the dashboard of Accounting

 Result: the amount displayed is the one on the invoice but we want the converted amount.

 Original feedback: https://www.odoo.com/web#id=3212264&menu_id=4720&cids=1&action=333&active_id=809&model=project.task&view_type=form



 task: 3215921

closes odoo/odoo#114432

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Before this commit, error messages appeared when a user tried to put an
unsupported video on a page of his website, but the user could still add
this bad video on his page, which broke it.

Steps to reproduce the bug fixed by this commit:
- On a page of a website in edit mode, double-click on an image.
- Go to the video tab and type an unsupported URL like google.com.

=> An error message appears but the user can still add the media on his
page which will break it.

opw-3167707

closes odoo/odoo#114959

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

`Account.move.line` contains a stored related field called `parent_state` which relates to `move_id.state`. This allows for performance improvements by accessing that instead of `move_id.state`.

However, across odoo and enterprise `account.move.line` is domained against `move_id.state`.

This can produce an unnecessary left join on SQL queries for reports or other queries when instead it could use the stored field directly.

To accomplish this fix, we adjust domains to refer to 'parent_state' instead of `move_id.state`

While this PR will adjust multiple modules to fix this domain, it should improve SQL queries over large tables when a left join is no-longer necessary.

opw-3178866

closes odoo/odoo#114730

Related: odoo/enterprise#37939
Signed-off-by: William André (wan) <wan@odoo.com>

Current behavior:
When no account is set on a product category, you cannot close a POS
session. This happens because we are not using the default account set
on the POS journal in this case.

Steps to reproduce:
- Create product A, and product category B that has no account set on it
- Open a POS session, add product A. Validate the order
- Close the POS session, you will get an error message.

opw-3178181

closes odoo/odoo#115231

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

Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).

When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.

When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.

To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.

task-3147271

closes odoo/odoo#111719

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a second warehouse WH02
   - Let WH01 be the existing one
3. Create two storable products P_compo, P_finished
4. Create a BoM:
   - Product: P_finished
   - Components: 1 x P_compo
   - Operation Type: "WH02: Manufacturing"
5. Create a MO:
   - Product: P_finished

Error: Once the product is set, nothing defines the BoM (and
therefore the components, picking type, and so on)

When opening the MO form, the picking type is directly defined with
"WH01: Manufacturing". Therefore, when looking for a BoM, we use
that picking type as criteria -> we will not find the BoM of step 4

Notes about the fix:
- Small behaviour change: once the picking type is set, it does not
change automaticaly (whatever the BoM is)

OPW-3122384

closes odoo/odoo#114816

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

On big databases, it is possible that some setups will create huge queries when trying to apply reconciliation models. In such cases, the query might take a very long time to run, essentially eating up all the available CPU, and proof impossible to kill, because of the type of operations ran by SQL.

To alleviate that, we introduce a new config parameter, allowing cutting the list of statement lines to match into slices, and running the matching in multiple queries. This way, we avoid server overload, giving the ability to kill the process if takes too long.

closes odoo/odoo#114809

Signed-off-by: Laurent Smet <las@odoo.com>

Steps to reproduce:
-Enable multistep routes for manufacturing
-create a MO for 50 products
-In internal transfers from Stock to Pre-production validate
part of the tansfer (20 units) and create a back order
for the remaining qty (30 units)
-create and validate another pertail transfer (3 units)with a back order
for the remaining quantity (27 units)
-create a return for the last validated transfers

Bug:
the default qty for the return is set to -20 where it should be 3
this commit[1] deducts the previous transfers from the returned amount

Fix:
only deduct returns from current transfer

opw-3104699
[1]:https://github.com/odoo/odoo/commit/7b08f0ae0a39e8f575b21e744de16264b6365704



closes odoo/odoo#115110

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

This commit fixes a regression introduced in https://github.com/odoo/odoo/pull/104323

.

That fix was preventing the default behavior of the 1st `.oe_login_form button[type=submit]` found.

It turns out that, for allowing the mail plugin to work, you actually need to have the default behavior of that element working normally.

Without this patch, the `&do=1` query is never added to the POST parameters. Thus, the user is unable to authorize their mail plugin.

@moduon MT-2552 MT-2553 OPW-3230686

closes odoo/odoo#115198

Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

To reproduce the issue:
1. Create a product:
   - Type: Storable
   - Category:
     - Costing Method: AVCO
2. IN 2 @ 4.63/u
3. IN 5 @ 3.04/u
4. OUT 0.1
5. Repeat step 4 70 time in total, so that the final quantity is 0
6. Open the inventory valuation of the product

Error: the total value is $-0.04 instead of $0.
The compensation of rounding issue is stuck by a check that ensure we don't erase a valuation error.

However, this check can never succeed with small quantities, here is the mathematical proof:
°Current check: rounding_error <= qty * curr_rounding / 2
With:
1) rounding_error >= curr_rounding
2) 0 < qty < 2
3) v1 = rounding_error / curr_rounding
4) v2 = qty / 2
We can be sure that:
5) v1 >= 1 because of 1)
6) v2 < 1 because of 2)
7) v1 > v2 because of 5) and 6)

° rounding_error <= qty * curr_rounding / 2
° rounding_error * curr_rounding <= qty * curr_rounding / 2 * curr_rounding
° rounding_error / curr_rounding <= qty / 2
° v1 <= v2
==>> This contradict 7), hence this check can never be True for qty < 2

To fix this issue, we change the check to:
 ° rounding_error <= qty * curr_rounding / 2 OR rounding_error <= curr_rounding
 Where the 1st part doesn't change, but the second one is true when rounding_error == curr_rounding

closes odoo/odoo#115516

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

Steps to reproduce:

- Add a "Table Of Content" snippet from the website editor.
- Save > The effect on the active page item (in top menu) is removed.

Starting from [1], a `.scrollspy('dispose')` call was added to destroy
the existing ScrollSpy, and to be able to make a new call that works
correctly when the header height changed.

Since this call has no specific target as option, it will trigger the
`scrollspy._clear()` process on all `'.nav-link'` elements including
navbar items which removes the `'active'` class from current page link.

The goal of this commit is to fix this behaviour by calling the
'dispose' only when an instance of `Scrollspy` exists.

[1]: https://github.com/odoo/odoo/commit/476995ba5a1d33aa0590214609346557d1d471c0



task-3223277

closes odoo/odoo#114937

Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>

When a document (SO/MO) create a demand and this demand is directly
refill by an orderpoint, then write the source document that triggered
the orderpoint in addition in the origin field.

The purpose is to have an easy base tracking configuration even if
the priority and schedule date (and the final customer) could change
afterward (origin field still editable)

closes odoo/odoo#114738

Part-of: odoo/odoo#75144
Signed-off-by: Adrien Widart <awt@odoo.com>

Usecase to reproduce:
- Enable multi steps manufacturing (pbm at least)
- Set a RR 0 0 on a component
- Confirm the MO

-> The scheduler is not run for the components

It happens because only the moves raw are confirm and not
the pickings from the procurement group (like in SO)

Part-of: odoo/odoo#114738

This commit translate the ics file for an event to
the language chosen by the public user on the website.
For connected users, the ics file is translated to
the user's language.

Task-3199180

closes odoo/odoo#113528

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

fix typo in substract

substract -> subtract

closes odoo/odoo#115476

Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>

mrp_operation picking type is not handle by default in stock module get_description function.

Add default return to stock get_description function

opw-3232811

closes odoo/odoo#115310

Signed-off-by: Tiffany Chang <tic@odoo.com>