When there is a materialized view that has not been populated any select
on it will fail.

Example of traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/12.0/odoo/service/server.py", line 1162, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 86, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/12.0/odoo/modules/loading.py", line 367, in load_modules
    registry.setup_models(cr)
  File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 262, in setup_models
    env['ir.model']._add_manual_models()
  File "/home/odoo/src/odoo/12.0/odoo/addons/base/models/ir_model.py", line 321, in _add_manual_models
    cr.execute('SELECT * FROM %s LIMIT 0' % Model._table)
  File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 148, in wrapper
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 225, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.ObjectNotInPrerequisiteState: materialized view "x_bi_sql_view_report_copy" has not been populated
HINT:  Use the REFRESH MATERIALIZED VIEW command.
```

Several upgrade requests have or had had this error which has been
solved with specific scripts.

Related to #40930

closes odoo/odoo#71002

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

with this commit we disables autofill of autocomplete by setting
autocomplete=off, this was previously done in commit: 64293fbd
but it was not working because we were setting autocomplete=none
it seems that none does not work all the time.

task-2462676

closes odoo/odoo#68271

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

Before this commit, link to the API documentation was referenced
to the master version, instead of the current one, 14.0.

Furthermore, the link wasn't adapted correctly following the documentation
reorganisation, which is also fixed by this commit.

closes odoo/odoo#61905

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

data-parent fields were set on tab link and not on the tabpanel
div. It prevented the accordion of having the right behavior:
closing all the other tabs when a tab is clicked to be opened.

closes odoo/odoo#70960

X-original-commit: 32b2c17e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

To reproduce:
1. create and confirm a MO with register number checks on operations
2. duplicate the MO
The register number checks won't show up in the new MO

We didn't set copy=False for workorder_id on stock.move, when copy a
confirmed MO, the new moves are linked to old WOs on old MO. New WO
didn't link to any moves.
When create quality checks, we only create "register ..." checks for WOs
with move_id. As a result, new WOs without move_id won't have those
checks.
To fix, set copy=False on workorder_id of stock.move

Task 2484939

closes odoo/odoo#68348

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

Some message are not translated. Fix them.

closes odoo/odoo#68223

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

website_forum.faq_accordion is not rendered by a drag'n'drop
and data-parent is therefore not set on tabpanels by onBuilt.

closes odoo/odoo#70759

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

This commit update owl to the latest release. It only contains a small
fix on the order of lookup for the t-component directive.

Release on github: https://github.com/odoo/owl/releases/tag/v1.2.5



closes odoo/odoo#70935

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

If you set the type (cost_subtype_id) of a new contract
(fleet.vehicle.log.contract) before setting vehicle_id you got an error:

 name = record.cost_subtype_id.name + ' ' + name

 TypeError: can only concatenate str (not "bool") to str

 because vehicle name was False.

 opw-2527268

closes odoo/odoo#70929

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

When the user removes the readonly from the field date order and tries
to modify it it crashes in some cases, this commit fix this

opw-2523508

closes odoo/odoo#70895

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

On unbuild order creation, when the user selects a manufacturing order,
the UoM of the quantity will be defined with the product's UoM instead
of MO's UoM.

To reproduce the error:
(Use demo data)
1. In Settings > General Settings, enable "Units of Measure"
2. Create two products P_finished and P_compo
    - Both are storable
    - Qty on Hand of P_compo = 12
3. Create a Bill of Material
    - Product: P_finished
    - Component: 1 x P_compo
4. Create a Manufacturing Order MO
    - Product: P_finished
    - Quantity To Produce: 1 Dozen(s)
5. Check Availability, Produce, Mark as Done
6. Create an Unbuild Order:
    - Manufacturing Order: MO

Error: The unit of measure of the quantity is incorrect, this is
Unit(s), it should be Dozen(s)

The method `onchange_mo_id` defines the product, therefore the method
`onchange_product_id` is also called and here is the issue:
`onchange_product_id` will override the UoM using the product's UoM.

OPW-2467017

closes odoo/odoo#70904

X-original-commit: b80321ac
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.

Specifications
==============
This is done with 2 system parameters.

If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.

If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.

Otherwise we do not encapsulate the email (same behavior as before this
commit).

Task 2367946
See odoo/odoo/pull/61853

closes odoo/odoo#70854

X-original-commit: 044532ae
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

Before this commit, evaluating a domain containing a like/ilike
operator with an evaluation context in which the value was false
crashed.

Moreover, those operators were wrong w.r.t. the case sensitivity:
like was case insensitive, whereas ilike was case sensitive, and
both =like and =ilike were case insensitive.

This commit fixes thoses issues.

The first issue was spotted on our prod, as we tried to add an
invisible attrs in a form view, using the ilike operator (it thus
crashed in create mode).

The second issue was spotted while writting the test cases.

To the best of our knowledge, those operators aren't used in attrs
(for now), explaining why those issues haven't been found before.

closes odoo/odoo#70876

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

Before this commit, when the user edits the description of a task with
use_pad=True and then change the project of this task to one with
use_pads=False. The description written in the pad server is not copied
in the description field of the task.

This commit copies the content of the pad for this case when the use_pad
changes to become False and description_pad is set.

Step to reproduce:
-----------------

1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project B"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the "Project A". With this change,
the collaborative pad is disabled for this task since the Project A has
not the pad, and then the description field is empty rather than have
the content that we have just written.

task-2515150

closes #70401

closes odoo/odoo#70901

X-original-commit: 32a8f598
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

Before this commit, in Project App, when the "Collaborative Pads" is
enabled in the Settings of this app, if the user create a task without
project or in a project that has not the pad enabled and he writes a
description for his new task and select (another) project in which the
pads is enabled then the description field in the form view changed to
have the collaborative pad and the problem is the description is not
copied in the pad and seems erase/delete for the user.

This commit checks if the pad_content_field is not empty after
generating the pad url for the new task/record, if it is the case then
we copy the content in the pad and the user can continue his edition
before saving the task/record.

Step to reproduce:
-----------------

1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project A"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the Project B. With this change,
the collaborative pad is actived for this task since the Project B has
the pad, and then the description in the pad is empty rather than have
the content that we have just written.

task-2515150

closes #70401

X-original-commit: d2b55c77

Before 03025520 rounding applied was eg. for these numbers and UP and
DOWN rounding methods to multiple of 10:

```
Numbers | -8 | -2 |  2 |  8 | 12
DOWN    | -2 | -8 | -2 | -8 | -2
UP      |  8 |  2 |  8 |  2 |  8
```

which is correct for positive numbers but UP and DOWN are inversed for
negatives numbers.

After 03025520 this became:

```
Numbers | -8 | -2 |  2 |  8 | 12
DOWN    |  8 |  2 |  8 | -8 | -2
UP      | -2 | -8 | -2 |  2 |  8
```

which is correct for all cases except for positive numbers that are
before HALF of the precision (eg. number 2) for which UP and DOWN are
inversed.

This is happening because 03025520 uses the sign of the rounded value
=> this does not work for 0 so number 2 is broken (and if fixed number
-2 would be broken).

With this commit, the adjustement of sign is done based on original
number, so we get the equivalent of python equivalent methods:

```
Numbers | -8 | -2 |  2 |  8 | 12
DOWN    |  8 |  2 | -2 | -8 | -2
UP      | -2 | -8 |  8 |  2 |  8
```

opw-2451841

closes odoo/odoo#70910

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

This reverts commit d89562e8fe473692296cb209651beb2ce7a715e4.

Since this commit, the taxes mapped by fiscal position wasn't managed by the _fix_tax_included_price_company method anymore.
Otherwise, some customizations exist on this method that are no longer called.
The 2527940 issue is also due to a remaining bug: the total_excluded price should be divided by the quantity but:
- what if the quantity & price_unit are both signed?
- what if the number of digits for price_unit and the currency are different? Should we skip the rounding of taxes?
Since this commit is not perfect and has a lot of dependencies in others modules, we decided to revert it.

Original PR: https://github.com/odoo/odoo/pull/68997
Revert PR: https://github.com/odoo/odoo/pull/70858



closes odoo/odoo#70883

Issue: 2527940
X-original-commit: c9330e4a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

When partner is not selected, Odoo sends name_search request
`[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such
domain mean ( see #70584 ). This commit clarifies what do we expect to get:
we want all records without restrictions on `partner_id` value.

This also fixes performance issue because domain leaf `('partner_id',
'child_of', [False])` is converted to where-clause `<table>.partner_id in <all
or almost all ids>`

---

opw-2524010

closes odoo/odoo#70842

X-original-commit: 39e0f1fb
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

Steps to reproduce the bug:
- Go to Project app
- See the overview of any project
- Select at the top right another company with a different currency. But keep the company assigned to the current project selected

Problem:
The new currency is changed in the project overview, but the values are not converted to this currency.

opw-2479364

closes odoo/odoo#70597

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

Issue

    Use Safari (or equivalent) browser

    - Install e-commerce
    - Go to Website -> Configuration -> Payment Acquirers
    - Activate Ingenico in test mode
        (write aaa in required fields)
    - Go to shop, and add product to card
    - Go to checkout
    - Select Ingenico payment mode
    - Click on Pay button
    - When on the ingenico page, press back

    The page is blocked and the button is disabled.

Cause

    When clicking on Pay button, the page is locked and
    the button is disabled.
    With Chrome, when coming back to previous page,
    this one is regenerated and therefore adapt the button.
    In Safari, it is not the case.

Solution

    On `pageshow` event, if event have `persisted` attribute set to
    to true, meaning using cache, then reload page.

Fixes https://github.com/odoo/odoo/issues/69453



opw-2510281

closes odoo/odoo#70834

X-original-commit: f2eb6d3c
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

Issue

	- Install "Contacts" & 'base_address_extended' modules
	- Go to contacts and create a contact with value:
	  - street name : Chaussee de Namur
	  - House : 40
	- Save and edit again
	- Set country to 'Netherlands' then save.

	Address not splited well (wrong values for street name and house).
	The issue is not present in UI but is in tests.
	(Issue in UI from odoo 14.0+)

Cause

	There is 2 '_split_street_with_params'
	(inverse function that set street fields):
	- partner_autocomplete_address_extended (removed in 14.0)
	- base_address_extended

	The 'spliting' logic is not the same in both function.

	In UI, looks like it does not call '_split_street_with_params'
	from 'base_address_extended' since no super(Partner, self)...

	However in testing, it does call it from module
	'base_address_extended' and therefore trigger the issue.

Solution

	Adapt _split_street_with_params function
	(in 'base_address_extended' module):
	If previous field (from 'street_format') to parse
	in 'street_raw' is 'street_name', then:
	- set `tmp` to: splitted (max 1 split) street_raw
	  with current field seperator
	- set `append_previous, sep, tmp[0]` to:
	  splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
	- add 'append_previous' to 'street_name' value
	- join 'tmp' values and set it to street
	  (should equal to what left from `rpartition(' ')` split
	  + seconf part of first normal split)
	- continue normal parsing flow

opw-2476096

closes odoo/odoo#70783

X-original-commit: d094d264
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

[FIX] *: update documentation links Following the recent reorganisation of the documentation in 12.0+, the majority of the documents have been moved and their old links are no longer valid. Some redirection rules will soon be deployed, but those rules might be dropped in some years and we want the links to still work, which is why we still replace the links to the new ones.

FW-Port of odoo/odoo#70675 (13.0)

closes odoo/odoo#70728

X-original-commit: 85c24961
Related: odoo/enterprise#18283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Original issue:
Create a payment like follow:

Payment type: receive money
Partner type: customer
Destination account: whatever receivable
Amount: define an amount (i.e. 90.00)
On Save, open the draft jounral entry created.
Lower the liquidity or counterpart amount and add a writeoff
Go back to the payment, change the amount and save.
The journal entry writeoff will swap from debit to credit at every
change made to the amount. This occur also when changing currency on the
payment

opw-2475223

Otherwise, this fix is not covering all cases:
inbound with write-off in debit
inbound with write-off in credit
outbound with write-off in debit
outbound with write-off in credit

closes odoo/odoo#70807

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.

To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
    - Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries

Error: In PDF, the first timesheet line has a bottom line and its last
cell has a white background (instead of grey).

The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.

OPW-2478311

closes odoo/odoo#70746

X-original-commit: 88a10bdd
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

We have observed that in some circumstances, there is no field to
reflect on a given model.  Avoid an exception in that case.

closes odoo/odoo#70774

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

uuid should be unique even after copying

closes odoo/odoo#65148

Related: odoo/enterprise#15996
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

These changes have been made to be able to add some behaviors in some specific points of the flow when overridden.

Before this commit:

  When there is too much records to post and it's take time more than 15 minutes then server was restarted.
  So scheduler action will do the process with the same records again and again.

After this commit:

  post record in batch of 1000

opw-2451446

closes odoo/odoo#69738

X-original-commit: b87612d6
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: rrt-odoo <rrt-odoo@users.noreply.github.com>

The method that computs what is due and the change of an order is based
on the selected payment line which is wrong, because if you add and
remove a payment line, none will be seleced, that lead to issue in this
case because a change is computed, and it won't match the invoices
because an amount_return is sent to server.

To reproduce you can follow this simply procedure:
    - set rounding half-up to 0.05
    - create a product at 0.98
    - open POS and create an order with the product
    - go to payment screen
    - add cash payment (1€ auto filled)
    - add bank payment (It'll autofill -0.02 not really a problem)
    - remove the bank payment => It'll show 0.02 due (it is caused because of no payment method is selected)
    - Set a customer and check the invoice => unbalanced (0.02 probably because it is set in amount_return of the request)

closes odoo/odoo#70825

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

[FIX] account: bug fix and rewrite query of function _adapt_parent_account_group and _adapt_parent_account_group

before this commit:

_adapt_parent_account_group or _adapt_parent_account_group call with multi-company record then raise singleton error

after this commit:

singleton error is fixed

closes odoo/odoo#69323

Signed-off-by: William André (wan) <wan@odoo.com>

This bug is cause in this PR https://github.com/odoo/odoo/pull/70312



closes odoo/odoo#70810

X-original-commit: f7f283bc
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used.

Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0.

In community, grids number were missing on the lines' labels, and the codes (used to retrieve the value of each grid when generating the XML) were not correct.

closes odoo/odoo#70754

X-original-commit: 90e21592
Related: odoo/enterprise#18292
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

/shrug

closes odoo/odoo#70753

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

The `search` function of the `re` package can return `None` if the
provided string does not match with the provided pattern
(https://docs.python.org/3/library/re.html#re.Pattern.search

).

On the `_parse_youtube_document` function of the `slide.slide` model,
we are directly accessing the capture groups from the returned value
of the `search` function without checking that the returned value is
actually a 'match' object. As a result, an exception can be throw if
there is no match as, in that case, the `search` function will return
`None` and the `group` function will not be defined on `None`.

To avoid throwing an exception, we will check that the returned value
of the `search` function is not `None` before accessing the capture
groups via the `group` function.

LINKS

Task id: 2525007

closes odoo/odoo#70743

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

In case X several recurrences are processed in the same cron execution,
only the last recurring task was created X times, while the other tasks
were not created. There is also a missing id preventing a correct use of
the default stage for the new created task.

closes odoo/odoo#70633

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Regarding of the `display_default_code` context value, `display_name` is
supposed to return the product code or not, eg:
> product.display_name
> '[FURN_6666] Acoustic Bloc Screens'
> product.with_context(display_default_code=False).display_name
> 'Acoustic Bloc Screens'

But since the context was not considered when accessing this field, it would
always return the cached value, which was set from the first time that field
was read, with the `display_default_code` value used at that time.

tl;dr: `display_name` was ignoring the context once cached.

One of the critical issue was that internal code were displayed on the eshop
cart (not the eshop itself), see `name_short`.

task-2517830

closes odoo/odoo#70727

X-original-commit: b5b4d38a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Before this commit, some requests could be sent to the actual IAP
servers during testing. These calls weren't always mocked as many
of these requests are sent in background while performing usual
tasks such as creating a bill.

Now, any call to the function iap_jsonrpc during testing will result
in an AccessError.

closes odoo/odoo#63096

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

closes odoo/odoo#70687

X-original-commit: cf975e44
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.

Now, the content of the binary is cropped to
20 chars as it is useless to log more.

opw-2527629

closes odoo/odoo#70699

X-original-commit: d54b30bb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>