The quantity of the forecasted report was displayed without any precision specified

Steps to reproduce:
1. Install the Stock and Sales apps
2. Create a storable product
3. Create a quotation for this product with a quantity of 1.63
4. Confirm the quotation
5. Go to the product and open the forecasted report
6. The 'Not Available' quantity is -1.6300000000000001 instead of -1.63

Solution:
Specify the widget and decimal precision used for the quantity

OPW-2713548

closes odoo/odoo#81992

Signed-off-by: Arnold Moyaux <arm@odoo.com>

With a 308 redirection from `/url` to `/new_url`:
Links like `/url?a=a` should be rewritten to `/new_url?a=a` and not
`/new_url?a=a&a=a`.

closes odoo/odoo#81685

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

Reproduction:

- have 308 redirection from /shop to /boutique and refresh routes
- go in incognito on /boutique?order=name+asc (don't go on
  /boutique first, or restart odoo to clear ORM cache)
- select a sorting option eg. price

=> we are redirected to /boutique?order=name+asc?order=list_price+asc
and this error is shown:

Invalid "order" specified (is_published desc, name asc?order=list_price
 asc, id desc).

This is happening because url_rewrite is keeping current query string
(see ir.http()._slug_matching) and caching it. So if the first call
caches:

  url_rewrite('/boutique') => /boutique?order=name+asc

all other url_rewrite('/boutique') calls will give you
/boutique?order=name+asc even if the query string has changed.

In addition to that, url_for may append query_string to url_rewrite
return value, so you may get a double query_string such as:

?order=name+asc?order=list_price+asc

which causes the error.

In this fix, we restore the removal of query string that was removed in
3beb4545.

opw-2702036

Part-of: odoo/odoo#81685

Steps to reproduce:

- Create an account group for a range for example from 100000 to 200000
- Now edit the group to have a range from 100000 to 150000

Issue:

The accounts with code > 150000 are still in the account group

Solution

Adding an other intermediary table to the query in order to take into
account the accounts which have no group_id

opw-2695533

closes odoo/odoo#81475

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

The translation of purchase.order().notes name (Terms and Conditions) is
wrongly done in bulgarian since 2016
(d14efd56).

opw-2719178

closes odoo/odoo#81993

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

Inside a scrollable popup, the scroll was not correctly triggered when
moving one of its snippets through drag and drop.

This commit correctly defines the SmoothScrollOnDrag.$scrollTarget when
a modal is shown.

task-2431469

closes odoo/odoo#78813

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

When reversing the CABA entry, the CABA tax account was replaced by the transition tax account if not set on the repartition line.
To reproduce:
Set up a CABA tax with ACC1 as transition tax account and ACC2 as tax account.
When creating the CABA entry, there is a line on ACC1 and another on ACC2.
When reversing the CABA entry, both lines are now on ACC1.

Introduced by https://github.com/odoo/odoo/pull/79556



closes odoo/odoo#81986

Issue: 2718413
X-original-commit: d22cd547
Signed-off-by: Laurent Smet <las@odoo.com>

When validating a batch picking where some pickings have no quantities
done + some do, then avoid immediate transfers wizard and remove
pickings with no quantities done from the batch picking. This will make
it so users can validate a partially done batch picking in this case.

This is an adaptation of [1] (which is already deployed in 15.0)

[1] eb0ebc07

OPW-2711585

closes odoo/odoo#81981

X-original-commit: d43feb00
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: William Henrotin (whe) <whe@odoo.com>

Step to reproduce:
- Duplicate expense with a uom != of Unit

Current behaviour :
- Error telling that the unit is not correctly chosen

Behaviour After PR:
- The uom is copied on duplication and no error

opw-2714136

closes odoo/odoo#81638

Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>

Step to reproduce:
- Print a 'claim car report' on a car with no attachment

Current Behaviour:
- Print a empty PDF

Behaviour after PR:
- The landing page explain to the user there is no pdf to print

opw-2714493

closes odoo/odoo#81687

Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>

Hovering the shadow mode option reset the entire shadow instead of just
previewing the mode change.

Related to opw-2701512

closes odoo/odoo#81038

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to reproduce:

  - Install `website_hr_recruiment` module
  - Go to `your_website.com/jobs`
  - Activate Edit mode and add a "3 Columns" block
  - Select one of the columns and set the shadow to `None`

Issue:

  Shadow is not removed, and by default the "outset" mode is selected.

Cause:

  When we check the state of the shadow with `css('box-shadow')`, it
  will always be set because a custom css 'box-shadow' is set by the
  module website_hr_recruitment on card element, and therefore the value
  will always be either 'inset' or 'outset'.

Solution:

  If widget value is set to '', replace `box-shadow` style to 'none'
  (only if needed) so it will override the style from css file.

opw-2701512

Part-of: odoo/odoo#81038
Co-authored-by: qsm-odoo <qsm@odoo.com>

Steps to follow

 -  Go to project
 -  Select a project task with timesheet
 -  Edit the view with studio
 -  Edit the timesheet list view
 -  Enable 'Show Invisible Elements'
 -  Select 'Non-Billable'
 -  Uncheck 'Invisible'
 -> An exception is thrown

Cause of the issue

  attrs.column_invisible was used with invisible

Solution

  remove attrs.column_invisible

opw-2706370

closes odoo/odoo#81751

Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

Before, the system required a vat number on every partner, but that
is not required.  We need to send it as some other kind of ID however.

To clarify, a partner without vat is not for the simplified case only.

closes odoo/odoo#81906

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

* = website_livechat

Prevents from leaking unnecessary information to livechat clients.

opw-2453956

closes odoo/odoo#68946

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Steps to reproduce the issue:

  - Install eCommerce and Inventory module
  - Go to Settings
  - Ensure `Product Prices` is set to 'Tax included'
  - Ensure `Variant Grid Entry` is activated
  - Create a new Product as storable
  - Set `Sales Price` to $1.0
  - Set `Customer Taxes` to 10.00 %
  - Under `Variants` tab, set 'Sales Variant Selection' to 'Order Grid Entry'
  - Under `Variants` tab add an Attribute with 2 values
  - Set "Price Extra" to $2.0 to one of the variants
  - Go to the Shop and select the product

Issue:

  The extra price badge does not include the taxes
  ($2.0 instead of $2.2), however the final price does.

Cause:

  The price_extra field from ptav (used in the badge) does not include
  the taxes.
  However, when calculating the final price, we do first the sum of all
  prices (including the extra prices) and then apply the taxes.

Solution:

  In the template, for each 'variants', we call `_get_combination_info`
  to get the variant.price_extra with taxes included/excluded
  depending the `Product Prices` setting.

opw-2669871

closes odoo/odoo#81858

X-original-commit: 83c927f3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Before, the 'success' key was removed from the results
of the invoice processing and as such the invoice
was never put as successfully sent, but you sent it
again and again.

closes odoo/odoo#81902

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

In urllib3 1.25, an _is_key_file_encrypted method was added
where urllib3 checks if the keyfile is encrypted or not, but
urllib3 uses filenames, while we want to use the contents of cert.
So, in our case, this gave a traceback because it could not open
the file.

The final simple solution for now is to keep keyfile empty as
we store our info in certfile anyways already.

Part-of: odoo/odoo#81902

It's possible to confirm an invoice with an archived bank account of
the recipient. But it's not making any sense, since the bank account
is archived.

It's why we need to raise an error if the user want to confirm an
invoice with an archived bank account.

opw-2704605

closes odoo/odoo#81287

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

Step to reproduce:
- Have a fleet contract that need renewal

Current Behaviour:
- A new activity is created everytime the scheduler is called

Behaviour after PR:
- A new activity is only created if there is no current renewal activity present when the scheduler is called

opw-2713537

closes odoo/odoo#81671

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

Journal entries related to a POS session without cash are wrong

Steps to reproduce:
1. Install the Point of Sale and Accounting apps
2. Go to Point of Sale -> Configuration -> Point of Sale and create a new one
3. Remove the payment method 'Cash' for this POS and save
4. Open a session in this POS, sell something and then close and post journal entries
5. Open the Journal Items related to the session

Solution:
Fix the account_move_line query to match the statement_id with the session's statement_ids

OPW-2684748

closes odoo/odoo#81790

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

There is an issue when exporting pdf using edi documents created before
the PDF/A commit. With the subtype now included, the system would try
to use the subtype given by the ir.attachment which would not be formated
as expected by the pdf file format.

The attachment may get neutered by the ORM, so we may have to force
the mimetype when embedding it.

This fix in two parts will allow to force a subtype when adding an
attachment into a pdf, as well as parse the subtype of ir.attachment
to give them the right format.

xxx/xxx should become /xxx#2Fxxx

opw-2714040

closes odoo/odoo#81709

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

account.move.line has a journal_id field that is related on move_id.journal_id.
By searching on journal_id we avoid a useless join,
offering more room for database query optimizations.

closes odoo/odoo#81797

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.

closes odoo/odoo#81793

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

The goal is to ensure that 2 conditions are met for a fiscal position to
be applied (within the EU):

- The customer must have a valid VAT number from another EU Member State
- The goods must leave the country of origin

closes odoo/odoo#81817

Task: 2596204
X-original-commit: ca0fc6cd
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>

Current behavior :
When using cash rouding method "HALF-UP" if the difference between the rounded price and the original price was exactly the half of the cash rounding, the order would appear as unpaid.

Steps to reproduce :
- Create a rounding method of 0.5 (half-up)
- Sell a product for 11.25
- The order appears unpaid in the PoS orders list view

opw-2593687

closes odoo/odoo#81747

X-original-commit: 43a20a62
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

invoice line

Steps:
- Create 2 service products with "Invoicing based on timesheet" & " Create a task in sales order's project"
- Create a SO with both products > confirm
- Add hours to both tasks
- Create invoice > remove one invoice line > Save

Issue:
- The removed invoice line is still appearing in the Timesheet stat button

Cause:
- account_analytic_line.timesheet_invoice_id is set to the invoice when the invoice is created
- It is not reset to False when the line is removed from the invoice

Fix:
- Reset it to False when the move the line is removed from invoice

opw-2668814

closes odoo/odoo#81145

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

The filter 'Difference different than zero' is not correct

Steps to reproduce:
1. Install the Inventory app
2. Go to Inventory -> Operations -> Inventory Adjustments
3. Create a new Inventory Adjustments and start it
4. Change the number of Drawer counted so that the absolute difference is <= 0,498
5. Apply the filter 'Difference different than zero'
6. The line disappears although the difference is not null

Solution:
Specify the argument name 'precision_rounding' for the function 'float_is_zero()'

OPW-2699771

closes odoo/odoo#81808

X-original-commit: d60c3ed6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

closes odoo/odoo#81772

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

closes odoo/odoo#81776

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

When a kit is exploded to `stock.move` the quantity is rounded half-up
for every move. But during the invoice. The quantity to invoice on
kit is rounded up so it could result in differences between the
inventory valuation and the cost of the product

closes odoo/odoo#81588

Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>

Fix for task 2620026.

_get_bom_component_qty function is only referred to once in the whole odoo app,
which is on addons/sale_mrp/models/account_move.py#22.

The result returned from this function is used as a multiplier to quantity
to convert into the expected UoM. However, the quantity being referred to on
_stock_account_get_anglo_saxon_price_unit (qty_invoiced, qty_to_invoice), are
already converted into the SO Line's product's default UoM. In this function,
it however tries to convert 1 from SO Line's UoM to BoM's UOM.

With this, if Product UoM=x, SO Line UoM=y, BOM UoM=x, in the function _stock_account_get_anglo_saxon_price_unit,
the quantities will be multiplied by the same factor twice, resulting to the incorrect computation of price_unit to follow.

Part-of: odoo/odoo#81588

Consider this example:

- Create a 42% tax, price-included, with two tax repartition lines doing +100 -100
- Create an invoice of 100€ using this tax, and look at the move lines generated

==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line.

This is wrong, as we'd expect to see:

- 100 in payable/receivable
- 100 for the base line
- 42 for the +100 tax repartition line
- -42 for the -100 tax repartition line

The two tax lines are missing because the compute_all considers the tax as a 0% one, because of the +100 -100 stuff.

OPW 2716083

closes odoo/odoo#81733

X-original-commit: 24d32f3d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

When clicking on save, the saved HTML should be what the user currently
sees. Before this commit, there might be cases where clicking on save
actually triggers a DOM update which occurs too late for the change to
be considered for the save. In 15.0, this manifests for example with
the blog cover saving*: if the color is being changed with the
colorpicker and that the user does not close the colorpicker before
saving, the color change is not considered because the previewMode=false
update of the colorpicker is not received. With this commit, we ensure
that DOM updates which occur because of the click on the save button
are considered before saving.

* That bug is however due to two other issues which are being fixed with
  the PR at [1].

[1]: https://github.com/odoo/odoo/pull/79028



closes odoo/odoo#81732

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

Before this commit, the ripple effect did not work when a button was not
in the same location/size when clicked compared to its position/size
when the page was loaded. (e.g. after scrolling the page)

task-2686370

closes odoo/odoo#80611

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

Problem 1: The context was not passed when calling the resequence function.
Problem 2: Also, the subsequent read operation did not pass the full
context, but only the context of the user, not the context of the action.
A test has been added for the basic model to check that the context is properly
given after a resequence.

closes odoo/odoo#81477

X-original-commit: 9b665ba8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>

Current behavior:
When a user doesn't have any HR access right he cannot access his own profile

Steps to reproduce:
-Go to the demo user settings
-Remove all the right in the HR section
-Log into demo account
-Try to access My Profile

opw-2712593

closes odoo/odoo#81653

X-original-commit: ee932eab
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

No notifications should be received whilst in Kiosk Mode.

closes odoo/odoo#81454

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