Without this commit, when the compare/reset view feature was reading the arch,
it would translate it.

2 issues :
- When reading from file (hard reset), it would translate the file version
- When reading current arch, it would translate it

closes odoo/odoo#62346

X-original-commit: e69c9c5fe73b5bb33342f08247488821f3b71800
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Behavior prior to this commit:

- when the warehouse uses a 3-step manufacturing process, if I create a
Sales Order, the MO generated does not show the SO# as "Source", instead
it shows the MO#

Behavior after this commit:

- the MO source shows the SO# (similar to how it works when using the
2-step or the 1-step manufacturing process)
- the origins are assigned thus:
  - Delivery Picking = SO name
  - Post-prod Picking = SO name
  - MO = SO name
  - Pre-prod Picking = MO name

Implementation note:

- the `origin` gets overwritten when the group is generated in
`_run_pull`, because the group name is used as default origin in the
base `StockMove` model
(see https://github.com/odoo/odoo/blob/a8224115d8254b4200416f552fc86f6e9e68223c/addons/stock/models/stock_move.py#L1030

).
But we need that group to correctly tie the moves to the MO. So instead
we go back to look at the dest move on the MO to get its origin.

opw-2380717

closes odoo/odoo#62201

Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>

Before this commit if a product template has no image, no image was
displayed in the website shop for the product

After this commit if a product template has no image, the image of the
first variant is displayed in the website shop

https://github.com/odoo/odoo/issues/52463



closes odoo/odoo#61322

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

What are the steps to reproduce your issue ?

    1. Install "website_sale_comparison"
    2. Create a product with only one variant with one attribut
    3. Click on "Go to website" smart button
    4. Enable "Customize/List View Variant"
    5. Click on "Compare" button

What is currently happening ?

    Nothing

What are you expecting to happen ?

    Add product to the comparison list

Why is this happening ?

    Because the product has just one variant and attribut so odoo don't
    display it on the product page. The system cannot find the ids as
    they are not on the page

How to fix the bug ?

    Specify the product id in this case

opw-2377711
https://www.odoo.com/web#id=2377711&action=4043&model=project.task&view_type=form&cids=1&menu_id=4720



closes odoo/odoo#62285

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

This makes the act of replacing the dummy text easier.

@Tecnativa

closes odoo/odoo#55433

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

STEPS:
* Create a BoM with two components purchased the same vendor, but with
different "Delivery Lead Time". First component must have lower value
* Create Manufactoring order, Mark as ToDo
* Open created purchase order

BEFORE: Order Date	is equal "MO planned day MINUS delivery lead time for the first component"
AFTER: Order Date	is equal "MO planned day MINUS maximum amout delivery lead
time for the components"

---

opw-2388031

closes odoo/odoo#62382

Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

closes odoo/odoo#62374

X-original-commit: 73293a2b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Fiscal positions shouldn't be deleted if used by existing account moves

closes odoo/odoo#62167

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

closes odoo/odoo#61878

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

For this case, if the invoice currency is different from the invoice company currency, the tax calculation is considered the value in a different currency, and the subtotal is the sum of the amount untaxed + the taxes (wrongly in company currency) result in an incorrect value. This is verified when printing the invoice report

closes odoo/odoo#61401

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

Followup on 911ada2d

When modifying the company_id of a pricelist, the check to ensure a website
has a pricelist available wasn't triggered.

This commits ensures the Each website has Valid Pricelist with Correct or
Empty company.

Fixes #50707

closes odoo/odoo#50785

Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Before this commit, it was impossible to write to a delegated m2o field
if the length of the recordset was greater than 1.

The reason was because the special case for delegated fields inside
fields.Many2one.convert_to_cache would check for `record.id` which is a
bit misleading, since record can be greater than one.

The solution is to check whether any of the records are real records
instead, as if all of the records are NewRecords, then the parent is a
NewRecord too.

Fixes #62069

closes odoo/odoo#62295

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Introduced in e25d859c,
assertAlmostEqual's third param is 'places' and not 'msg'.
We fix that by declaring the message as a keyword argument.

closes odoo/odoo#62221

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

A based on rules shipping method with the "Free if order amount is above" field enabled is not correctly applied.

To reproduce the error:
(Need website_sale)
1. Go to Settings > Website
2. Enable "Shipping Costs"
3. Go to Website > Configuration > eCommerce > Shipping Methods
4. Create a new one
	- Select "Based on Rules"
	- Enable "Free if order amount is above"
	- Set the corresponding amount
	- In pricing, add a line
5. Save & Publish (Click on "Unpublished")
6. Go to website's shop
7. Add the product set in the shipping method to your cart
	- Select an amount sufficient to exceed the threshold amount set in step 4
8. Process Checkout

=> The shipping method is shown, but the associated amount is "No price rule matching this order[...]"

The shipping method price should be 0.

(This error also happens when creating a SO)

OPW-2383258

closes odoo/odoo#62062

Signed-off-by: adwid <adwid@users.noreply.github.com>

Before this commit selecting the same attachment was not detected, which
was a problem when the attachment had been mistakenly removed

After this commit when the same attachment is selected several times in
a row it still triggers the upload and gets attached

https://github.com/odoo/odoo/issues/42364



closes odoo/odoo#61597

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Steps to reproduce the bug:

- Let's consider a BOM with by-products
- Let's consider a product P tracked by lot
- Let's consider a user U in a single company
- Let's manufacture the BOM with U
- Click on produce and add P in the by-product
- Create a lot L and save

Bug:

It was impossible to save because the required field company was empty

opw:2390013

closes odoo/odoo#62268

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Behavior prior to this commit:

- edit an existing invoice
- add a line, but do not save
- add an attachment - the attachment uploads and the new line stays visible
- save the record: the line now disappears

Behavior after this commit:

- changes are not discarded when uploading an attachment

opw-2369162

closes odoo/odoo#62155

Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>

- Create a product with:
  Cost: 60.80
  Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Report
- Export as XLS

The header values have too many decimals: 60739.2000000007

The root cause is `convert_to_cache` returns this value:

https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333



In this case, `currency.round()` keeps the extra digits. Since the field
is not stored, the useless digits are kept.

A simple solution is to use `float_repr` on the non-stored float fields
to make sure that doesn't happen. Another solution could be to not
convert the floats to strings, but that doesn't seem intended.

opw-2378895

closes odoo/odoo#62091

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Main
-

Inheriting the creation of Cash Basis (CABA) Journal Entries is hard to
be done and the current way of doing it can lead to the creation of a
huge number of lines that are not quite useful and its creations can
lead to a lengthy process of creation of payment when several invoices
with a huge amount of invoice lines involved or to a lengthy process of
cancelation of payment because of reversion of the CABA, in case of
l10n_mx, many users have opted for using
l10n_mx_edi_avoid_reversal_entry, and then this causes a lengthy process
of deletions of CABA entries.

Justification
-

CABA Entry is divided into two parts when it is created
- Tax Part: The part that deals with the taxes themselves (this PR does
not mess with them).
- Base Part: The part of the base of the taxes (what this PR is all about)

Currently Base Part is creating a big deal of line and we want to be
able on our side to change this behavior.

By providing a better inheritability on the
`create_tax_cash_basis_entry` method Developers can leverage on it and
make their own implementation according to their local needs.

**This PR does not change the current behavior of
`create_tax_cash_basis_entry` method**

closes odoo/odoo#46952

closes odoo/odoo#61105

X-original-commit: 4b866255
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

During the uninstall step of the registry, we perform a commit right
after the uninstallation of all module data, this commit is performed
right before the creation of a new registry, this means that said commit
will call `flush_env` and thus `recompute` on an environment that is
based on a stale Registry (memory and database are unsynchronized).

This means that during this specific moment, there's a chance that the
recompute function may have to fetch some fields it depends on to
perform its computations if said fields are not in cache, this in turn
means that it will try to prefetch fields that are potentially no longer
in the database, making the registry crash and preventing the uninstall.

This is what happened with multiple if not all `payment_*` modules, the
main module `payment` depends on a `ir.module.module` record, most
notably the `color` field of the `payment.acquirer` model which depends
on the `state` field which in turn depends on the
`ir.module.module.state` field.

This meant that uninstalling a module such as `payment_paypal` triggered
a recompute of `payment.acquirer.color` during uninstall, and to perform
that computation we need several `payment.acquirer` fields to be fetched
from cache or the database. If in cache, the uninstall would go through
without a hitch, if not in cache, we would fetch the required fields
from the database but we'd also attempt to prefetch the fields
introduced by `payment_paypal` that had just been deleted from the
database!

To avoid this, the `_module_uninstall_data` method of `ir.model.data`
will henceforth guarantee that `ir.model.fields` that are to-be-deleted
will have their prefetch set to False, meaning only existing fields will
be fetched from the database during the uninstall of extending modules.

Fixes #60424
opw-2372598

closes odoo/odoo#62231

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>

Steps to reproduce the bug:

- Let's consider the current company C in Germany with a VAT number
- Let's consider a partner P in Belgium with a VAT number and fiscal position Geschäftspartner EU (mit USt-ID)
- Let's consider a product PR with weight and a 19% tax
- Make a cutomer invoice CI to P with PR
- The 19% tax will be replaced by Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG)
- Post CI
- Go to the Intrastat report

Bug:

PR didn't appear in the report

As wrtote here: https://github.com/odoo/enterprise/blob/13.0/l10n_de_reports/models/partner_vat_intra.py#L21


The taxes considered in the intrastat report must be with as least one of these tags:

- l10n_de.tag_de_intracom_community_delivery
- l10n_de.tag_de_intracom_community_supplies
- l10n_de.tag_de_intracom_ABC

But Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG) didn't have one of these tags
Same for Steuerfreie Ausfuhr (§4 Nr. 1a UStG)

opw:2379263

closes odoo/odoo#62039

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Steps to reproduce the bug:

- Let's consider a configuration with two languages L1 and L2
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Define a default text T1 and save
- Create a new customer invoice, T1 is displayed in the field narration
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Change T1 to T2 for L1, L2 and save
- Create a new customer invoice

Bug:

T2 was displayed in the field narration

opw:2388353

closes odoo/odoo#62190

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

The German date format is the following: DD.MM.YYYY but when importing
such value, it is wrongly considered as a float value due to the '.'
being confused with the thousands separator in the regexp of method
_remove_currency_symbol.

We should check both date/time and float/monetary formats, so it will
correctly identify the German date format as well as float values.

closes odoo/odoo#62197

X-original-commit: 1bdd0cc2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>

WHY:
* chart of accounts may not be setup right after module installation
* even though the classes are inherited from TestStockValuationLC, adding tests
just to TestStockValuationLC doesn't make the trick

---

opw-2382456

closes odoo/odoo#62160

Related: odoo/enterprise#14914
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

Steps to reproduce the bug:
- Install Accounting
- Go to Accounting > Reporting > Management / Invoices
- In the "Favorites" filter, choose "By Product Category" or "By Product"

Bug:
Traceback:
Uncaught Error: NameError: name 'true' is not defined

Explanation:
We can pass the context as a JS object since `pyUtils.eval()` uses them as is.
Keeping the context as a string is useful when we can't evaluate it
directly (because there is no evaluation context yet and it's needed by
`pyUtils.eval()`). Here, the context is already evaluated.

opw:2380285

closes odoo/odoo#61851

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

The 'On Hand' button triggers action_open_quants on product model. It
do not explode the kit into its component

closes odoo/odoo#62058

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Instances like deleting a tax used in a pos.order before closing a
session is allowed but it renders error when closing the session
because of imbalance move lines. In this commit, we are adding
a 'balancing' line in the move before it is created. This ensures
the closing of pos session. The introduced move line is named
'Difference at closing PoS session' and is a receivable making it
easy to find and can be reconciled.

closes odoo/odoo#61870

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

When some bills are not paid, some with due date, some without, when registering the payment of these bills as a group payment with checks, it is not possible to print the check

To reproduce the error:
(Need account)
1. Go to Invoicing > Vendors > Bills
2. Create a new one
    - Add at least one line
    - Add the Payment Terms
3. Save & Post
4. Duplicate it, then Save & Post
5. Go back to Bills
6. Select the two bills
7. Click on Action > Register Payment
8. Select Checks, enable Group Payment
9. Click on Create Payment
10. Click on Print Check
11. Click on Print

=> An Odoo Error is raised

The user should be able to print it.

OPW-2389368

closes odoo/odoo#62028

Signed-off-by: adwid <adwid@users.noreply.github.com>

Create a sale order for a stored product, save and confirm.
Validate delivery
Return and validate.
Return (the return, so delivery again) and validate.
Try return again.

The quantity to return in the widget will be 0.
Attempting to fix manually will worsen the situation creating negative
quantities on further action.

This occur because when creating the return the system tries to identity
other sibling return moves to set the correct quantity
This commit fine tunes 73de0645b730e1f1183b7c770e878b4c4ff1e0f1 aiming
to collect quantities only on actual sibling returns (moves sharing the
same parent)

opw-2379663

closes odoo/odoo#61996

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

closes odoo/odoo#61492

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Set a arbitrary 10000 limit instead of 40 for the configurator
product_no_variant_attribute_value_ids (attributes that do not create a
variant) and product_template_attribute_value_ids (attributes that
create a variant) fields.

With a limit of 40, when we edited a variant (eg. on sale order) with
more than 40 create_variant=never attributes, the widget
ProductConfiguratorFormView that work with this data would only received
40 attributes so there would be an error message:

  "The combination does not exists."

which would prevent edition of the variant.

opw-2333091
closes #58493

closes odoo/odoo#58570

X-original-commit: 295884ce154990ecb51d3fc7c39aeeb21dc11f03
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

1. Create a storable product
2. Set the category: Costing
   - Method: First In First Out (FIFO)
   - Inventory Valuation: Automated
   - Price Difference Account: Price different accounts.
3. Create a vendor bill with the product and the quantity set as 0
4. Post the vendor Bill

A ZeroDivision error is raised.

A fix was done in #58613, but instead of using it commit
32d47d32 attempted to refactor the code. We apply the
original fix again and add a condition to prevent a zero division.

No refactoring was needed in stable.

opw-2375464

closes odoo/odoo#62102

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Correctly format the `product_uom_qty` with the appropriate widget.

opw-2382517

closes odoo/odoo#62065

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The prefetching engine wants to prefetch all the registrations to all
the events of all the schedulers, which may make a lot of data.

If the autocommit is on, then all this prefetched data is discarded at
each loop.

This commit limits the prefetching to each scheduler, so that we avoid
prefetching the data unnecessarily.

closes odoo/odoo#62049

X-original-commit: 904a46f2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>

What are the steps to reproduce your issue ?

    1. Install 'stock'
    2. Create 'ProductA' with 'Tracking By Lots'
    3. Create some 'Lots/Serial Numbers', for example 'CodeA0 and 'CodeA1'
    4. Go to 'Reporting/Inventory Report'
    5. Remove 'Product > Location' from the search bar.
    6. Click 'Create' and select 'ProductA' with 'WH/Stock' Location

What is currently happening ?

    When you set 'Lot/Serial Number', the available lots to choose
    are not limited to the selected product only.

What are you expecting to happen ?

    Show only lots of the selected product.

Why is this happening ?

    The domain contained no condition which depended on the product.

How to fix the bug ?

    Addition of a condition that depends on the product.

opw-238143

closes odoo/odoo#62005

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Steps to reproduce:
- Install Online Appointments
- Go to Calendar > Online Appointments > create a new one
- Add an available employee like "Mitchell Admin"
- Make a slot for each week day at 8:00
- Go to the Calendar of the employee and create a recurrent meeting from 6:00 to 12:00 which repeats everyday for 10 days
- Go to the Online Appointments you created then click the button "Go to Website"

Bug:
You can still make an appointment when the employee is busy.

Explanation:
Recurring events had their stop date always set to one hour after their start date. So, appointments could still be made two hours after the start date.

As seen here: https://github.com/odoo/odoo/blob/ee76b25b003f96073f78420960e216acf14bf821/addons/calendar/models/calendar.py#L47
`with_date` is passed to `timedelta()`. And passing `hours=True` works as if `True` was `1`.

```python
>>> from datetime import timedelta
>>> timedelta(hours=True)
datetime.timedelta(seconds=3600)
```

This fix reproduces the behavior before this commit introduced the bug: https://github.com/odoo/odoo/commit/9920f20e4c7753bc17bea71dea3a90f7de687196
That is, if no duration is given or duration is `0`, one hour is used instead.

This bug probably occured because of the naming of the definition: https://github.com/odoo/odoo/blob/ee76b25b003f96073f78420960e216acf14bf821/addons/calendar/models/calendar.py#L33


In fact, `with_date` can be interpreted as being boolean, and the `False` default isn't helping against that. A possibly better alternative to this could be:

```python
def calendar_id2real_id(calendar_id=None, duration=None):
```

opw:2334449

closes odoo/odoo#61823

Signed-off-by: backspac <backspac@users.noreply.github.com>

Steps to reproduce the bug:
- Install Online Appointments
- Go to Calendar > Online Appointments > create a new one
- Add an available employee like "Mitchell Admin"
- Make a slot for each week day at 8:00
- Go to the Calendar of the employee and create a recurrent meeting on yesterday's date from 7:00 to 11:00 which repeats everyday for 10 days
- Go to the Online Appointments you created then click the button "Go to Website"

Bug:
The employee's events aren't generated and available slots show up as if the events didn't exist.

Explanation:
The events weren't generated if the recurrence start date wasn't within the generation frame.

What are the steps to reproduce your issue ?

    1. Create two companies on a multi-company database without Website installed.
        For this use case, install Purchase
    2. Configure two distinct logos per company
    3. Create a Purchase Order with the second company.
    4. Send PO from second company over as email.
    5. Check recipient email (or mailhog for Runbot) for the email
    6. Find that while the PDF report reflects second company's logo,
        the header navigation bar in the client email when clicking "View Request
        for Quotation" reflects company_id=1's logo.

What is currently happening ?

    The displayed logo is not the correct one.

What are you expecting to happen ?

    Display the right logo.

Why is this happening ?

    Because when rendering the view. The value of 'res_company' declared in the context has as value the id of the default company of the user

How to fix the bug ?

    Specify the current company.

opw-2380274

closes odoo/odoo#62007

X-original-commit: 5eb40d22
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>

- Create a product with price 2335.5, no tax
- Start a POS session
- Add the product, set a discount of 3% on the line => total is 2665.44
- Validate and close the session
- Got to Point of Sale / Reporting / Orders, open the pivot view

The Total Price of the order is 2665.43.

It happens because the server returns a value of 2665.435, which is
displayed in the pivot view as 2665.43.

We round the Total Price based on the company currency decimal
precision. Indeed, all amounts are converted in this currency in the
report.

opw-2369023

closes odoo/odoo#61945

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>