When executing the product2bom method it is possible that an active_test
context is present in self. However, the method should not consider
archived BoMs.

closes odoo/odoo#100771

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

# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.

# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."

# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()

OPW-2982004

closes odoo/odoo#100064

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

closes odoo/odoo#104196

Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>

Before this commit, following these steps:
- Go to /blog
- Activate the option Customize > Top banner - Name / Latest Post
- Disable the option Customize > Full Width Cover
- Click on the "guides" tag of the "Buying A Telescope" blog

No blog is displayed. This was because the top banner post is not shown
when the posts are filtered. Basically, once filtered, a blog post was
always missing.

Related to opw-2882492

closes odoo/odoo#93680

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

Before this commit, following these steps:
- Go to /blog
- Activate the option Customize > Top banner - Name / Latest Post
- Disable the option Customize > Full Width Cover

The URL to which we are redirected when we click on the blog of the
post presented at the top of the page leads to an error.

Indeed the URL of that link is something like "/blog?blog=blog.blog(2,)"
because of the template wrongly using the 'blog_url' QueryURL which is
defined in the case where we are rendering a blog page where no specific
blog is selected. We define that as `QueryURL('/blog', ['tag'], ...)`
but then parts of the template used it like this: `blog_url(blog=X)`
thus generating an URL like "/blog?blog=blog.blog(2,)". Adding "blog" to
the list of params would not be right as would create "/blog/blog/2"
which is still wrong as we want "/blog/2". And of course the "/blog"
prefix in the QueryURL definition is needed in case we only specify a
tag via `blog_url(tag=X)` (we expect /blog/tag/X). Patching QueryURL or
making blog_url a custom function instead of a QueryURL instance could
be a solution but it was judged not stable enough. We'll do that in
master. Here we only support "/blog?blog=blog.blog(2,)" URLs.

Note that many parts of those templates do not use the `blog_url`
function and simply build the URL by hand, which is why the bug only
occurred for a very specific set of blog options.

opw-2882492

Part-of: odoo/odoo#93680
Co-authored-by: Guillaume (gdi) <gdi@odoo.com>

Backport of #83422

closes odoo/odoo#104094

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Have the following taxes:
- Tax A: 15%, included in price
- Tax B: 21%, included in price

Create a product P with list price 115 and tax A

Have a fiscal positions FPOS configured with:
- Detect Automatically checked
- Country: Belgium
- Map tax on product: A -> B

Open a web shop session as guest, add P to cart
Go to checkout: Price total will be 115
Fill address details with Belgium address
Go to confirmation page

Error:
Price total will be 100. In the application of fiscal position the wrong
unit price is used

opw-2973879

closes odoo/odoo#101364

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Pingen's v2 API does not offer an endpoint to generate a Cover Page automatically with an API call anymore, thus the need to generate it and append it to the invoice from the client-side beforehand.
Also make the Cover Page option mandatory due to the invoice being near
impossible to format for Pingen's validation needs. (Odoo 13 Only)

closes odoo/odoo#103385

Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>

Because of an issue with converting bool values, read_progress_bar didn't work
on grouping by bool fields (e.g. Active).

Related tests worked fine because mocked server responses were different from
real server responsed. So, we need to adjust mocked server too.

opw-2870937

closes odoo/odoo#95654

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

Before this commit: the "no-store" was overridden in developer mode.

'no-cache' does not require that the response must not be stored in the
cache. It only specifies that the cached response must not be reused to
serve a subsequent request without re-validating.
It is up to the browser what to qualify as a subsequent request. In
Chrome, using the back button and duplicating the tab does not. So I
agree that it's better to use 'no-store' in dev mode.

The solution is to prevent changing the "Cache-Control" if it's "no-store".

opw-2855802

closes odoo/odoo#101590

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

We are spammed by some accounts that don't have credits anymore.

With this commit, when we try to send letters from the cron, whenever we
meet the CREDIT_ERROR error_code, we stop trying to send the letter.

task-2930455

closes odoo/odoo#103264

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Before this commit, customers might see a "transaction not found" page
when returning from Adyen Pay By Link Payment Page.

Now, they'll see a "waiting for payment" page if they returned before
the webhook notification or the confirmation of payment if they
returned after the webhook notification.

opw-3006401

closes odoo/odoo#102999

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

The previous link was dead

closes odoo/odoo#101911

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Fixup of 706db8a7

closes odoo/odoo#102558

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

The implementation of _find_mail_template allow to call it only
on one record at a time.

This was not the case with in _send_order_confirmation_mail.

- Add excplicit constraint in _find_mail_template
- Make sure _send_order_confirmation_mail call the method once per
  record

closes odoo/odoo#102135

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

Customer display does not show the appropriate logo when multi-company is
enabled. The logo shown is always the logo of the default company.

Step to reproduce the issue:
1) Install Point of Sale and set up a second company
2) Put a logo on both companies (different ones)
3) Create a POS session on the newest company (not the default one)
4) In this session, activate Customer Display
5) Launch the session and open the Customer Display
The logo shown is the logo of the default company.

Solution: The issue is that when fetching the logo, we don't include
information about the current company. Thus, we include the logo of the default
company (at url /logo). We can easily specifiy which logo we need via the url
/logo?company={company_id}. As dynamic information cannot be included into a
CSS, we include this into the XML as it is done with other images rendered.
In our case, we don't need to retrieve the logo and map it to base 64 (for
ressources requiring to be logged in) because the logo is a resource available
to anyone.

opw-2745014

closes odoo/odoo#93638

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

closes odoo/odoo#98021

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

Part-of: odoo/odoo#98021

This PR https://github.com/odoo/odoo/pull/97805

 wrongly assumed that
self contained a single workorder. This would raise an error if there
were multiple records in self.

Solution:
Modify calls on `self` to `workorder` (as we already iterate through
them)

closes odoo/odoo#101580

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

Steps to reproduce:

1. change system and admin's time zone to one with a different
date than UTC
2. enable multi-currency in the accounting module
3. add rates for the current date in local time zone and UTC
4. go to settings > currencies
5. the rate for the UTC date is displayed

To fix this, we should use a time zone aware field in `res_currency`.

opw-2945108

closes odoo/odoo#100123

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

closes odoo/odoo#101380

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

- Go to accounting/Report/Invoices Analysis
- Open studio
- enable list view
- empty view

This code bellow compute count_field as `__count` because group_by_no_leaf
is in the context.

But in the basic_model we don't consider this case.

https://github.com/odoo/odoo/blob/5797fd80a63309269f15bcbe4948d4429a53eec2/odoo/models.py#L2293-L2297



opw-2980923

closes odoo/odoo#100869

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

Those constraints are an incorrect leftover from 0a42a9de which removed the size constraints on a
number of core tables including 'name' and 'model' of ir_model_data.

Temporary table tmp_ir_translation_import limits columns size (imd_name and imd_model).
Those columns are only used to match columns 'model' and 'name' in ir_model_data.

But in ir_model_data, columns 'model' and 'name' are VARCHAR, no reasons to restrict the temporary table.

opw-2983422

closes odoo/odoo#101144

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Change 'Invoice date' label on report according move_type

closes odoo/odoo#100851

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

The default value of max_time_between_keys_in_ms in barcode is 55 ms.
The default value of 55 ms is too low and creates an issue for RFID readers.

The default value of max_time_between_keys_in_ms is increased to 100 ms.

task-2996072

closes odoo/odoo#101128

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

Steps to reproduce:
- install sale_management
- enable variant in the setting of sales
- create a second company
- create a product with at least a variant and set the company
  to the active one
- switch to the second company
- create another product and select the same variant
- error on creation

Cause:

 The stored compute is executed as sudo, therefore a value that the user
 has no access may stays in the cache. In subsequent flush we might read
 value from cache when computing some other fields that contain an
 unreadable value for current user.

Solution:

 Flush and invalidate so we don't have unaccessible value in cache in
 this use case.

note: this is not happening in 14.0 and over

opw-2898457
opw-2950290

closes odoo/odoo#96023

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

A "thematic break"[1] is composed of 3 or more characters (-, _,
or *). The current separator using only 2 characters between the main
body of the PR and the footer / addendum makes it more difficult to
interpret the message.

Update to 3 so e.g. the mergebot can strip the footer.

[1]: https://spec.commonmark.org/0.30/#thematic-breaks



closes odoo/odoo#101072

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Reproduction:
1. Install eCommerce and accounting
2. Go to Accounting->Configuration->Taxes, add one sale tax 15%, and one
0%. Both taxes are included in the price.
3. Go to Configuration-> Fiscal Position, create a new one “test” which
applies the tax mapping from 15% sale tax to the 0%. Check “Detect
Automatically”, set country group as Europe
4. Go to Website->Orders->Customers, set the country of the portal user,
Joel Willis, as Luxembourg. In Sales&Purchase->Fiscal Information set
the fiscal position as “test”
5. Go to Website->Products->Product Variants, create a new one
“test_tax_prod” with price 110, and sale tax 15%, can be sold, can be
purchased and consumable.
6. Go to Website->Configuration->Attribute, create a new product
attribute “test” with Display Type as Ratio, Variant Creation Mode as
Never. Create a value “a” in its attribute values
7. Go to Website->Products->Products, find test_tax_prod, go to its
variant tab, set attribute as “test” with value “a”, publish this
product
8. Open an incognito tab, login as “portal” pwd: portal, search the
product “test_tax_prod”, set the price list as “public price list”, the
price is 95.65 on the page. Add it to the cart, the price is 110

Reason: When we update the order_line, we should update the price based
on the fiscal position for the no_variant products too. However, based
on the current workflow, the price is computed in method
_website_product_id_change before an order line is created. Thus for
no_variant products, the price is not updated.

Fix:  This issue is fixed in saas-15.3 by rewriting the workflow and
calculating the price through an on_change function here: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605

In v13, we don’t have this on_change method to compute the new price, so
a similar price update can be created in the cart update for
website_sale. This fix solution was created here: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
However, new price computation issues can happen when combining two
pricelists, here: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391

Thus the fix is eventually done in _website_product_id_change. Added a
new parameter to force checking the orderlines based on the domain. The
orderline is created but only can be searched based on the domain. This
ensures the price is computed correctly for pricelists and for tax.

Added fiscal position test for no variant product

opw-2856956

Fix by re-writing in saas-15.3: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605
First related fix: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
Second fix to patch for the first fix: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391



closes odoo/odoo#99647

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Issue :
- `account.move.state` has only 3 possible values cancel, draft, posted
- the wrong value was used

Fix:
- Use the correct value `posted`

OPW-2991389

closes odoo/odoo#100691

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Have a tax with tax tags
Create a bank statement line
Reconcile creating a manual operation, add the tax, then remove it and
validate
Check journal entry

The tax tags will be present on the base line even if the tax was
removed

opw-2867395

closes odoo/odoo#94445

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

blocked to their stock inventory records

closes odoo/odoo#100631

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

Only compute the lot values info on stockable or consu (kits) products
on the invoice lines

closes odoo/odoo#100322

Signed-off-by: Adrien Widart <awt@odoo.com>

Currently, When we create an invoice from a sale order containing some notes or sections. The analytic account from the sale order is set on the invoice/move line. During the creation of analytic lines, a line is created from the section/note line.

This commit makes no analytic line is created for section/notes.

Video : 

https://youtu.be/AqyrXEIcKvg



--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#95786

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

- Due to hefty data the RAM limit gets exhausted.
- The process gets killed due to computed field margin on sale.order.line

To solve the problem:
- We add column margin to DB schema.

Task id: #2950878

closes odoo/odoo#100453

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

When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
   'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
   one with values:
   - Product: Table Top
   - Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
   the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
   finish time) even though its expected duration is 2 hours

Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)

Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning

opw-2893622

closes odoo/odoo#97805

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