Expected behaviour:
When you create a sale order with a project associated. When the sale order change state
from non upsell to upsell sales person should receive one email.

Current behaviour:
The sales person receive an email for every entry in the timesheet after the sale order goes
from non upsell to upsell.

Step to reproduce:
Create a sale order setup to create a project and task and the invoicing policy is ordered quantities.

Add a timesheet entry which takes it past the ordered quantity.

Create the invoice for the order.

The state of the line and order goes to upsell, and the upsell email is sent to the salesperson.

Add another line in the timesheet and the email is sent again to the salesperson

closes odoo/odoo#78457

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

Before this fix, if the country is not set on the company
the loading of the session may stall at some point.

A check is added and will prevent to start a session if the country
is not set.

opw-2557989

closes odoo/odoo#79212

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

When exporting, the delivery address is put inside the xml.
This field is added by the 'sale' module and is not supposed to be displayed for vendor bill.
However, even if this field isn't displayed, the factur-x module was setting the wrong delivery address on it.

closes odoo/odoo#79194

Issue: 2668902
X-original-commit: 75b23371
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Laurent Smet <las@openerp.com>

Steps to follow

  Edit the account.move view (with studio for example)
  Set the lines readonly property to [["partner_id","=",False]]
  Create a new move
  Add a partner
  Add a product
  Remove the partner
  -> A traceback appears: widget.$el is undefined

Cause of the issue

  widget.$el is used after the widget has been destroyed

The fix was already present in 14.0 (3fd7b200)
but we still need to keep the test

opw-2557142

closes odoo/odoo#79066

X-original-commit: 0bfc05c2
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

The constrains on orderpoint location being related to the warehouse view
location was too restrictive especially in a complex subcontracting flow
with dropship.

This commit change the constrains to only be triggered if the two
location to be compared have both a warehouse.

closes odoo/odoo#79126

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

Steps to reproduce:

  - Install eLearning module
  - Go to eLearning, open course Basics of Gardening and edit it
  - Click on `How to Grow and Harvest The Best Strawberries | Basics`
  - Upload an encrypted PDF as Attachement

Issue:

  Traceback is raised :
  utils.PdfReadError("File has not been decrypted")

Cause:

  When trying to calculate `completion_time` to read pages, we try to
  get the number of pages of the pdf but an error will be raised if the
  pdf is encrypted.

Solution:

  If not possible to get number of pages, we dont set/update the
  completion_time.

opw-2612529

closes odoo/odoo#78997

X-original-commit: 8eac4109
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

This allows to avoid tens of thousands of instructions being done at
each click in the editor.

At multiple places, the editor is asked to close all its widgets (for
example, when clicking on another snippet to edit). The original cost
of that action was to remove a class on each widget, which is a very
primitive action. But in the end we had to do more to close a widget: we
trigger_up an event and ask to close all sub widgets. When we ask the
editor to close all widgets... it makes sense not letting every sub
button of every select trigger_up an event.

closes odoo/odoo#79217

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

- Go to Email Marketing
- Create a new mailing with template having social media links
- Save
- Click on one of the social links
An error is triggered:
"Error: Blocked a frame with origin xxx from accessing a cross-origin frame."

The traceback occurs because we try to change the content of something we
don't have access to, as these sites prevent display in an iframe.

opw-2599540

closes odoo/odoo#79188

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

Steps to reproduce:

  - Go to any chatter
  - Click on "Send message"
  - Open the Full Composer
  - Click directly on the "Link" button of the composer
  - Add label and url then save

Issue:

  Link not added to composer.

Solution:

  Restore the "old range" only when selection is cancelled by focus.

Related fixes:
https://github.com/odoo/odoo/commit/da14e4449e5e318eb72e1b9f268fb797adb0c6a6
https://github.com/odoo/odoo/commit/d2f3c9e7975188753fa17c06db3fc5c73c773944



opw-2544149

closes odoo/odoo#79204

X-original-commit: 92588032
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

- Open session with cash control
- Set 300 €
- Close session
- Add Cash 50€
- Close session
- Set end Cash at 350 €

--> It raise an error

closes odoo/odoo#78780

Signed-off-by: Masereel Pierre <pim@odoo.com>

Stock.location is ordered by "complete_name" which is possible to be the
same (i.e. default production locations for different companies). This
may result non-deterministic order. Add "id" to avoid it.

closes odoo/odoo#79169

X-original-commit: 94a8ad3f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

If a work center is used in any routing, a warning will be displayed when it will be archived

opw-2658596

closes odoo/odoo#79087

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

In case you use products with variants or internal references, display_name is more specific than name.

closes odoo/odoo#79130

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

In last added migration script in https://github.com/odoo/odoo/commit/b40216a8ae8fefd03311b2884e7b83644baac0a1

, the code assumes the chart of account of l10n_es is installed. But happens that you may have installed several l10n_* modules, including l10n_es, but not having the chart of l10n_es installed (you have installed the chart of another module).

In this case, then the update crashes because tax_ids is None and tuple(tax_ids) crashes!

closes odoo/odoo#79024

X-original-commit: f5b21797
Signed-off-by: Olivier Colson <oco@odoo.com>

closes odoo/odoo#74896

closes odoo/odoo#78468

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Steps to reproduce:
1. Create Manufacturing Order with quantity >1 of Serial Tracked product
2. Press Mark done. (One Product will be immediated produced with a new
   SN auto-created)
3. Create Backorder
4. Press Mark done on the backorder

Expected Result:
Backorder will also be able to immediate produce and auto-create a new SN

Actual Result:
Usererror because env is still referring to original MO and tries to
produce the same SN again.

closes odoo/odoo#79123

Fixes: odoo/odoo#78134
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Currently, hovering on the tooltip displays some content out of
the viewport. It happens because tooltip content div requires
270px width to display the text and the distance between the
tour indicator and viewport is less than 270px

so this commit fixes the issue by changing the position of the tooltip
indicator from left to the top so that the tooltip indicator displays
top of the element and hovering on it displays the full content

TaskID-2667140

closes odoo/odoo#78529

Related: odoo/enterprise#21914
Signed-off-by: Laurent Smet <las@openerp.com>

This commit fixes the 'You need to supply a Lot/Serial Number...' message
when validating a receipt with backorder for subcontracted tracked products.

closes odoo/odoo#78062

Task: 2604664
Signed-off-by: Tiffany Chang <tic@odoo.com>

Suppose an automated AVCO product category. When confirming an invoice,
if the associated product was a kit and if its BoM has changed during
the process, a traceback can occur.

To reproduce the issue:
(Need sale_management)
1. Create a product category PC:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
2. Create 3 products P1, P2, P3:
    - Product Type: Storable
    - Category: PC
3. Update P3's quantity > 0
4. Create two bills of materials:
    - BOM01:
        - Product: P1
        - BoM Type: Kit
        - Components: 1 x P2
    - BOM02:
        - Product: P2
        - BoM Type: Kit
        - Components: 1 x P3
5. Create a sale order SO with 1 x P1
6. Confirm SO and process the delivery
7. Edit BOM02:
    - BoM Type: Manufacture
8. On SO, create the invoice INV
9. Confirm INV

Error: an Odoo Server Error is displayed with a traceback: "[...] in
_compute_average_price, bom_line_data = bom_lines[bom_line] [...]
KeyError: mrp.bom.line(19,)"

On step 7, when changing the BoM type, a new BoM line is created.
Therefore, in `_compute_average_price`, the BoM associated to the move
(i.e., `bom_line`) is not one of the lines in `bom_lines` (i.e., the new
BoM lines). There is already a check in case the line has been deleted,
but not if it has been changed.

OPW-2610685

closes odoo/odoo#78917

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

We create the document types data with a csv file, but the active field
should be not updatable so the users could active or inactive records.

closes odoo/odoo#78576

X-original-commit: a7ea6f21
Signed-off-by: Josse Colpaert <jco@openerp.com>

Fix a small logic bug which made it so draft outs would only show only
if there were also draft ins.

closes odoo/odoo#79037

Fixes: odoo/odoo#78872
Signed-off-by: Arnold Moyaux <arm@odoo.com>

commit 96b56ea3 fix the link between SO <-> MO in manufacture 3 steps
but break it on other configuration

It happens because without `store after manufacturing` the procurement
group is not copied and used on the MO. And the stat button search on
procurement group with a MO and a SO on it. Before it was searching
on `stock_move.created_production_id` and thus was able to find the MO.

This commit do a mix of the 2 solutions. It search for procurement group
linked to SO and MO + created_production_id to be sure to find all the
MO related to a SO

opw-2645042

closes odoo/odoo#79015

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The number that was there before was a TFN, not an ABN because of
confusion between those two tax numbers.
See
https://github.com/arthurdejong/python-stdnum/commit/cc3a970e893ebe6635982bcd49c48e6549cb5ac3
https://github.com/odoo/odoo/commit/a72f7222c9f5987a20461be9c837e3de73801ff7



closes odoo/odoo#78894

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

closes odoo/odoo#78883

X-original-commit: 83bb18e4
Signed-off-by: Olivier Colson <oco@odoo.com>

Fix https://github.com/odoo/odoo/commit/b40216a8ae8fefd03311b2884e7b83644baac0a1

 was merged though partially ready.

closes odoo/odoo#79005

X-original-commit: 880c32f9
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

Reproduce :
(With timezone GMT+3)
- Create any record R1 with previous day's date and time after 21:00.
- Create any record R2 with today's date and time after 21:00.
- Create a filter to show all todays records (Date is between "<TODAY'S DATE> 00:00:00 and <TODAY'S DATE> 23:59:59".

Result :
  Even though R1 is in yesterday's date, it will show in the list.
  R2 will not show in this list.

Explanation :
  This behaviour has been observed in several modules, for any timezone but UTC & only with custom filters default datetime values.
  The search was applied on [datetime(UTC) + 2 * offset] because the timezone wasn't correctly set.

Solution :
  Timezone is now correctly set on default datetime values.

closes odoo/odoo#75663

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

It may happen that there is a property defined on some field that is not
the default property, but rather the property associated to a record.
For example
```
=> select id,name,company_id,fields_id,value_reference,res_id from ir_property where name like '%property_stock_inventory%'
+------+--------------------------+--------------+-------------+-------------------+----------------------+
| id   | name                     | company_id   | fields_id   | value_reference   | res_id               |
|------+--------------------------+--------------+-------------+-------------------+----------------------|
| 528  | property_stock_inventory | 1            | 4665        | <null>            | product.template,752 |
| 6    | property_stock_inventory | <null>       | 4665        | stock.location,5  | <null>               |
+------+--------------------------+--------------+-------------+-------------------+----------------------+
```
In this case the property with id=528 is not a default property since
res_id is not NULL. Alternatively the property id=6 is a default one.

The issue here is that when searching for the missing locations we do
not filter out the properties with res_id not NULL, thus we may get that
a company has the location define while in fact it doesn't. Following
the example above, this means that we incorrectly get property id=528 as
the one defining the location for the company id=1 here:
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L107
This not only prevents the creation of the correct default property but
also the default locations
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L36-L51



On this patch we fix the domain search for default property. This allows
for the correct creation of the default locations and associated
properties.

This issue was observed during upgrade 40921, where it prevents the
upgrade to 15.0

closes odoo/odoo#78949

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

The "Save" / "Cancel" buttons were wrongly showing on the "My Profile"
page.

closes odoo/odoo#78820

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

Selection of multiple companies to view multi-company data was added
in v13, but at the time there was no way to have reports correctly
take into account currency rates when also working with multi-currency.
v14 onwards is able to correctly apply the currency rates, therefore we
fix the purchase report to do so.

Steps to reproduce:
1. Start with existing demo data + add a new company with currency = EUR
2. Activate multi-currencies + set a currency rate (not 1) for Euro to $
3. Open Purchase Report (Purchase > Reporting > Dashboard)
4. Activate demo company + new EUR company
5. Switch between USD and EUR company as selected company

Expected result:
  Dashboard monetary quantities switch between $ and EUR, i.e. both the
  amount changes according to current exchange rate and symbol.

Actual result:
  Currency symbol changes, but amount stays the same.

closes odoo/odoo#75651

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

The end datetime is not timezoned in _adjust_to_calendar before defining the search_range and using the _get_closest_work_time method.
Since _get_closest_work_time will timezone the timestamp received to start searching, the search interval needs to refer to the same end timestamp to avoid erratic behaviors.

Task-2628876

closes odoo/odoo#76374

Related: odoo/enterprise#20783
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Same fixes for the purchase scope

1) Do not overwrite lines description if the line was not modified

2) Correctly recompute prices/sellers on quantity change.

When no new line was added to the PO through the matrix, the
prices/sellers were not recomputed, even if the qty was modified for
some products.

closes odoo/odoo#78902

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

1) Do not overwrite lines description if the line was not modified

Fixes #78833

2) Correctly recompute prices on quantity change.

When no new line was added to the SO through the matrix, the prices were 
not recomputed, even if the qty was modified for some products.

The prices have to be recomputed in this case since pricelist provide 
rules based on minimum qty.

Part-of: odoo/odoo#78902

Most uses (correct ones) of the `partner` context key content expect a `res.partner` recordset as `partner` context value.
This value is extracted during the pricelist price computation (but not used anyway...).

But in one case, fixed by the current commit, a `res.partner` id is placed in the context, as `partner` value.  In some cases, this may trigger "Comparing Apple and Oranges" errors, since `with_context` calls returns a new or existing environment, verifying whether an environment with the same values (user, context, ...) exists.
During this comparison, the new context, with an id (int) as `partner` value, is compared with existing contexts, potentially including some with a recordset on the same key.  Such a comparison fails on the lowest `__eq__` level, raising "Comparing apples with oranges" error.

This commit fixes this case, by making sure the value put in the `partner` context value is always a recordset, and not an id.

closes odoo/odoo#78936

Note: In the future, this context key should be dropped because it's still a bad practice to put recordsets in the context.
Forward-port-of: odoo/odoo#78276
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

WO are released in confirmed state, but the help message says that they are released in draft.

opw-2609040

closes odoo/odoo#78890

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

Steps to reproduce the bug:
- install mrp_workorder
- Create a new work center which will work every day from 8:00-9:00
- Create a BOM with component and operation, which takes 24 minutes in your work center
- Create 4 MO for this bom
- Set manually scheduled date > 1 MO should have a different date than others, e.g:
    - 3 MO → 01/dec/2021 08:00
    - 1 MO → 02/dec/2021 08:00
- Plan the MO which has different date than others

The ```planned_end_date``` is not calculated correctly

Current behavior before PR:
MO_1 : 01/dec/2021 08:00 → 01/dec/2021 08:24
MO_2 : 01/dec/2021 08:24 → 01/dec/2021 08:48
MO_3 : 02/dec/2021 08:00 → 02/dec/2021 08:24
MO_4 : 02/dec/2021 08:24 → 02/dec/2021 08:24

Problem
The MO_4 should only last 20 minutes, while it lasts 23 hours and 48 minutes.

opw-2648065

closes odoo/odoo#78377

Related: odoo/enterprise#21701
Signed-off-by: Rémy Voet <ryv@odoo.com>

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>