Issue: When returning a product sold that is only made of kits and
validating the return, the delivered quantities of the sales order was
set back to the full amount delivered

Steps to reproduce :
  1) Install MRP and Sales
  2) Create a BoM Kit for a new product [Nested Kit] that has one or
    more consumable or storable product as component
  3) Create a BoM Kit for a new product [Main Kit] that has
    [Nested Kit] as component
  4) Create a SO for [Main Kit], confirm, validate delivery
  5) Check SO, 1 product is delivered (correct)
  6) Go back to the Delivery, create a return for the delivery
    (don't validate)
  7) Check SO, 0 product is delivered (correct)
  8) Now validate the return for the delivery
  -> Check SO, 1 product is delivered (bug)

Why is that a bug:
 Since the Main Kit was returned, the delivered should be 0 and not
 the full amount initially delivered. It was set back to 1 because we
 didn't look at the type of picking, when computing the quantity
 delivered, the fall back considered that if all the moves were done,
 everything was delivered, but it is the opposite when returning

opw-2542337

closes odoo/odoo#75256

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Expected behavior : The order button should go green and active when you 'unskipped' an orderline

Current behavior : The order button doesn't go green and can't be clicked when an orderline is 'unskipped'

Steps to reproduce the error :
First of all, you need to setup a PoS Restaurant with these options :
~ Bar/Restaurant
~ Enable `Table Management`
~ Enable and setup `Order Printer` with IP Address and choose Categories to be printed on.

1. Open a restaurant session
2. Pick a table
3. Select a product and put it on hold
4. Select the **same** product and order it
5. 'Unskipped' the product from step 3

Order button should be green and active but is unactive so the order can't be sent

Previously, the condition was only based on the product_id so error occurs when multiline of the same product are handled

opw-2557518

closes odoo/odoo#78608

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

quotation_description on the sale order is copied from the
product template, where it already is sanitize_attributes=False,
and it has to stay like that because otherwise widgets like
"tab" or "accordion" cannot be rendered correctly.

This is also linked to a bug in the ORM where the _related_attrs
weren't copied correctly.

Related ORM PR: https://github.com/odoo/odoo/pull/78687
Ticket link: https://www.odoo.com/web#id=2487749&model=project.task



opw-2487749

closes odoo/odoo#78723

Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>

before this commit: applying readonly attribute on toggle_button doesn't work,
toggle_button still clickable and value is still changed even though widget is
readonly, there is no effect of readonly attribute on toggle_button widget.

after this commit: if toggle_button widget has readonly attribute then it will
not be clickable, button of toggle_button will be disabled so that user can
easily understand that element is not clickable.

task-2339995

closes odoo/odoo#76426

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

Expected behaviour

A time-off responsible should be able to see the leave-request to validate, even if he is only reponsible and not leave-manager, at least as long as the leave validation is set on 'both' or 'time-off responsible'

Observed behaviour

If the leave validation is set on 'both' (and not on 'time-off responsible' only), the time-off responsible cannot see these leave request in the "To Approve" view, and only the leave-manager can see them.

Problem Root Cause

The issue is coming from a wrong domain definition (cf commit diff).

opw-2595054

closes odoo/odoo#78633

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

This commit ensure the pricelists are properly configured before launching a pos session.

Steps to reproduce:
- Have a V13 with point_of_sale
- Have minimum 2 companies A & B
- Select both companies in the company selector
- Go to Settings / General Settings
  - Point of Sale
    - Check Pricelists
- Go to Point of Sale
  - Open a pos.config PC
    - Set a Pricelist PL as Default Pricelist
- Go to Point of Sale / Products / Pricelists
  - Open PL
    - Set a company (must be different than PC)
- Go to Point of Sale
  - Click "New session" on PC
--> Traceback

In V13, the traceback shows as "Traceback not available"
As from V14, the traceback is shown properly

A variant would be to start the session before changing
the pricelist company then click on "Resume" on PC

closes odoo/odoo#78713

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

Steps to reproduce:

  - Install website_sale module
  - Enable discount and advanced pricelist in settings
  - Create product with sale price 0$ and set a website in
    eCommerce + publish the product
  - Create pricelist PPP with Discount Policy as
    "Show public price & discount to the customer" and selectable in the website
  - Go to the product and set an extra price of 10$ for the new pricelist
  - Go to the product in the eshop and select the pricelist PPP
  - Add the product to the shop cart

Issue:

  The price displayed is 0$ instead of 10$.

Cause:

  Since price_unit equal 0$, not possible to calculate the discount and
  therefore using the 0$ value.

Solution:

  Use price of pricelist in case 'discount_policy' is 'without_discount'
  and price_unit equal 0$.

opw-2652192

closes odoo/odoo#78570

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

When combining two pricelists, the unit price might be incorrect

To reproduce the error:
1. In Settings, enable:
    - Pricelists (Advanced)
    - Discounts
2. Create a product P:
    - Sales Price: $100
    - Available on website
3. Edit the Public Pricelist:
    - Add a price rule:
        - Apply On product P
        - Min. Quantity: SuperProduct
        - Compute Price: Percentage
        - Percentage Price: 63%
    - Discount Policy: Included in the price
4. Create a second pricelist:
    - Add a price rule:
        - Apply on product P
        - Compute Price: Formula
        - Based on: Other Pricelist
        - Other Pricelist: Public Pricelist
        - Price Discount: 25%
    - E-commerce Promotional Code: PROMO
    - Discount Policy: Show public price & discount
5. On the website, add P to the cart
6. Edit the cart:
    - P's quantity: 500
    - Apply PROMO code

Error: The new price is $75 instead of $27.75

`_website_product_id_change` already returns the correct price value, so
the latter shouldn't be computed again (moreover,
`_fix_tax_included_price_company` should use the price with the pricelists
applied instead of the default product price)

OPW-2605804

closes odoo/odoo#75371

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Part-of: odoo/odoo#78570

Steps to reproduce the bug:
- Go to purchase > Configuration > Vendor Pricelists
- Filters > select the “Active” filter

Problem:
Currently, the filter does not include records that do not have a specified `”date_end”`, even though they are considered active.

Opw-2659829

closes odoo/odoo#78515

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

When invoicing a product with multiple variants and with anglo_saxon_accounting, the COGS would be the wrong amount.
The function _stock_account_get_anglo_saxon_price_unit() was selecting the first BOM among all variant BOMs.
Using the variant_bom_ids when existing prevent this situation.

OPW-2662863

closes odoo/odoo#78428

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

Steps to follow

- Enable group_show_line_subtotals_tax_included
- Create a repair order and add a tax to a line
-> The subtotal doesn't contain the tax amount

opw-2513287

closes odoo/odoo#76427

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

We create the document types data with a csv file, but the active field
should be not updatable so the users could active or inactive records.

closes odoo/odoo#78484

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

Current behaviour:
Unbuilding order use the last BOM created for the product

Expected behaviour:
Unbuilding order should use the BOM that has been used for the MO

Steps to reproduce:
Create a product with a BOM
Create a MO and mark it as done
Create another BOM for the same product
Create unbuild order for the MO
The wrong BOM is selected by default

opw-2636632

closes odoo/odoo#78467

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

closes odoo/odoo#78387

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

There was a missing translation for apply/cancel button in
daterangepicker widget. With this change, we provide the odoo
translation to the library when initializing the picker.

opw-2628117

closes odoo/odoo#78518

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

Since changes made in currency rate default value made in this PR
https://github.com/odoo/odoo/pull/76513

 the date is stored based on user
timezone, and so doesn't work if the test runs around midnight with the
belgian timezone on the servers.

closes odoo/odoo#78452

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

This commit fixes issues with downpayment and credit notes in project
profitability report.

Steps to reproduce opw-2596224:
- Go to sale
- Make a RFQ for a service product with service_policy set at
delivered_timesheet (Timesheets on tasks), set quantity as 10
- Confirm order and create two invoices for 15%, confirm the two
invoices
- Create a credit note for one of the invoice and confirm it
- Go back to the Sale Order and click on Project Overview
=> Inconsistencies (Downpayment reported twice)
- Add an expense
=> Inconsistencies in expense amount untaxed invoiced

This issue is fixed by :
- Excluding downpayments which are linked to a reversed invoice line
- Use expense amount to invoice and expense amount invoiced separetely
in the project overview.
- Do not report not invoiced SOLs in the expense amount invoiced.
- Exclude negative amounts in analytic account which are linked to
credit notes.

opw-2596224

closes odoo/odoo#78310

Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

This commit makes the picking search by product more consistent with
the general product search as the following case could happen:

  - Have a product with two variants;
  - Each variant has the following internal reference:
    - Variant 1: 'SoMething'
    - Variant 2: 'SomethingElse'
  - Create two pickings, each one containing one of the variant;
  - Then filter pickings by product and the result will vary:
    - Searching for 'SoMething' -> Found one picking
    - Searching for 'Something' -> Found two pickings

The expected behavior is to find the two pickings in both cases.

opw-2646214

closes odoo/odoo#78085

Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>

Steps to reproduce:

- Set the Decimal Accuracy at 5 digits for Product UoM
- Create a product X
- Create a kit BOM for X with a component Y, and qty 0.08600
- Create a Sale Order for 10 product X, confirm and deliver all

Issue

- On the SO, quantity delevered is 9.00000 instead of 10.00000, same
  issue occur with the same flow with a Purchase Order.

Cause

As the quantity per kit was rounded when calling _compute_qty,
the calcul of quantity ratio was not well computed.

Solution

Avoid rounding the quantity per kit, as the quantity ratio is rounded
a few steps after.

opw-2590126

closes odoo/odoo#78400

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

Translation files contained multiple instances of the same reference.
This caused a traceback when loading the translations.

closes odoo/odoo#78398

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

On sale.order.line, the onchange on product_packaging ensures that a warning
is raised when changing the package if the qty on the line is not a multiple
of the package qty.
With this commit, a same warning is raised when changing the qty if the qty
on the line is not a multiple of the package qty.

closes odoo/odoo#49150

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

Creating lots of production lot can take a huge amount of time if the
mail message follower is added on each chatter.

This commit removes this functionality to speed up the creation as
there is no real need to have the lot creator as follower of it.

closes odoo/odoo#78370

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

Searching the stock move line candidate to update at reservation can be
shorten by breaking the loop once one is found

Part-of: odoo/odoo#78370

Part-of: odoo/odoo#78370

The recomputation of stock move state is often done with already
the correct state (for instance in the case of move line deletion only
one of the deletion will change the state).

This commit check the move state before changing it only when it's
necessary.

Task: 2507143
Part-of: odoo/odoo#78370
Co-authored-by: Remy Voet <ryv@odoo.com>

Steps to follow

  - Set the thousands_sep of the current lang to an empty string or null
  - Create a report
  -> The thousand separator from the system locale will be used instead to format numbers

Solution

  Use an empty string if there is no thousands separator

opw-2507441

closes odoo/odoo#75868

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

In some cases when creating a new ticket, the default product
type shown is a "Consumable". It should rather be handled as a
"Service". In later versions, a detailed type is created, but the
base product type should be set to service too.

This commit uses the `product_id` `context` to set the default
type to "service".

Task-2655226

closes odoo/odoo#78046

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

closes odoo/odoo#78328

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

scrap_qty field was missing the digits attribute, and therefore the user
could not create a scrap with a quantity with more than two decimal places.
With this commit, scrap_qty will follow the 'Product Unit of Measure'
precision setting, just like any other quantity fields.

closes odoo/odoo#78220

X-original-commit: 14322fc4
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

In case an invoice is already paid it is useless to provide
a QR Code for scanning to pay a residual of zero.

closes odoo/odoo#77997

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

The processing of the LINK command in a one2many should fail when the
line being linked does not exist.  However, there is one case where it
should not fail: when that line existed and was linked before applying
the commands.  That use-case may seem strange, but it actually exists:
deleting a line in a sales order automatically deletes the corresponding
reward lines.

closes odoo/odoo#78014

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

When calling `_get_signup_url_for_action` on more than one partner,
because the `url` input parameter was re-used for the actual signup
URL before assigning to the partners map (in
559bdc97), from the second iteration
onwards the signup URL will almost certainly get misgenerated to
redirect to the previous signup URL (accumulating).

As `signup_url` is not normally accessed in bulk this should not
usually be an issue.

Reported by Andreas Brückl

closes odoo/odoo#78196

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

new transaction

Previously, when cancelling an Ingenico transaction, the cancellation
was considered done from the POS' point of view even though it hadn't
actually finished on the terminal yet. Starting a new transaction from
the POS meant it would fail and the POS and terminal's states would get
out of sync.

In an enterprise PR for the pos_iot module, a fix was made so the
cancellation request is only considered done when the terminal has
confirmed that.

In the case of pressing cancel on a payment line, this means that the
button will block and remain in a loading state with a spinner until
the operation finishes. After this the user can press the retry button
the payment line.

There are two other workflows where waiting for the cancel operation to
finish wasn't done until now, and that's what this PR is for.

The first is when a transaction was requested and the
back button was pressed in the UI. This cancels the active transactions.
If you wait a while after pressing the back button, the UI will be
notified when the cancellation finishes, and the payment line's state
will be updated in the local db, even if it's not visible on screen.
When you go back to the payment screen, you'll be able to retry the
transaction again. However, if after pressing the back button you
immediately go back to the payment screen, you'll see the spinner of the
wait for the cancellation, but it would never update. That's because
while the local db gets updated when the cancellation finishes, the
payment screen lines didn't get refreshed. Hence a call was added to
`stop_electronic_payment` that re-renders the payment lines (if we are
present on the payment screen) once the cancellation finishes. In this
way, the payment state in the UI will correctly update.

The second case is when a transaction is requested and the user deletes
the payment line. This used to happen immediately without waiting for
anything. This PR changes that so the line goes to the `waitingCancel`
state instead, and will only be deleted once the operation finishes. If
there's nothing to be cancelled, the line will get deleted immediately
like before.

opw-2525010

closes odoo/odoo#77585

Related: odoo/enterprise#21342
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Before this commit, selecting elements on a newly added slide of the
carousel was not displaying the editor overlay.
It was due to the fact that adding a new slide to the carousel was done
making a deep clone of the slide, and therefore of its editor.
Now, the slide is cloned without its editor.

task-2657532

closes odoo/odoo#77335

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

How to reproduce the problem:
- Install the website_slides modules
- Go to the website -> Courses -> choose a course -> Add Content (Webpage)
- In the new Webpage -> Edit -> Drag and drop a Form Builder -> Save
The form is unusable: you can't write in the form's fields.

Cause of the problem : usefull attributes and values of the form were
removed due to the sanitizing of the HTML component.

Solution : the HTML components in slide are not sanitized anymore,
in order to keep valuable information for building forms.

opw-2588089

closes odoo/odoo#77128

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

1. Have Bank journal with 'Post At' is set to 'Bank Reconciliation'
2. Create and validate a bill with reference and register a payment.
3. For said payment create a bank statement line.
4. Be sure to have other posted account.move.line's with a similar
reference so they could be considered for this payment (if that's not
the case reconcile will work but only because it will fall back to
checking any move lines for the partner with matching amount regardless
of the reference).
5. Try to reconcile.

The proper move line of the payment will not be selected. This occure
because it's not correctly detected the communication flag of the draft
move, thus not giving the correct priority.

opw-2657393

closes odoo/odoo#78090

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

Bug introduced by this commit: https://github.com/odoo/odoo/pull/76965/commits/509db2371f9122a47af867e3b90841e115c712cf



Steps to reproduce the bug:
- Install purchase and mrp
- Add to “Marc Demo”, user access rights only for purchase app
- As demo, Create a PO and add any product
- Confirm the PO

Problem:
An access error is triggered when searching for a BOM linked to the selected product in the POL

closes odoo/odoo#77754

X-original-commit: c7476f80
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

Have two taxes included in price in two different companies
Have a product with both taxes
Have the 2 companies selected
Make a SO and add the product

The price on the SO will add both taxes rather than just 1

opw-2657752

closes odoo/odoo#78032

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