Due to floating point limitation, the quantities displayed in the
forecasted report should be formatted to ensure the rounding.

Issue example:
(Need stock)
1. Create a storable product P
2. Update its quantity to 7.1
3. Consult the Forecasted Report

Error:
Quantities are "7.1000000000000005 Units". In this case, the
floating-point issue comes from the method `float_round()`

Another example:
(Need purchase_stock)
1. Create a storable product P
2. Update its quantity to 0.1
3. Create a PO with 0.2 x P
4. Consult the Forecasted Report

Error:
The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This
field is directly computed while rendering the report, it's the sum of
0.1 and 0.2 which, in python, results in 0.30000000000000004
(floating-point issue)

Since the rounding of these quantities are actually based on the decimal
precision of the UoM, this commit may slightly change the report.
Suppose the generic precision is .001 and the precision of "Units" is
0.01: if the quantity is 12.34, one zero will be added in the report:
12.340. However, these unnecessary zeros do not change the information
that is initially displayed. Moreover, the UoM precision can not be
greater than the generic precision, so we will never lose a part of the
quantity to display.

OPW-2611892

closes odoo/odoo#78773

Signed-off-by: William Henrotin <Whenrow@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#78793

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

Steps to reproduce:

* Create PO
* Confirm Receipt Date
* Cancel PO
* Draft and Confirm again

Current behavior:

* Button for Confirm Receipt Date is not visible

Expected behavior:

* Button for Confirm Receipt Date should be visible

This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO.

With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again.

closes odoo/odoo#59674

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

The active field of stock_valuation_layer is related to product_id.active.
Adding auto_join = True avoids bloating search/read_group queries in
expression.parse().

closes odoo/odoo#69198

X-original-commit: 2526c640
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

How to reproduce the problem:
- Install hr_timesheet and create a project.
- Create a task in the project, and assign a Partner as the Customer
- In the Timesheet tab of the Task, add a new entry. Save the Task.
- Edit the task again and change the Customer. Save again.
-> the partner on the Timesheet entry did not change.

With sale_timesheet, the Sales Order Item of the timesheet entry can
be updated from the Sales Order Item of the Task, but it isn't the case
with the partner, which is not logical.

Solution : Now, the partner_id is computed and will automatically be
updated from the Task's Customer/partner_id. If sale_timesheet is
installed, it will first filter out the invoiced timesheet entry:
we don't want to change an already invoiced entry.

opw-2616784

closes odoo/odoo#78577

Signed-off-by: LTU-Odoo <IT-Ideas@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
Forward-Port-Of: #78570

Cherry pick of 32d34ffb04b3c6a8397c8ff7eb4e8a3dd9fb8a95

closes odoo/odoo#78701

Signed-off-by: bon-odoo <nboulif@users.noreply.github.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#78724

X-original-commit: 6099c366
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

before this commit,
it was raising an error while try to preview the certificate

after this commit,
prevent the preview of certificate, as it is not possible to
set the preview of certificate

task- 2623276

closes odoo/odoo#75116

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

In activity view, the deadline date that has no timezone is formatted
from UTC to local timezone, so if the timezone is negative, we display
by error the previous day (eg. 24 october instead of 25 october).

With this commmit, we interpret the date in local timezone so there is
no timezone issue.

note: no test added since this only happen on browser with negative
timezone which would be hard to test.

note: this was fixed similarily in 13.0 with 07355470 but must have
been lost in a refactoring.

opw-2629681

closes odoo/odoo#78681

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

While installing 'crm_iap_lead_website' module, 'website_crm' module is
automatically installed(auto install based on website and crm), and it
introduces m2m field 'lead_ids' on visitors, as well as 'visitor_ids'
m2m on leads.

The issue is, 'website_crm' is installed automatically in this case,
but does not depend on 'crm_iap_lead_website', and one can therefore
uninstall 'website_crm' without knowing it may impact
'crm_iap_lead_website' (the 'lead_ids' field is defined in 'website_crm'
and it is used in 'crm_iap_lead_website', and so trying to access it
from 'crm_iap_lead_website' in this scenario will introduce a traceback).

Other point to note: as we have no visitor field available in
'crm_iap_lead_website' (many2many added in 'website_crm'), we cannot
manually search for leads as we do not have the information (we could
make a fallback on visitor.partner_id if set, but that would be much
low-level management just for a corner case).

Considering above points, to avoid the traceback, instead of directly
accessing the 'lead_ids' field, we simply check that whether the field
exists or not. If it does not exist, we simply consider that no leads
are attached to the visitor and we create the reveal view. If the field
is there, the flow remains the same.

Task-2655439

closes odoo/odoo#78355

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

Release notes:
https://github.com/odoo/owl/releases/tag/v1.4.7



closes odoo/odoo#78644

Fix: memory leak in some templates
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Currently, DDT use the product_uom_quantity of product for the ddt move which is inaccurate in case of no-backorder change in quantity

The fix correctly check if the done quantity is other than 0 for the delivery and if it is, use it as the delivery quantity

opw-2663174

closes odoo/odoo#78184

Signed-off-by: Florian D <fdamhaut@users.noreply.github.com>

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#78623

X-original-commit: bb8bef5c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@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#78595

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

When updating a PO generated by the scheduler, if the user decreases the
quantity and then confirms the PO, the picking quantity will be
incorrect

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the company's warehouse WH:
    - Incoming Shipments: 3 steps
3. Create a product P:
    - Product tye: Storable
    - Add a vendor
    - Add a reordering rule:
        - Location: WH/Stock
        - Min: 1
        - Max: 100
4. Run the scheduler
5. Edit the generated purchase order PO:
    - Quantity: 80
6. Confirm PO
7. Open the picking

Error: The quantity delivered is 100, it should be 80

When computing `qty_to_attach`, we should use the minimum between
`product_qty` and `move_dests_initial_demand` (note that in the case
above, `product_qty` is 80 and `move_dests_initial_demand` is 100). This
won't change the end of the method: if `product_qty` is greater than
`move_dests_initial_demand`, another move will be created based on
`qty_to_push`. Otherwise, no additional move will be created.

OPW-2616287

closes odoo/odoo#78575

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#78586

X-original-commit: e7d45695
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>

Bug
===
If you send a URL (which will be transformed into a link tracker) to
an external website (e.g. in mass mailing, social, ...), the UTM values
will be added in the GET parameters of the URL.

The external website might crash if those parameters are not supported
by it.

We want to add a system parameter `link_tracker.no_external_tracking`
to be able to not add those UTM values in the redirected URL.

This is done only for external website, because it will never be an
issue if the URL redirect to Odoo.

Task-2657413

closes odoo/odoo#77493

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

XML-ID 'chart8111' was set for account 811, which didn't really make
sense. Changed to 'chart811'
Also adapted the translation files accordingly

closes odoo/odoo#77073

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

There was a change in 0248f173 with a missing adaptation of POT so some
terms became not translated (but still translatable manually).

It should have been fixed in c0ab3360 but it seems there has been an
issue in the source, so it was still not translatable.

opw-2669973

closes odoo/odoo#78552

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

Before this commit, it was possible to edit scroll buttons with the
editor toolbar.

task-2656662

closes odoo/odoo#78532

Related: odoo/design-themes#518
Signed-off-by: Quentin Smetz (qsm) <qsm@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#78536

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

Expected Behaviour

When a user reply to a mention (on an invoice, a client profile, ...) in a log_note, and this user answers directly in the chatbox, the answer should be considered as an internal discussion, and so be posted as a log_note.

Observed behaviour

Since V12, when a user reply in the chatbox, the reply is automatically set as a "send-message" reply, which is a issue as the user sends an email to all followers of the discussion while he probably thinks his answer will be visible only by the internal users.

Reproducibility

This bug can be reproduced following these steps:
1. Declare at least 2 users (A and B) and make sure user A handles notifications in Odoo
2. Log as user B, go anywhere in Odoo as user B and mention the user A in a log_note
3. Log as user A, open the mention notification and reply in the chatbox
4. The answer will be noted as a send-message answer, sending then e-mails to all followers ...

Problem Root Cause

As long as the V12 isn't supported anymore, we didn't investigate this version. In V13, the issue comes from the fact the chatbox didn't use the same composer class as the discussion module, and then it's not possible to send a log note from the chatbox. In V14, as the discussion module has been totally refactored, the "error" comes from the arbitrary choice to set "false" as the default value of "isLog" on a general message, which implies that the answer from the chatbox is considered as a "send-message" and not as a "log-note".

Related tickets

opw-2602712
opw-2659484

closes odoo/odoo#78520

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

If we set a date manually via the input while the datepicker widget is displayed and we click outside the widget while remaining in the dropdown custom filter, a traceback appears.
Because two triggers on datetime-changed are done almost at the same time change.input hide.widget

Now we ignore lib events for `_datetimepicker()`

OPW-2591874

closes odoo/odoo#78394

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

This warning was introduced before the upgrade scripts ir.model.fields
unlink overrides and is now irrelevant in odoo upgrade process.

This checks breaks the exception mechanism used to add computed
fields in stable.

closes odoo/odoo#78521

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Current Behaviour :
1. Enable Work Orders
2. Add an operation to a BOM
3. Disable Work Orders
4. Create a manufacturing order for this product and finish the manufacturing.
5. Print the production order

What is the current behavior that you observe?
The production order has the operations in it even though the work order option has been disabled. This is because disabling the work order option just hides the operations and does not remove it from the BOM.

What would be your expected behavior in this case?
The printed production should not show the operation.

opw-2660545

closes odoo/odoo#78244

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

After some analyze on a lot of customer databases, seems like most of the time
their are performance probleme, and big store, it is due to  a lot of big file
uploaded without reason. E.g. barcode, photo, ... a small one will be enough.

Now, we decided (in stable) to auto resize these pictures to 1920x1920px
by default and compress it with a quality of 80 when the source is bigger.

You can bypass this behaviour in your specific use case,
using a context key: 'image_no_postprocess' set to True.

You can disable the resize (and quality implicitely)
using an icp: 'base.image_autoresize_max_px' set to '0'.

You can change the default resize (1920x1920) format using an icp:
'base.image_autoresize_max_px' set to '<width>x<height>' (e.g. '1024x768')

You can change the default quality (80) using an icp:
'base.image_autoresize_quality' with a value between 0 and 100 where 0 skip it.

You can change the type of file that will be post process using icp:
'base.image_autoresize_extensions' (subtype of the mimetype comma separated).

Api of image has not be changed in this commit, only refactored to allow to
work with image directly without the need to encode/Decode in base64 the raw.

We decide to keep 1920x1920 by default instead of 1080p to avoid to resize
portrait picture in 1080px and stay consistent with field image_1920 that
return a 1920px image for width or height whatever the orientation.

closes odoo/odoo#78145

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

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

closes odoo/odoo#78419

Fixes: #68552
X-original-commit: afaff8fc
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.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" and check "Is an Event Ticket".

Task-2655226

closes odoo/odoo#78362

X-original-commit: 741086da
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Warehouse should not be modified when the salesperson is modified
on a confirmed SO

opw-2614063

closes odoo/odoo#78327

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

Description of the issue/feature this PR addresses:

When using analytical account and invoicing a fixed price sales order
item, which is linked to a project task, where timesheet has been
recorded, the invoice gets double counted into the project revenues -
both as Invoiced and as Other revenues on the project overview
profitability.

Current behavior before PR:

The invoice gets double counted into the project revenues - both as
Invoiced and as Other revenues on the project overview profitability.

Desired behavior after PR is merged:

The invoice gets counted only in the project revenues as invoiced/to
invoice on the project overview profitability.

This commit adds tests to assess this use case is covered.

PR : #78230

opw-2631163

Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Thibault Libioulle <tle@odoo.com>

This commit fixes multiple issues 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
- Add timesheets
- Create an invoice from the SOL
=> Inconsistencies in Other costs, counting the downpayment.

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.
- Include all services and not timesheetes  SOLs linked to project,
project task or project's analytic account in the invoice/invoiced
subquery.
- Remove the unused downpayment column in the subqueries
- Remove unused subquery (relative to downpayment)

PR : #78230

opw-2596224
opw-2631163

Before this commit, it was possible to drop an inline snippet (e.g.
badge, cards, etc.) next to a section when this section was a snippet
which can be dropped as main snippets or as inline snippets (e.g.
countdown, embed code, etc.).

task-2648348

closes odoo/odoo#76827

Signed-off-by: Quentin Smetz (qsm) <qsm@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#78462

X-original-commit: 83873965
Signed-off-by: pimodoo <pimodoo@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#78427

X-original-commit: 4289d173
Signed-off-by: William Henrotin <Whenrow@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#78435

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

closes odoo/odoo#77574

Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>

steps to reproduce the bug:
- Go to inventory > products > Create a new Product from ```product.template```
- Assign two vendors to the record
- Go to inventory > products > product variants > select the newly created product
- Remove any vendor and save

Problem:
An error indicating that the record ```product.supplierinfo``` does not exist or has been deleted will be triggered

In the ```product.product``` model, we have two One2Many fields ```seller_ids``` and ```variant_seller_ids```
which both point to ```product.supplierinfo```.
When we save, the write method will be called and will first delete the seller with seller_ids
and then try to update with variant_seller_ids but as both fields point to the same field,
the seller will already be deleted and an access error will be thrown

Solution:
As the two fields are never displayed at the same time in the view.
We can use the same invisibility condition to make them read only to prevent them from being both updated at the same time

opw-2661082

closes odoo/odoo#78431

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.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#78138

X-original-commit: f783e238
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: prro-odoo <proose@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#78401

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