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>

The empty editor message was overflowing its container when in a modal,
so a part of it was hidden and there was a scrollbar. This fixes it by
setting its width to the available space.

task-2742664

Part-of: odoo/odoo#85126

Current behavior :
If no completed template (`completed_template_id`) is selected in the options of an elearning course, an error occurs when a user completes this course.

Steps :
- Install elearning
- (*with demo data*) Go to a course (e.g. Basics of Gardening)
- Remove the selected "Completion Email" then save
- Complete the course

Reason :
We are trying to access a `record_email_values` value here [1] but no value is assigned to `record_email_values` unless we have a completed_template [2].

[1] : https://github.com/odoo/odoo/blob/f4d83f31c12cb13d626bcaaa619c0f3be680cdbc/addons/website_slides/models/slide_channel.py#L110
[2] : https://github.com/odoo/odoo/blob/f4d83f31c12cb13d626bcaaa619c0f3be680cdbc/addons/website_slides/models/slide_channel.py#L105-L106



OPW-2753078

closes odoo/odoo#84377

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

Speedup basic_model._updateRecordsData for
many2many fields such as fetchmail.server.message_ids
and mail_channel.channel_message_ids.

Calling _.findWhere(values) inside two nested _.each
calls can be quite slow when the number of values
is big.

Remove the call to _.findWhere by first
creating a Map res_id -> data and then calling
Map.get to retrieve the data for a given res_id
when making a DataPoint

opw-2701170

closes odoo/odoo#82522

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

Expected Behaviour

When updating the cost of a product with a negative quantity and then
making an inventory adjustment, the final value should be corrected according
to the current cost of the product

Observed Behaviour

In the case we had a negative quantity when changing the cost, the compensation
layer will be ignored when doing an inventory adjustment afterward, leading to
an incorrect total value in the inventory valuation

Reproducibility

This bug can be reproduced following these steps:
- Create Storable product with costing method = AVCO Automated, Update cost to 100$
- Sell 10 units of this product (Inventory valuation at -1000 $ for -10 units)
- Update cost of the product to 10 $ (Inventory valuation at -100 $ for -10 units)
- Create an inventory adjustment to set the quantity of the product to 0.
==> Inventory valuation is a 900 $ for 0 unit of our product

Related Issues/PR

- opw-2635692

closes odoo/odoo#86368

X-original-commit: 673a6b69
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>

When a PO is in the "To Approve" state, it disappears from the
forecasted report

To reproduce the issue:
1. In Settings, enable "Purchase Order Approval" with a minimum amount
equal to 0
2. Create a storable product P
3. With Marc Demo:
    - Create a PO with 50 x P
    - Consult the forecasted report of P: there are 50 x P "Forecasted +
Pending"
    - Confirm the PO (its state becomes "To Approve")
    - Consult the forecasted report of P

Error: The 50 x P disappeared: 0 On Hand, 0 Forecasted, 0 Forecasted +
Pending. We should still see 50 Forecasted + Pending

OPW-2774586

closes odoo/odoo#86376

X-original-commit: 6f1d750c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

PR #85474 introduced a bug where in users are not able to create purchase
requisition in a multi company setup.

closes odoo/odoo#86397

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

opw-2793379

closes odoo/odoo#86402

X-original-commit: 0dd7c78b

When inserting a format with a collapsed selection, we need to insert a
zero-width space. It should not be saved so we need to isolate it and
put the "oe-zws-empty-inline" attribute on its parent so it gets cleaned
up by the sanitizer.

closes odoo/odoo#85408

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

Take `<p>a<b>bcde</b>f` and select the whole paragraph. If you click the
"bold" button, you would expect the whole paragraph to become bold. Only
if you only select "bcde" do you expect to unbold it. This is the
behavior of other editors. Odoo-editor so far was unbolding as long as a
part of the selection was bold.
The same applies to other formats.

Currently the format buttons are active when the closest start container
is that format but it should be active when pressing it would undo the
format, ie when the whole selection is that format. This harmonizes it
with the browser defaults.

task-2754127

Part-of: odoo/odoo#85408

When a background color is applied on an ancestor, while it's visibly
there, `getComputedStyle` doesn't know. Because it did depend on it,
the toolbar showed the wrong color in these cases.
Eg: `<span style="background-color: red;"><b>a[]bc</b></span>` was
showing no background color.

task-2778416

Part-of: odoo/odoo#85408

The link button was toggling its active state on every update of the
toolbar because we weren't passing the toggle function a boolean. and
if the element we were passing it was `undefined`, it triggered the
default behavior which is to just toggle. Instead we want it to be false
if the element is `undefined`.

Part-of: odoo/odoo#85408