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>

This is internal data that does not need to be shown to the user

Partially backport the changes from 49429f98 to file_open to be
able to use it in the assetsbundle

Using an explicit list of sign up parameters will avoid
polluting the context with unrelated values, and make
debugging easier.

Fix of 57665a02 which was problematic in point_of_sale

task-2388659

task-2376327

Only admin users should be able to load demo data, if needed.

This is only possible from the settings dashboard, and thus,
the method could be decorated.

See: c002e2eb

Before this commit, it was possible to drag and drop a popup inside an
oe_structure which was itself inside an other oe_structure (e.g. snippet
parallax). It didn't make sense and moreover created bugs.

After this commit, it is no longer possible to drag and drop the popup
snippet or the newsletter popup snippet in a substructure.

task-2491976

closes odoo/odoo#81613

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

Steps to reproduce:
-Create a quote with 2 lines (same product - different lead time).
-When a partial delivery is made (e.g., 5 of 10), Odoo places the operation related to the remaining undelivered quantity (5), on the last line in the Operations list.
-When the next delivery is made, Odoo deducts the quantity from the first operation in the list instead of from the line whose deadline is closest.

Current Behaviour :
Odoo assign button assign quantity to the first move line in the list.

Behaviour After the PR:
Odoo assign button assign quantity to a move line based on the priority, the closest deadline and the id.

opw-2657048

closes odoo/odoo#80534

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