…e unit calc

**Current behavior:**
Selling a kit bom product will result in inaccurate journal
entries in the stock output and expense accounts, the
amount_currency field will only reflect the price unit of the
kit's components.

**Expected behavior:**
The price unit should reflect the total cost of the components
on the BoM: e.g., if a kit product needs 4 of some component1,
the price unit should be 4 * component1.standard_price.

**Steps to reproduce:**
1. Create a kit product with 2 components, both with qty > 1

2. Assign dropshipping to the kit

3. Create a sale order and confirm -> confirm the purchase order

4. Validate the dropship transfer, invoice the sale order and
post it

5. See the 2 inaccurate journal entries, where the debit/credit
respectively only total to one instance of each component's
cost added together

**Cause of the issue:**
The price unit calculation didn't look at the bom line product
qty, only using the price unit 1 time per component.

**Fix:**
Multiply the value by the quantity of it required on its line in
the BoM.

opw-4253827

closes odoo#183916

Signed-off-by: William Henrotin (whe) <[email protected]>

This completes odoo#171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix.

Based on Real World™️ evidence.

@moduon MT-7215

closes odoo#185089

Signed-off-by: Arnaud Joset (arj) <[email protected]>

Adds default value to a few required selection fields as currently a
value is apparently set in the form (as the select field will pick the
first value) but without having the value really set in the field,
meaning that on save, the field will appear as invalid.
Also, to be able to select the "almost default" value, you'd need to
select another value then pick the first value again to properly set it
in the field and be able to save the form.

To avoid those issue, we can add a default value to those fields
corresponding to the current "default" value in the form.

closes odoo#184939

Signed-off-by: Steve Van Essche <[email protected]>

Issue:
    - When picking up a SO in POS, the discount on products
    sold with a non groupable UOM disappears.

Steps to reproduce:
    - Create a SO in the sales app.
    - Include a product that has a UOM of which the uom category
     is not grouped in POS (g for example).
    - Add a discount to the product.
    - Pick up the order in POS.
    - Notice that the discount is not applied.

Solution:
    - In `_onClickSaleOrder` I set the discount on the `splitted_line`
     before adding it to the orderline.

opw-4133659

closes odoo#185109

Signed-off-by: Vlad Stroia (vlst) <[email protected]>

When archiving an operation in a bom, currently it will unlink if from
bom lines that had it set as their `Consumed in Operation`.

However, it's not the case for byproducts, meaning that the byproducts
lines will still display the now archived operation.

closes odoo#185093

Signed-off-by: Steve Van Essche <[email protected]>

When having a tax with a specific tax as source account in the
tax mapping of a fiscal position. The mapping does not apply
if the product has a different tax from the tax of the account
and no income/expense account set.

This is because we extend `_get_product_accounts` in `datev`
and replace the default income/expense account by an account
that have the product tax.

With this fix, we replace defualt income/expense accounts only
if we find an account.

Steps:

- Have a FP with an account mapping: 8400 -> 2315
- Have a product P with a different tax from the one set on 8400
  account, and that is not set on any other account
- Create an invoice, set the FP, select the product P
-> Account on the aml is 8400 instead of 2315

opw-4075846

closes odoo#185232

Signed-off-by: Josse Colpaert (jco) <[email protected]>

this commit reverts changes introduced in odoo#183616

During reconciliation when two payment methods (cash and bank) are used simultanosly.
the change amount is incorrectly deducted from the bank payment.
An attempt to resolve this issue introduced further complications with payment amounts.
By creating a single account move, it attempted to deduct the change amount
from the cash payment, which led to inaccurate payment amounts.

opw-4276421

closes odoo#185291

Signed-off-by: Vlad Stroia (vlst) <[email protected]>

Since the introduction of live chat, an arbitrary decision
to open a blank chat window when reloading/navigating away
from the page when the user didn't interract with it was
made.

However, this is disturbing, especially in the chat bot case
where the empty chat window still has the chat bot name as its
title.

Moreover, this chat bot chat window won't trigger the bot answers
if the user interract with it.

This PR removes this blank window behavior and displays the
live chat button instead.

opw-4214093

closes odoo#185313

Signed-off-by: Matthieu Stockbauer (tsm) <[email protected]>

Same issue as odoo#126323 but with CSV, TXT
and other types of files.

This basically overrides the default decoding charset of the email python
module to use utf-8 by default.  As mentioned in the PR above, utf-8 is a
superset of the ascii encoding and this should not cause other issues.

opw-4237114
opw-4245261

closes odoo#185270

X-original-commit: fd8a5e5
Signed-off-by: Julien Castiaux (juc) <[email protected]>

When model selection field is used in a form, its default value is
always one of the available values. Because of this, if the field is
required, it does not force the user to pick a value, but it provides a
possibly incorrect default value.

This commit makes an empty value available for selection if no default
value is chosen.
The behavior is also made available on custom fields, if such an empty
value had been manually created, it will be replaced by this
implementation.

Steps to reproduce:
- Install website_form_project
- Add a form in a page
- Select the "Create a Task" action
- Add the "Analytic Account" field to the form
- Make the field required

=> There was no way to have no default value by default.

opw-4268164

closes odoo#184842

Signed-off-by: Serge Bayet (seba) <[email protected]>

Versions
--------
- 16.0+

Steps
-----
1. Add one or more lines to an SO with the same tax;
2. apply a discount coupon.

Issue
-----
Tax gets mentioned in the discount line name, even though it isn't
really necesarry in this scenario.

Cause
-----
When generating the discount line description, a `tax_desc` gets added
for any tax with a name.

Solution
--------
Only add `tax_desc` if there's more than one discount line being
generated due to multiple taxes.

opw-4072437

closes odoo#183686

Signed-off-by: Valentin Chevalier <[email protected]>

Steps to reproduce:
1. Navigate to Pricelists.
2. Import a CSV or XLSX file that contains at least one product or product
   variant.
3. Duplicate the newly created pricelist.

Issue:
- When duplicating an imported pricelist, the duplicated record does not retain
  the product or product variant information.

Cause:
- If the applied_on field is not provided during the creation of the pricelist
  item, the default value of 3_global is applied.
- As a result, when duplicating the pricelist, the product_tmpl_id and
  product_id fields are set to None.

Fix:
- When the applied_on field is missing during the creation of a new pricelist
  item, set it based on the presence of the relevant fields (such as product or
  product variant).

opw-4170242

closes odoo#185100

Signed-off-by: Victor Feyens (vfe) <[email protected]>

An Odoo server error occurs when attempting to change the main partner, country, sales team (if sales is installed) or document type (if l10n_latam_invoice_document is installed) in a report from the invoice analysis.

Steps to reproduce:

1. Go to Accounting > Reporting > Management > Invoice Analysis.
2. Click on the pivot icon (on the far right).
3. Click on any amount.
4. A list of invoices should appear.
5. Click on any invoice.
6. Change the main partner or country and save.

An Odoo server error would occur

opw-4246387

closes odoo#184505

Signed-off-by: Antoine Dupuis (andu) <[email protected]>

Steps to reproduce:
- Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id
- In journal items, try to "cut-off"

Issue:
You won't be able to do so because of the tax lock date

Cause:
We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow.
We create move line without tax_ids/tag_grid and so it does not impact the tax report:
https://github.com/odoo/odoo/blob/763d54426a1218b827f30fa0323f745c929a3d1d/addons/account/wizard/account_automatic_entry_wizard.py#L242-L271

Solution:
we set the `has_tax` to False to byapss the check. The user, if he wishes, could excatly the same flow by creating an entry "a la mano" <->  We don't need to block this flow

opw-4191527

closes odoo#185078

Signed-off-by: Antoine Dupuis (andu) <[email protected]>

When downloading a url type attachment, it will not open in a new tab
and breaks the activity of the current tab,such as rtc call and
breadcrumbs.

To reproduce the error: Project > Task > click on the url attachment >
open in the current tab, the breadcrumbs (previous filters) will be lost

This commit fixes the issue by opening the url attachment in a new tab.
And "downloading" a url does not make sense, so the download button is
replaced by an open button.

closes odoo#184264

Signed-off-by: Zelong Lin (zel) <[email protected]>

Before this commit :
`is_html_empty` considers empty icons as empty html.

After this commit:
Empty icons are considered as non empty html

Note: changed the tag_re to more performant regex

task-4060037

closes odoo#182642

Signed-off-by: Xavier Morel (xmo) <[email protected]>

Steps to reproduce:
- Install Accounting and l10n_es_edi_tbai
- Switch to a Spanish company (e.g. ES Company)
- In Accounting settings, select "Hacienda Foral de Bizkaia" as
"Tax Agency for TBAI"
- Create a vendor bill:
  * Vendor: [a Spanish vendor]
  * Invoice Lines: (These amounts are important)

      Quantity  |  Price  |  Taxes
    --------------------------------
         2      | 2896.74 |  21% G
         4      |  121.52 |  21% G

- Confirm the bill
- Sent bill to TicketBAI

Issue:
The generated xml will be rejected because "BaseImponible" value has
more than 2 decimals.

Cause:
A floating point issue during the computation of "BaseImponible" with
these specific values.

opw-3987704

closes odoo#170724

closes odoo#184885

Signed-off-by: Josse Colpaert <[email protected]>
Signed-off-by: Antoine Dupuis (andu) <[email protected]>

Steps to reproduce the issue:

1. Activate Italian Localization
2. Create a contact in any country but Italy
3. Assign VAT number starting with 'IT' (Tax ID or Identification Number)
4. Save and receive error:

>     Invalid Codice Fiscale '[VAT number]': should be like 'MRTMTT91D08F205J' for physical person and '12345670546' for businesses.

Explanation:

When `country_id` or `vat` is changing, `_l10n_it_onchange_vat` will try to create a `l10n_it_codice_fiscale` if `res.partner` respects some conditions.
Those conditions are flawed because if `country_id` is not Italy but `vat` starts with "IT", it will enter the condition.

(Kind of a hack: if `country_id` is set after a `l10n_it_codice_fiscale` has been added to `res.partner`, the first condition will not be met but the second will, and `l10n_codice_fiscale` will turn back to False.)

Fix reasoning:

We will only check conditions related to `vat` and `country_id` and always perform changes to avoid inconsistencies where `vat` is no longer correct but `l10n_it_codice_fiscale` did not change and is still valid.

opw-4261959

closes odoo#184406

Signed-off-by: Antoine Dupuis (andu) <[email protected]>

Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

closes odoo#171705

Signed-off-by: William André (wan) <[email protected]>

…creating accrued revenue entries

Problem:
When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set.

Purpose of this PR:
To make sure only product lines are taken into account when generating these entries

How to reproduce:
1) Create and confirm a sale order where the first order line is a section or note and the next contains a product
2) Run the Accrued Revenue Entry contextual action
3) Fill the Accrual Account and Amount fields with arbitrary data and hit Create Entry
4) Error appears, a move line is generated with no account

closes odoo#183230

Signed-off-by: Olivier Colson (oco) <[email protected]>

Currently, a traceback occurs when the user deletes a module
which is having a gamification goal record.

To reproduce this issue:

1) Install sale and gamification
2) Create a new gamification challenge record
3) Create a new goal in the gamification challenge
4) Make sure the goal has the definition as `Automatic: sum on a field`
5) Select the model as `account`
6) Uninstall the invoicing module and start challenge of that gamification.

Error:- "KeyError: False"

This is because when the user deletes a module that is used in
the gamification goal, as the model value becomes `False`.

This leads to a traceback as model_id is used for the reference of obj
https://github.com/odoo/odoo/blob/d9603e93d2ab5e0b9fd1948dfd3e3bee20ede599/addons/gamification/models/gamification_goal.py#L164-L165

We can resolve this issue by adding `ondelete='cascade'`
in the field description. Where the record will be deleted
if the corresponding model is uninstalled.
sentry-4089991441

closes odoo#180307

Signed-off-by: Thibault Delavallee (tde) <[email protected]>

Update branding logo and icon in windows installer.

Task-2862802

closes odoo#185650

Signed-off-by: Christophe Monniez (moc) <[email protected]>

Payments initiated by the customer from the payment form could sometimes
lead to multiple charges if a webhook notification would arrive at the
same time as the payment request's response. This is due to the webhook
acquiring a lock in the database when updating the transaction's state,
followed by the processing of the payment request's response trying to
do the same and thus encountering a concurrent access error. The payment
request is thus retried and a new charge is created on Adyen side.

This commit fixes the issue by passing an idempotency key with the
payment request. If a payment request is inadvertently retried, Adyen
silently ignores it and returns the same response as for the initial
request. The response is processed again in Odoo and the customer is
smoothly redirected to the payment landing page.

closes odoo#184919

Signed-off-by: Antoine Vandevenne (anv) <[email protected]>

As VISA added more mandatory fields to perform payments, the holder's
name is required now for the customer to fill when paying with adyen.

opw-4085163

closes odoo#178393

Signed-off-by: Valeriya Chuprina (vchu) <[email protected]>

- Billing officers / HR officers have access to all bank accounts
- Internal users only have access to bank accounts that are not linked to an employee
- Portal/Public users have access to nothing.

closes odoo#184346

Taskid: 3101400
Signed-off-by: Florian Gilbert (flg) <[email protected]>

Currently, when the stock scheduler is run, a new cursor is created and
the result is rolled back even if all tasks succeeded. Even though tasks
themselves are not rolled back because they are run using new other
cursors, rolling it back is not correct and it makes harder to test the
scheduler feature.

The rollback was introduced in da6bd90 by mistake.

This commit makes the transaction to be rolled back only when the
current transaction actually failed.

closes odoo#175621

Signed-off-by: Tiffany Chang (tic) <[email protected]>

Issue found at commit: odoo@0e8f3d5
After the above mentioned commit when using eWaybill with
e-Invoicing the log note of ewaybill i.e.
```
E-wayBill Sent
Number -> 0
Validity -> None
```
where as in the response attachment of eWaybill, the ewaybill number
does exist

In this commit, we resolve the above issue and the correct ewaybill
number gets logged

opw-4280093

closes odoo#185680

Signed-off-by: Josse Colpaert (jco) <[email protected]>

Use normalized emails for comparison to avoid issues linked to
formatting.

Task-4281171: [mail] {email/smtp}_from normalized comparison

closes odoo#185749

Signed-off-by: Thibault Delavallee (tde) <[email protected]>

Steps to Reproduce :
1. Go to Website editor --> Drag and Drop the Image - Text snippet
2. Replace an image of size fore than 10 mb or any image that takes
time to upload.
3. Close the upload media pop-over.
4. Close the uploading media screen as well.
5. Post the buffering screening ---> Traceback occurs.

Specification:

This commit aims to resolve the issue occured while discarding the
upload process the `this.fileInput.el` becomes undefined as image upload
is discarded which resulted in traceback.

task-4255826

closes odoo#183547

Signed-off-by: Benjamin Vray (bvr) <[email protected]>

Problem:
Certain `ir.actions.act_window` actions contain a context with `active_id`, which causes issues when set as home actions, as `active_id` will not be defined in that context.

Solution:
Prevent the selection of actions that include `active_id` in their context from being set as home actions.

Steps to reproduce:
1. Enable debug mode.
2. Navigate to `Settings / Users & Companies / Users`.
3. Select the current user from the list.
4. Under Preferences / Menus Customization set "Home Action" to "Quotations and Sales."
5. After that: each time you go to backend homepage (/) you get a traceback error instead of the app dashboard

opw-4283156

closes odoo#185319

Signed-off-by: Rémy Voet (ryv) <[email protected]>

There was a typo in the test, which was breaking tests when they ran
without demo data. This commit fixes it.

closes odoo#185659

Signed-off-by: William Braeckman (wbr) <[email protected]>

Steps to reproduce:
- Install l10n_cl
- Switch to a Chilean company (e.g. CL Company)
- Activate a foreign currency (e.g. USD)
- Make sure that the rate of the foreign currency is not 1
  For example:
  * Unit per CLP: 0.001057876419
  * CLP per Unit:945.29
- Create an invoice in USD with 2 lines having different amount:
  * 15.80
  * 15.00
- Save the invoice
- Print the invoice

Issue:
On the printed invoice, a slightly different currency rate is displayed
for each invoice line.

Cause:
The currency rate to display is computed for each invoice line, based
on the following formula: abs(self.balance) / self.price_subtotal
However, the value of balance is rounded to the unit because of the
CLP currency and therefore it generates a different rate when trying
to compute it.

Solution:
Compute the rate from the total values instead of the subtotal of each
line.
The real rate configured on the currency cannot be used because it can
be modified after the creation of the invoice.

opw-4242448

closes odoo#185230

Related: odoo/enterprise#73035
Signed-off-by: Josse Colpaert (jco) <[email protected]>

*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr,
l10n_fr_pos_cert

closes odoo#185817

Related: odoo/enterprise#73048
Signed-off-by: Tiffany Chang (tic) <[email protected]>

When guessing the language at install (or upgrade) we cannot trigger a
pre-fetch of all fields of `res.company` because some of its columns may
be not initialized yet. One way to trigger this behaviour is to add a
stored field whose default value uses translations, while at the same
time adding any other stored field. If the translation is fetched in a
sudo environment we can get an error when the System partner has `NULL`
language.

Steps to reproduce:
1. On a cleanly initialized DB (only `base`) add any extra language
   (en_GB would do).
2. Open Users & Companies (show inactive users) open System user.
3. Open Related Partner.
3. In the form view of the System partner set the language to None.
4. Try to install via the command line a module with the fields as
   described above (see below for a code example).

We get an error like:
```
2024-10-30 08:48:40,831 41180 INFO test_16 odoo.modules.registry: module mymodule: creating or updating database tables
2024-10-30 08:48:40,839 41180 ERROR test_16 odoo.sql_db: bad query: SELECT "res_company"."id" AS "id", "res_company"."name" AS "name"
... <many more fields, redacted>  ... "res_company"."bar" AS "bar", "res_company"."foo" AS "foo" FROM "res_company" WHERE "res_company".id IN (1)
ERROR: column res_company.foo does not exist
LINE 1: ...e" AS "write_date", "res_company"."bar" AS "bar", "res_compa...
```

The solution we propose is to skip the prefetch of `res.company` fields
when we are in the process of guessing the language. In this case the
language is correctly picked from the System partner's company.

This issue has been observed in many upgrades to 18, but it's present in
older Odoo versions as well. The language field in `res.partner` is not
required, thus it is also possible to set the language to `NULL` via
code.

Example data observed in upgrades:
```
> select id,name,active,lang from res_partner where lang is null
+----+-----------------------+--------+--------+
| id | name                  | active | lang   |
|----+-----------------------+--------+--------|
| 4  | Public user           | False  | <null> |
| 5  | Default User Template | False  | <null> |
| 6  | Portal User Template  | False  | <null> |
| 2  | System                | False  | <null> |
+----+-----------------------+--------+--------+
```
There may be other standard flows that lead to such setup where System
partner has no language set.

Example inherit of `res.company` that triggers the issue:
```py
class A(models.Model):
    _inherit = "res.company"

    bar = fields.Many2one(
        comodel_name="ir.sequence",
        default=lambda self: self.env["ir.sequence"].sudo().create({"name": _("Dummy")}),
        required=True,
    )
    foo = fields.Integer()
```

Standard example of this code pattern that triggers the issue during
upgrades to 18:
https://github.com/odoo/odoo/blob/dd71d998/addons/account/models/company.py#L140-L152

closes odoo#185810

Signed-off-by: Rémy Voet (ryv) <[email protected]>

After this commit 784f151 , The `float_round()` functionality is changed.
Before this commit, If the `qty_available` is 0.57:
```
In [2]: float_round(0.57,2)
Out[2]: 0.5700000000000001

After this commit:
In [2]: float_round(0.57,2)
Out[2]: 0.57
```

Now, while executing this line of code
https://github.com/odoo/odoo/blob/baea953d248471e8aef60e02c1216f77941f1951/addons/mrp/models/product.py#L244.
```
Before:
In [3]: 0.5700000000000001*100//1
Out[3]: 57.0

After:
In [3]: 0.57*100//1
Out[3]: 56.0
```

These differences leads to blocking the upgrade process.
```
Traceback (most recent call last):
File "/tmp/tmpft9eq3rf/migrations/testing.py", line 212, in test_check
self.check(value)
File "/tmp/tmpft9eq3rf/migrations/stock/tests/test_on_hand_quantity.py", line 90, in check
self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[12,[7979 chars]6, '57'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']] != [[12,[7979 chars]6, '56'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']]

First differing element 529:
[20246, '57']
[20246, '56']
```

upg-2096343
opw-4224012

closes odoo#183289

Signed-off-by: William Henrotin (whe) <[email protected]>

**Steps to reproduce the bug:**
- Create two storable products, “P1” and “P2”.
- Set “P1” to be tracked by Serial Number
- Update P1 with SN1.
- Create a repair order:
   - Set P1 with SN1.
   - Save.
- Edit and update the product to P2.
- Save.
- Print the order.

**Problem:**
The “lot_id” is not cleared and appears in the report because the
“lot_id” field becomes invisible and read-only under the same condition.
Since it is read-only and not force-saved, the value of “lot_id” is not
considered in the write of the repair order, even though the `onchange`
sets the “lot_id” field to False:

https://github.com/odoo/odoo/blob/16.0/addons/repair/models/repair.py#L208-L212

**opw-4281176**

closes odoo#185552

Signed-off-by: Quentin Wolfs (quwo) <[email protected]>

Versions
--------
- 16.0  (sale_product_configurator)
- 17.0+ (website_sale_product_configurator)

Steps
-----
1. Enable Dutch language;
2. go to eCommerce;
3. switch to mobile view;
4. go to a product which has optional products;
5. add to cart.

Issue
-----
There's not enough space in the configurator to properly display the
"Toevoegen aan winkelmandje" button.

Cause
-----
The view isn't mobile-responsive.

Solution
--------
Replace the button with a simple cart icon to ensure consistency between
localisations while keeping things simple.

opw-4198786

closes odoo#185133

Signed-off-by: Levi Siuzdak <[email protected]>

When viewing more than 1 viewable file in the FileViewer,
the navigation buttons `<` and `>` are barely visible.

This commit fixes it by putting white icon on dark rounded
background for the buttons.

Task-4056907

closes odoo#185910

Signed-off-by: Matthieu Stockbauer (tsm) <[email protected]>

Since domain methods of fields are set using the actual class method
instead of a lambda, it is not possible to inherit those methods when
inheriting the model.

This issue is fixed by using a lambda function to call the domain
method.

Part-of: odoo#185419
Related: odoo/enterprise#72931
Signed-off-by: Xavier Bol (xbo) <[email protected]>

Since domain method of the Sales Order Item field is set using the
actual class method instead of a lambda, it is not possible to inherit
that method when inheriting the model.

This issue is fixed by using a lambda function to call the domain
method.

closes odoo#185419

Related: odoo/enterprise#72931
Signed-off-by: Xavier Bol (xbo) <[email protected]>

Update the OWL lib.

Release notes:
https://github.com/odoo/owl/releases/tag/v2.4.1

closes odoo#185965

Signed-off-by: Géry Debongnie <[email protected]>

Since odoo#138471, each time `create_or_update_sequences_and_picking_types`
is called, the related sequences will be updated to their default
values. This means that if a user changed the sequence_code of a
standard picking type, whenever that method is called (which can happen
at the update of a warehouse), it will erase their settings.

Rather than that, if the picking type already exist, we use its
sequence_code instead of the default one.

closes odoo#185966

Signed-off-by: Arnold Moyaux (arm) <[email protected]>

Versions
--------
- 16.0
- 17.0
- saas-17.2

Fixed in saas-17.4 via 3e0bbf5

Steps
-----
1. Set eCommerce prices to display tax included;
2. have a discount code program;
3. add a deliverable product to cart;
4. apply discount code;
5. click "Proceed to Checkout";
6. open web inspector on the discount amount in the cart summary.

Issue
-----
The `span` element doesn't have the `data-reward-type="discount"`
attribute.

Cause
-----
The template adding the attribute, only adds it to the first child
element, which displays the price tax excluded.

Solution
--------
Add an `xpath` template to also add it to the second one.

opw-4284046

closes odoo#185440

Signed-off-by: Valentin Chevalier <[email protected]>

To reproduce:
=============
- with service product S with create project & task
- create sale order with that product
- with another service product E with Re-invoice Expenses at cost
- create expense with this product and link it to the first sale order
- go back to sale order, we find product E added to sale order
- create invoice and post it

Problem:
========
on project updates we have the expense + the customer invoice
which gives wrong profits in stats

Solution:
=========
exclude the customer invoice from the revenues when it's linked
to an expense, as the expense is already included in the revenues

opw-4000095

closes odoo#182165

Signed-off-by: Xavier Bol (xbo) <[email protected]>

closes odoo#186092

X-original-commit: 3a28e5b
Signed-off-by: Josse Colpaert (jco) <[email protected]>

Conflicts:
	addons/web_editor/i18n/vi.po