Attachments that are uploaded on a record that isn't saved yet are
created with res_id set to 0. In the case of attachments linked through
a m2m rather than the usual (res_model, res_id), it means they may not
be readable afer the creation of the record, except by their creator.

Re-attaching them to the mailing / template at the end of the create()
call fixes the ownership.

Fixes #81935

closes odoo/odoo#82106

X-original-commit: 3857629a
Signed-off-by: Olivier Dony <odo@odoo.com>

read_group on "stock.inventory.line" could result in a memory error when the database possess to many stock.inventory.line
Those filters were removed on commit ba92e1da by AVD to prevent a test error where those fields were False. On his advices, I re-added them with the '|' comparator handle the False cases.

OPW-2714644

closes odoo/odoo#81998

X-original-commit: 7e13cc7a
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Before that, uploading a file from a kanban was adding res_id=0
Was missing from 5e81850e

closes odoo/odoo#82089

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

with l10n_mx_edi_stock being introduced in enterprise - we require the unit of measure object in the aggregated lines so that it can be used on the delivery report.

odoo/enterprise#21591
Task-2585661

closes odoo/odoo#82086

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

*: web_editor, point_of_sale, pos_restaurant

The grab cursor is currently not working on all browsers (at least
Chrome Linux). The fallback rule does not even work, meaning that if
you type:

```
cursor: move;
cursor: grab;
```

Those browsers does not even use "move" as they see "grab" as valid but
use the "default" cursor.

This commit replaces our "grab" uses with a local cursor ensuring it
works.

Related to task-2431469

closes odoo/odoo#82071

X-original-commit: c8e4e1e9
Related: odoo/enterprise#23182
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Current behavior :
When creating payment from invoice, the payment had the wrong sales team id

Steps to reproduce :
- Create atleast 2 invoices with different sales team and same partner
- Register payments for every invoice
- Go in payments list view
- Filter on partner and group by sales team
- All the payments are grouped in the same sales team

opw-2681041

closes odoo/odoo#81593

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

Backport of 3891ab34 to 14.0 following f2c1ee5a
It was not possible to print payslip report

Purpose
=======

If the user doesn't have access to ir.ui.view (aka no admin or
website access rights), printing a report with a configured
external layout will lead to a traceback, as it's forbidden
for the use to read on the field "key" on the related ir.ui.view.

As we only want to retrieve the view key, this is safe to use
sudo at that point.

Fixes odoo/odoo#81960

closes odoo/odoo#82050

Related: odoo/enterprise#23159
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

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