Some of the support scripts use xml-rpc calls to work
on pos.session on Saas or SH databases
(especially when needed to upload lot of offline orders
in smaller batches)
These scripts should be allowed to close any rescue session
created during this process programmatically via xml-rpc.

Our xml-rpc protocol does not allow to call function that
return nothing

closes odoo/odoo#78909

X-original-commit: 834bed30
Signed-off-by: Masereel Pierre <pim@odoo.com>

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

X-original-commit: e90452bf
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>

Purpose
=======
Fix guest users receiving confirmation emails for events by "Public User".

Specifications
==============
Confirmation emails for events are sent by:

- Organizer (if set)
- Company email (if set)
- The users's email
- Odoo bot otherwise

Task-2657588

closes odoo/odoo#78849

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

(Backport : fbf76c1f)

Expected behavior : Quantities are displayed in the same way on the delivery note regardless the stock picking stage.

Current behavior : Quantities aren't displayed in the same way on the delivery note depending on the stock picking stage. (e.g. `2.00 Units` units when picking is in `Waiting` stage but `2.0 Units` when picking is in `Done` stage)

Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 2 units)
- Go to the Receipt and print the Delivery Slip and look at the quantities printed (e.g. 2.00)
- Validate the Receipt and print the Delivery Slip again, quantities printed have changed (e.g. 2.0)

opw-2578120

closes odoo/odoo#78815

Signed-off-by: Arnold Moyaux <arm@odoo.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#78829

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

Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected.

Doc:

https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml

https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/



OPW 2662476

closes odoo/odoo#78651

Related: odoo/enterprise#21790
Signed-off-by: Josse Colpaert <jco@openerp.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#78818

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

Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.

Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`

Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)

Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`

But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`

The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received

opw-2600221
opw-2613116

closes odoo/odoo#78286

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

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>