For status images

closes odoo/odoo#79268

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

This reverts commit f95356a7.

Revert unwanted r+

Original PR:#78457

closes odoo/odoo#79275

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

Issue :
'Value Price Extra' cannot have the N-digit Decimal Accuracy configuration but 'Product Price' can.
Solve :
Added field_digits to views
opw-2674006

closes odoo/odoo#79014

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

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>

When a submodule overrides an old UNIQUE constraint with a new one,
records in that module may respect the new one and not the old one.
As the old module is updated, it would fail giving an ERROR message,
and therefore blocking the Odoo.sh deployment pipeline.

i.e. website_sale (old): res_users_login_key -> ['login', 'website_id']
             base (new): res_users_login_key -> ['login']

With this patch, the error level is changed from ERROR to WARNING,
leaving Odoo.sh free to continue the build deployment, as the error
was not a blocking one.

closes odoo/odoo#79178

X-original-commit: 8ed3641f
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@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>

- The batch version of get_metadata won't work correctly for the xmlid
returns due to the limit=1 (cause by
718b0f8b ). Fix the
previous issue by reversing the order and without limit.
- The read should be read with the correct user.

closes odoo/odoo#79076

X-original-commit: 29a53f19
Signed-off-by: Rémy Voet <ryv@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>

Issue:
Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user.
However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong.

Fix:
- Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write
- As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs.

closes odoo/odoo#78955

X-original-commit: 0b4efd37
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@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>

A related field copies the attributes from its target field, except for
the attributes defined on the related field itself.  The implementation
of this feature was not working properly for attributes with a truthy
default value.

closes odoo/odoo#78687

Signed-off-by: Raphael Collet (rco) <rco@openerp.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