Mock server's mail channel write method is incorrect. It assumes
the id of the channel will always be 20 while it could be anything.

closes odoo/odoo#86770

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

task-2793106

closes odoo/odoo#86767

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

Before this commit
The style for `li.oe-nested` was loaded only when the editor loaded.
The problem is that the style needs to be visible even when the editor
has never been loaded.

After this commit
The style for `li.oe-nested` is always loaded in the backend and in
the frontend.

Task-2793528

closes odoo/odoo#86758

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

Steps to reproduce the bug:
- Go to Inventory > Transfers > Select a ready transfer with no qty done
- Print > barcodes (ZPL) or barcodes (PDF)

Problem:
The file is empty because there is no qty_done.

Solution:
If no qty is done, then print all barcodes as if picking is done.
It makes sense, for example, when a user wants to print the barcodes before the product is delivered

but if at least one move_line has a Qty_done then do not print the other move_lines which have a qty_done of 0

opw-2780365

closes odoo/odoo#86756

X-original-commit: f6ae75f2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

Context
-------

Web design specific require a lot of work and need maintenance.
So far the style files were not taken into account despite the
amount of maintenance they require.

With this commit they are going to be counted,
knowing they still can be excluded in the manifest.

Imported module allow to deploy frontend assets: stylesheet,
javascript, xml template and Qweb view that require
as well some maintenance. They are going to be counted

Implementation
--------------

- Add method to parse css and scss file
- Include .scss and .css file in the count

- Add external_id to attachment that store
  frontend asset of imported module
- Find all attachment with .js, .css, .scss, .xml
  from imported module
- Find qweb view from imported module
- cound the content of the attachment and the qweb view

closes odoo/odoo#85854

Signed-off-by: Christophe Simonis <chs@odoo.com>

In case an open balance needs to be created on a receivable or
payable account after reconciliation, but no partner was defined
on the statement line, we want to keep the partner from the
counterpart values that was identified through reference matching.

closes odoo/odoo#86728

X-original-commit: 8c4d6d36
Signed-off-by: Florian Gilbert <flg@odoo.com>

Step to reproduce:

- Install contacts
- create a new contact and set "Côte d'Ivoire" as country
- add a phone number like this one: (+225) 01 02 03 04 05
- try to send a sms to the number, it's says "(Invalid number)" instead
  of the number, so it's not possible to send the SMS

The Ivory Coast has a new standard for the phone number since the 31
January 2021, the phone number can have a length of ten digits. And we
use the library phonenumbers with the version 8.9.10 and 8.8.1 for the
runbot and the SaaS server, but it's quite old (the 8.9.10 is released
on Jul 12 2018). The library in version 8.12.29 resolve the issue, but
using the recommended installation method, we would not have this
version.

opw-2726582

closes odoo/odoo#86577

X-original-commit: 2f718cd7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>

task-2734733

closes odoo/odoo#82915

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

Reproduction:
1. Add the subtotal field (untaxed_amount) to either the list or form
view in hr.expense
2. Create an expense that uses a unit price/quantity, set the fields and
save
3. The subtotal field is not updated

Reason: the field untaxed_amount is not saved, as its value is not
passed to the write function even with attribute store=True

Fix: Added an invisible field for untaxed_amount and set force_save=”1”

opw-2725901

closes odoo/odoo#86671

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

Steps to reproduce the bug:
- Enable “Storage Locations” option in the inventory settings
- Go to Inventory > Configuration > Warehouse > locations
- Choose any Location > Click on current stock > Select any product
- Try to add two line

Problem:
Traceback is triggered, Because the line should not be added twice(like in “Inventory Adjustments” view)
and as in the `_onchange_location_or_product_id` we access the quantity,
it should be only one quant: https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_quant.py#L517



In v14, this list view is not editable, but since the refactor in v15 added the new view `stock.quant.inventory.tree.editable`,
it is being called by this action

Solution:
set the `view_id` to `stock.quant.tree`, which is the view it was previously using

opw-2779795

closes odoo/odoo#86432

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

Steps to reproduce:
- create a contact with a very long name
- create a quotation
- in customer, type the first letter of the very long customer's name
- try to use the horizontal scroll bar

Issue:
close window on horizontal scroll

Solution:
Discriminate an horizontal scroll from a vertical scroll
A test has been added as well as the triggerScroll utility function
to allow proper tests when scrolling on elements

opw-2777443

closes odoo/odoo#86088

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

Since https://github.com/odoo/odoo/commit/cb6c6224be4eaa80091f51f957059de889332e68


we are now raising possible errors when uploading an invoice.
In 14.0+ we are allowing via a redirect warning to change the status of
the currency without changing the page but the upload only starts when
you change the uploaded file.
So the following flow does not work:
    - Try to upload a bill with MXN currency
    - With MXN being inactive, it raises an error. Using the redirect warning action
      we activate the currency, clos the modale window and try to upload
      again.
    - The upload won't work until we refresh the page, because the value
      of the input file does not change (or we need to select another
      one, then the first one again)
This change reset the file input if there is an error raised during the
upload allowing to select the same file more than once without reloading.

closes odoo/odoo#86517

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

When using price included taxes, the xml contained data that failed to
meet the constraints of the edi. This is due to the local rounding on
the lines of the invoice.
For example:

	A product costing 321€, on two lines of the invoice, with
	a price included tax of 22%
	Rounded per line:
	float_round(
		321 - (321/122 * 100),
		2 # To two decimal places
	)
	evaluates to 57.89, the total tax will be 2 * 57.89 = 115.78

	In the case of global rounding
	float_round(
		321 + 321 - (321/122*100) - (321/122*100),
		2 # To two decimal places
	)
	evaluates to 115.77,

	so we have a difference of one cent.

This can be exacerbated by more lines.

The constraints on the EDI that this conflicts with are on the tax
summary section for each tax.
The constraints (roughly reworded):
00422:  The base taxable amount for the tax must be equal to the sum of
	the base product prices (for which we have already used the
	rounded computed values, calcuated in the invoice) +
	<Arrotondamento> (rounding).

00421:  The value provided for the <importo> that is the value of the
	vat is equal to the taxable base multiplied by the tax rate.

The problem is that because of our local roundings, the taxable base
is equal to our products, but the tax rate * taxable base is not equal
to the tax amount (as present in the invoice).

This commit adds to the rounding field and subtracts from the
taxable base of the tax summary a value rounding value that
should make tax rate * taxable base equal to the value of the vat.

closes odoo/odoo#86683

Task: 2789290
X-original-commit: def954e8
Signed-off-by: Josse Colpaert <jco@odoo.com>

Steps to reproduce the issue:

- Let's consider a company C in $ and the rate conversion from $ to € is 0.5
- Let's consider a product P
- Let's consider a pricelist PL1 in € such as P is set to 100€
- Let's consider a pricelist PL2 in $ such as P id set to 100$
- Create a sale order SO with PL1
- Create a line with P

Bug:

The unit price of P was 200€ instead of 100€ because field currency_id was not set on the line
when trying to pass it to function _get_tax_included_unit_price

opw:2789324

closes odoo/odoo#86490

Signed-off-by: Simon Goffin <sig@odoo.com>

Workorder _action_confirm works in batch and is designed to
link workorders and moves per production.

Original code breaks the 'per production' constraint by linking
moves from all productions to workorders of the last one when
called on workorders from multiple productions.

closes odoo/odoo#86633

Task: 2797201
Signed-off-by: Arnold Moyaux <arm@odoo.com>

This fixes erroneous matching of product when the product code in an invoice is ambiguous and fixes a missuse of the label from a product rather than the one on the invoice

Previously, a product would be set on an invoice line even if several products share the product code and when a product is set the label is the one of the matched product
Now, a product is set if the code matches one and only one product and the label used is always the one from the invoice

closes odoo/odoo#86631

Task: 2764978
X-original-commit: b7d45808
Signed-off-by: Josse Colpaert <jco@odoo.com>

Since [1] illustration shapes are only obtained from their slug. Before
they were obtained from their URL.

After this commit the old behavior is restored as a fallback in case the
illustration shape cannot be found from its slug.
This is needed to allow importing shapes into the system from data
files.

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



task-2793073

closes odoo/odoo#86342

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

Since [1] the CSS property reset for hovered outline buttons is using
invalid property values.

After this commit the color and image are only reset on non-hover:
- the `background-color` is already set to `none` by `.btn`,
- the `background-image` is only set if defined on the button's style -
there is no need to reset it.

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



task-2633169

closes odoo/odoo#86205

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

When confirming a sale order, if a purchase order is generated, the
descriptions of the PO's lines won't be adapted to the vendor

To reproduce the issue:
1. Create a vendor V
2. Create a product P:
    - Type: Service
    - In Purchase, add a line L01:
        - Vendor: V
        - Vendor Product Name: Name01
        - Vendor Product Code: C01
    - Purchase Automatically: True
3. Create and Confirm a SO with 1 x P
4. Open the generated PO

Error: The description is incorrect (it's the standard name of P instead
of "[C01] Name01")

OPW-2777702

closes odoo/odoo#86256

closes odoo/odoo#86657

X-original-commit: 766964e4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

When delivering an additional product with a specific UoM, the generated
line on the sale order should have that same UoM

To reproduce the issue:
1. In Settings, enable "Units of Measure"
2. Create two products PA and PB (UoM of PB is the meter)
3. Create and confirm a SO with 1 x PA
4. On the picking, add 1 km(!) x PB
5. Validate the picking
6. Go back on the SO

Error: the line for PB is incorrect, its UoM is 'm', it should be 'km'

OPW-2761913

closes odoo/odoo#86471

X-original-commit: 042609e6
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Step to reproduce:
- Create a Quotation Template QT and set in in the sale settings
- In the confirmation Tab of QT add a confirmation email
- As a portal user, purchase an item in ecommerce
 The payment must be confirmed. (tested using payment_test module)

Current Behaviour:
- Traceback on confirmation email rendering, portal user do not
 have access to the full data.

Behaviour after PR:
- Email is rendered as superuser to ensure data is correctly
 fetched

opw-2749804

closes odoo/odoo#86357

X-original-commit: 8ece0413
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Currently, the tax report contains the lines for tripartite trade,
but no taxes have been made for these.
As the EC list report use these taxes it, these needs to be implemented.

closes odoo/odoo#86121

Task: task-2759470
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>

We have a bug when we were computing the invoice rate that is used to
report to AFIP. The rate we were setting was an old rate that references
the day that the invoice was created and not the rate of the day where
the invoice was validated.  This was happening because the
l10n_ar_currency_rate field that stores this value was computed before
posting the invoice. At that time the date field store the value of the
date where the invoice was created and had not been updated yet with the
accounting date.

Moving the l10n_ar_currency_rate field calculation after the invoice
post solves the problem and now the l10n_ar_currency_rate has the rate
of the accounting date.

Part-of: odoo/odoo#84470

Original commit: aac1165655d31ba3bca4b105e0c905534e91df93

closes odoo/odoo#85880

Related: odoo/enterprise#25022
Signed-off-by: Josse Colpaert <jco@odoo.com>

This fixes the how general discounts and product discounts are represented in the Italian EDI.

Previously, discounts were erroneously calculated and represented on several invoice lines not linked to the product.
Now, cascading discounts are summaries as 1 percentage discount for products and 1 amount for the general discount.

closes odoo/odoo#85844

Task: 2764978
X-original-commit: 806d766b
Signed-off-by: Josse Colpaert <jco@odoo.com>

When codice fiscale is not the same as the partita IVA, the template was
utilising the wrong value for IdCodice in <IdTrasmittente>. It should
use the value of codice fiscale, and if it's not found, then use the vat
value (e.g. when it's not an Italian company).

closes odoo/odoo#86617

X-original-commit: e961ff22
Signed-off-by: Josse Colpaert <jco@odoo.com>

The issue is that the config param is data, which means that when the
module is updated, the config parameter will be updated (i.e. reset to
the 'demo' state), which will cause havoc on client databases. Even if
we set the record to 'noupdate=1', the existing clients will have the
record updated.

The solution is to remove the config param from the data entirely, thus
preventing it from being updated when updating the module, and instead
have a 'post_init_hook' that sets the parameter to 'demo' (this will
only happen when the module is installed, and never again).

closes odoo/odoo#86594

X-original-commit: 1d3cd7ee
Signed-off-by: Josse Colpaert <jco@odoo.com>

PrezzoUnitario causes an error when the discount is 100% as it tries to
divide by zero. Fix this by just using the unit price when the discount
is 100%.

closes odoo/odoo#86604

X-original-commit: 23e84145
Signed-off-by: Josse Colpaert <jco@odoo.com>

The EDI rejects the xml if the <IdDocumento/> is longer than 20
characters long.

X-original-commit: 2c76293c
Part-of: odoo/odoo#86604

When we were doing a price modification on a product and this orderline was refund, the displayed price on the product screen was changed to the new value.

Example:
  - Default price: 33
  - Paying with a price set to: 2
  The order is refund:
  - Product price is set to 2
  It should only be 2 on the order refunded.

The fix doesn't change the price of the product after a refund anymore.

closes odoo/odoo#86496

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

When clicking on readonly stat button (website related), it would
sometimes raise a traceback since there is no action to redirect to.

Step to reproduce:
- Go to Website > Visitors > Visitors
- Select a Visitor to enter its form view
- Now, either:
  A. Enter edit mode
  B. Enter edit mode and discard (or save)
- Click on stat button

This will raise a traceback, since the `disabled` property is now gone.
Indeed, the framework is adding/removing that attribute when entering
or leaving edit mode.
See disableButtons()/enableButtons()` called by
_setEditMode()/_onDiscard()/..`

Note:
- With the new framework/owl, there is no TB as the `disabled`
attribute is not removed anymore.
- In 14.0, there is no issue despite the `disabled` attributed being
removed.

Fixes #78500
Closes #80884

Courtesy of @odooaktiv

closes odoo/odoo#86392

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

Current behavior:
All batch transfers are shown in the tree view. But only the one for the allowed companies should be in the list

Steps to reproduce:
- Be in a multicompany environnement
- Activate batch picking
- Go in Inventory/Batch transfers

opw-2752617

closes odoo/odoo#86505

X-original-commit: 8415b48c
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Since [1] when resetting the background color of the header, the footer
or the copyright, the 'menu-custom' property is saved as the 'false'
string.
There is no visual effect of this problem, but in case that property is
used in an SCSS `color-yiq` function call, it will trigger an error.

This commit solves this by removing the root cause of this 'false'
string: during the initialisation of color palettes a list of named
colors is built by browsing the color buttons and associating their
data-color attribute to their background-color, except for buttons
containing a gradient color.
Unfortunately this inventory also looked at the "Custom" gradient
button: this button has no background color (and was thus not detected
as being a gradient and therefore not excluded from the inventory) and
it has data-color="false". It therefore introduced a mapping between ""
and "false" - thus making the reset operation's empty string mapped to
the "false" string. This commit removes that button from the named
colors inventory.

Steps to reproduce:
- select the header
- open the "Colors" palette
- click on the None button (the trashcan icon)
=> the customization properties attachment contained a line
```
'menu-custom': 'false',
```

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



task-2633169

closes odoo/odoo#84550

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

Cash rounding value were not added with negative amount.
For example if you made an order:
  - amount of the order: 1.98
  - rounding value: 0.05
  - amount to pay: 2.00
The refund of this order should be:
  - amount of the order: - 1.98
  - amount to pay: - 2.00
  - amount to pay before the fix: - 1.98

Because when we added the latest fix that allowed payment lower than the cash rounding value (for example an order amount of 0.03 with a cash rounding for 0.05), the negative amount were not taken into account.
Whenever a negative amount had to be paid, the condition was triggered and return a 0 as rounding to apply (-1.98 < 0.05 => true).
Now we check the absolute value of the total amount to consider if we need to apply a rounding.

closes odoo/odoo#86495

X-original-commit: 421e9d91
Signed-off-by: Masereel Pierre <pim@odoo.com>

In a recent fix, the default values generated for datetime fields in
custom filter was incorrectly set, as the returned date objects were
lost instead of being assigned.

This commit restores the intended behavior.

closes odoo/odoo#86325

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

Issue:
At anypoint we should be able to call the method "_set_lot_ids" from stock.move on moves that are already done and the quantities should not change.
This is not the case for lots that get their quantity changes to 1 as if the product was tracked by serial number.

This commit should be seen a a complement to the commit: https://github.com/odoo/odoo/pull/79565



Fix:
Check the product is tracked by SN before trying to change the quantities to 1.

Related ticket: 2689724

closes odoo/odoo#82360

X-original-commit: 61cd8337
Signed-off-by: Arnold Moyaux <arm@odoo.com>

closes odoo/odoo#86246

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

Currently while sending a digest, if a company does not have an email
address set, the "From" field for the mail is blank and so trying to
send digest fails.

With this commit, if a company does not have an email address set, it
will fallback to logged in user's email address as a "From" value.
In most cases, it will be the Odoobot email address (if the digest is
sent with the CRON) but if the admin send manually the digest, we will
use the admin email address.

TaskID-2729780

closes odoo/odoo#86390

X-original-commit: 64af6473
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

closes odoo/odoo#85705

X-original-commit: 5ef00fcd
Signed-off-by: Arnold Moyaux <arm@odoo.com>

When opening mass_mailing in a dialog (eg, in marketing automation),
dragging a snippet to the bottom of the page (without dropping) caused
an infinitely growing scrollbar on the document element.

Note: this revealed that in that particular context the auto scroll to
snippet feature is broken and while dragging we have an extra scrollbar,
on the editable area. In order to fix that, we need to be able to
identify from within the iframe the case where mass_mailing
self-resizes. This involves changing the view to add an option which
will set a class on the document element. This is not acceptable in
stable and will therefore be fixed in master instead.

task-2742664

closes odoo/odoo#85126

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