This is a followup of 1d553eea.

Systematically logging import tracebacks can fill up log files, and
waste disk space.  We therefore log those tracebacks in DEBUG mode, so
that they can be activated only when needed.

closes odoo/odoo#45049

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

Assume a situation where you trigger a method which is going to create a
nested picking with move_lines included and having a filter set which
means that your context includes {'default_product_id': 20}

{
 'location_dest_id': 9,
 'location_id': 19,
 'move_lines': [(0,
                 0,
                 {'location_dest_id': 1,
                  'location_id': 2,
                  'name': u'name',
                  'partner_id': 1,
                  'product_id': 10,
                  'product_uom': 1,
                  'product_uom_qty': 1.0})],
 'origin': u'Origin',
 'partner_id': 1,
 'picking_type_id': 59
}

Before the creation of the objects it will inject the default product in
the top level of the dict which should create a picking with one or more
move_lines.

Based on this this injection will overwrite all product_id values of the
created move lines as the picking is created last and the default value
will write ALL move lines with this specific product from the context.

closes odoo/odoo#44989

X-original-commit: 05e957f0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Issue

	- Deactivate demo data
	- Install several modules (e.g. Sales, Helpdesk)
	- Go on Home
	- Hard refresh

	All tours' tips are shown

Cause

	In 02dab5dc, we wait the DOM to be ready.
	The DOM wasn't ready in previous version, this is
	why it seems to work.

	As the DOM is ready, in check_for_tooltip we
	have a visible trigger so trigerred = true
	and the tip is activated.

	If you activate the debug mode, the DOM is
	not ready too, this is why it works fine
	in debug mode.

Solution

	I don't think that not waiting the DOM to be
	ready is good so I think we should keep that
	and handle the case when we update the tours
	from the _register method. So that, we use
	the else part of the update method which
	will break after a tip has been activated.

OPW-2188525

closes odoo/odoo#44630

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

[FIRST ISSUE]

Steps to reproduce the bug:

- Create a pricelist PL with 50% reduction on all products.
- Create a SO with PL
- Add an optional product P

Bug:

 The price is correct for P  but the discount displayed was 0%.

[SECOND ISSUE]

Steps to reproduce the bug:

- Add the option line to the order

Bug:

A new line was create for P in the SO with the correct price but the discount was not displayed

PS: The discount field on the model sale.order.option has been implemented to add a new discount
to the displayed price unit of the option. But it has not been implemented to show the discount computed with
the pricelist.

opw:2186470

closes odoo/odoo#44976

X-original-commit: 21400337
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

The translation alert dialog was attached to the entire view in case no
status bar was found. This resulted in the following layout on large
screens:

    chrome
    --------------------------------------
    | alert dialog | form view | chatter |
    |              |           |         |
    --------------------------------------

Whereas when a status bar was set on the form view, the rendering was as
follow:

    chrome
    --------------------------------------
    |        status bar        | chatter |
    |       alert dialog       |         |
    |        form view         |         |
    --------------------------------------

The fix make sure the alert dialog is always placed just above the form
view just like when there is a status bar.

closes odoo/odoo#44860

Task: 2075172
X-original-commit: dacdc30681510e9c2db23610c5be5285a72a8949
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

- Activate variants and pricelists
- Go to Product > Products Variants
- Search for anything on the 'Pricelist' filter

A traceback is raised: 'Can only create cache keys from hashable
values...'.

This comes from the following change:

https://github.com/odoo/odoo/blob/4b06fe19fa68255b7982d15e5847da2f6d6209fd/addons/web/static/src/js/views/control_panel/control_panel_model.js#L962



It returns a list instead of a string. Since a list is not hashable, it
causes the issue.

There are not much solutions since the context key `pricelist` can be a
`list` or an `int` (an ID). We force the cache key conversion to a tuple
to avoid the `TypeError` and handle the `list` use case (which was
broken on top of crashing).

opw-2187757

closes odoo/odoo#44775

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Go to Accounting / Reporting / Management / Invoices
Select Pivot view
Add "Total" measure
expand results adding "invoice #" and product

Total will be incorrect because it is summing up the value reported from
several lines of the query in which the total is taken as the invoice
total, so it will display total * # lines.

Using the price retrieved from the single lines fix the issue, but it
needs to be converted according to the currency rate of the invoice.

Moreover the test need to be modified because the amount_total variable
of the report should NOT be the move amount_total but the amount from
all the lines converted in company currency

opw-2187369

closes odoo/odoo#44654

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

In a database with many users / events to synchronize, the cron
`ir_cron_sync_all_cals` may time out. Consequently, even if a `commit`
is performed for each user, some users are never synchronized.

In this commit, we first sort the users by last synchronization date,
meaning that all users will ultimately be synchronized, even if the cron
times out. On top of that, we introduce the context key
`last_sync_hours` to prevent the synchronization in case the cron is
restarted after timeout.

opw-2158372

closes odoo/odoo#45026

X-original-commit: 2f21def6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>

When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order
as many email notifications will be created as there are users linked to the same res.partner.
This won't send more than 1 email, but multiple mail.notification
records will be created.
This causes duplicate entries in the mail.notification table, and can
crash when an old unique constraint is still present in that table (from
earlier Odoo versions)

To prevent this, we deduplicate the notifications and order by notification
type to get 'email' first in case the user have different notification
type ('email', 'inbox').

How to reproduce:
   - Create a first user test1
   - Create a second user test2
   - Merge the contact test1 and test2
   - Create a customer customer
   - Set the user test1 as salesman
   - Create a new sale.order with customer as partner

Add a test to reproduce the pathological scenario

Solution
  add distinct on partner.id and order by partner.id,
users.notification_type

closes odoo/odoo#43862

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

When reading binary content such as `image_128` on `res.users`,
`AccessError` should be raised when necessary.

Steps to reproduce:
  - Populate cache in superuser mode.
  - Access cached field with public user.
  - Read access is allowed but should not.

Concrete example:
  - Unpublish `demo` user.
  - Access `/slides` with `public` user.
  - The template data is generated as `sudo`.
  - The same data is then accessed as `public`.
  - AccessError should be raised when requesting
    `/profile/avatar/<int:user_id>` but is not.

Closes #43826

Signed-off-by: Christophe Simonis <chs@odoo.com>

closes odoo/odoo#44969

X-original-commit: eeb66d101ff212dbe0d51952aa7ebcd38546b461
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

When adding a custom field, the ORM also adds it to all the inherits'ed
models, but with the state `base`, because those inherited fields are
automatic (created by the ORM).  However, dependencies are enforced for
`base` fields, while they can be ignored for `manual` ones.  This is a
problem when a custom field is fucked up: its inherited fields will make
the registry crash.

We fix the issue by not enforcing dependency check on fields inherits'ed
from custom fields.

opw-2191114

closes odoo/odoo#44966

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

If the account.move already has a `l10n_latam_document_number` set on it, the post() method should not try to consume a sequence again by any means. The validation filtering is also done with `l10n_latam_document_number` as this is the field which give the `account.move.name` the desired value; this makes a stronger validation while making it more flexible for other localizations which do not depend on the `account.move.name` to post an invoice.

On vendor invoices it allows to manually assign a `l10n_latam_document_number` and posting it without needing an ir.sequence assigned to the specific consuming a sequence from ir.sequence (and it does not even need to have one) as the value is already in the account.move.

**Context**: Not all latam localizations use the `l10n_latam_document_number` as the move `name`. This is basically for auditing purposes, as some countries (like Dominican Republic, Honduras, etc) do not always have **continuity** in their sequences, requiring to keep Odoo's base behavior on the move.name

closes odoo/odoo#43850

Signed-off-by: Josse Colpaert <jco@openerp.com>

The user is never able to delete a website, since there is at least one page,
the homepage, which is bootstraped during website creation.
From that point, even if nothing was done on that website, it was not possible
to remove it.
As website deletion is already a technical thing (debug mode), and since
website.page do not make sense without their website, removing those on cascade
will allow the user to remove a non-modified website.

task-2092845

closes odoo/odoo#44957

Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

As an admin or website publisher, you have the possibility to switch website in
the navbar. This will force a website in your session*.

If this website is removed at some point, your session will be broken as the
dispatch will lead to a traceback, trying to read un unexisting website.

* There is other way to have the website forced in the session: theme install,
  go to website from settings, create website from settings..

opw-2092845

When you read a record with the document viewer on the right side
that you don't have write access to this record
and the message_main_attachment_id was not yet set on the record

the document viewer try to set a value for message_main_attachment_id
that raise an access error

Set the value is not important but the popup
Access error can be really annoying

closes odoo/odoo#44722

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

Steps to reproduce:

- have Odoo with Dutch language and install Belgian accounting
- print "Periodieke BTW aangiften" report
- the report is wrongly translated

see this document for reference:
https://financien.belgium.be/sites/default/files/downloads/165-625-richtlijnen-2016.pdf%22

related pr: https://github.com/odoo/enterprise/pull/8233


opw-2176688

closes odoo/odoo#44971

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Issue

	- Install Blog
	- Go on a Blog post
	- Customize > Enable Share links & Sidebar
	- Click on a social share link

	Redirected to #

Cause

	The website_blog.js has been refactored fron v12
	to v13, it seems that the onShareLink method has
	been forgotten in the event handlers.

Solution

	I added it and make it working with the actual view.

OPW-2170706

closes odoo/odoo#44583

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

When grouping records in kanban view, if a quick create widget was
already opened, clicking on the "+" to launch another quick creation
would crash.

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



closes odoo/odoo#44935

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

Followup on 5ce8f1e3
Before this commit, There would be traceback on Launching Plan with `Responsible` set to `other` and No `Responsible Person` defined on activity due to Extra argument.

In this commit, We remove that extra Argument.

closes odoo/odoo#44922

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

[FIX] l10n_eu_service: wizard: don't copy tags when creating the service tax for the selected EU country

This restores the behavior for 12.0; we don't want those amount within the national tax report.

closes odoo/odoo#44881

X-original-commit: bd21046f9259f0c755deeba8a1d207da6578e957
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

This route was public by mistake, probably introduced to test during
ddf32f4f but no reason to make it public, public user has not the write
access on models anyway.

Courtesy of Swapnesh Shah

closes odoo/odoo#44912

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

- Go to Settings > Technical > Resource > Working Times
- Have a Resource Calendar RC with Average hour per day != 8.00
- Have an Employee E with Working Hours == RC
- Leaves > Configuration > Leave Types
- Have a Leave Type LT with Take Leaves in Hours
- Leaves > Managers > All > Allocations
- Create an Allocation A with Employee E and Leave Type LT
- Enter any number in Duration

The number of hours entered changes as we leave the field.

Being totally honest, what happens here is not clear at all, but using
the corresponding `resource_id.calendar_id` field seems to fix the
problem.

opw-2191795

closes odoo/odoo#44895

X-original-commit: e239b354
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before, we had abs() in the report, but we saw it was wrong:
https://github.com/odoo/enterprise/commit/5e7d91d5ea5356fa3c38b6676b68403a713da5be#commitcomment-33050133



Somehow they remained in saas-12.3 and with this we remove them as well.

Thanks to Martijn Kluijtmans
opw-2186942

closes odoo/odoo#44653

X-original-commit: e39d86a85015d833dcf0b87c3d28f7bc3b97a2c1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Without these magic filters the various options in the activity
widget (late, today, future) will show all activities instead.

opw-2172833

closes odoo/odoo#44817

X-original-commit: 8ddb78c05a97282096bed9f49de0cea8f265994c
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>

Since we use Promise instead of jQuery deferred, the onRemove method
class was no longer triggered before the actual removal of the elements.

Original fix with https://github.com/odoo/odoo/pull/43918


This PR is the same with the async/await form, not breaking the history
of half of the removeSnippet method's lines.

closes odoo/odoo#44900

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: fja-odoo <fja@odoo.com>

Make sure `force_company` context key is set on the SO in all cases.
Indeed, when the context key is not properly set, an incorrect fiscal
position can be retrieved in:

https://github.com/odoo/odoo/blob/cc557f1e4de88466d0d159c5edf1a606a0c0bc6f/addons/account/models/partner.py#L99-L100



This is for example the case when we go through the route
`/shop/confirm_order`.

opw-2186682

closes odoo/odoo#44451

closes odoo/odoo#44882

Original-signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
X-original-commit: 510bb8cc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

closes odoo/odoo#44875

Signed-off-by: Josse Colpaert <jco@openerp.com>

The typical command to launch odoo in the install documentation is usable as it is after following the complete instructions.
There is two changes done here:
- Remove the ../my_modules from the command, as it is a directory not used in the page at all.
- Remove the db-filter option not mandatory since the 11.0 version and add a '-d' argument. This will create the db instead of showing the database selector to the reader.

closes odoo/odoo#44640

X-original-commit: 5489cc12
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

The filter for Purchase orders in the Purchase report did not filter out Sent RFQ,
despite the fact that they were not really ordered yet.

opw:2158248

closes odoo/odoo#43620

X-original-commit: f112d91dd176865f33fb17f56f1ea2e119708e1b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Issue

	- Install Website
	- Go on your website
	- Add text block with image
	- Change ONLY the image's alt and/or the image's title text
	- Save dialog
	- Save page

	Not saved

Cause

	The element doesn't become dirty after changes in alt dialog.

Solution

	Trigger content_changed to make the element become dirty.

OPW-2189909

closes odoo/odoo#44853

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

closes odoo/odoo#44239

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

Make sure `is_website` is an existing field of the model at creation.

opw-2192139

closes odoo/odoo#44841

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

closes odoo/odoo#44838

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

Formerly the vendor bills, customer invoices and regular journal items were evaluated by the _check_unique_sequence_number method, but this is wrong and also was overwritten Odoo original constraint error message.

Now the _check_unique_sequence_number evaluate the account.moves that are not vendor bills that use documents because this kind of bills uniqueness depend on the vendor: we can have same name of vendor bill from different partners. This is evaluate in the already existing _check_unique_vendor_number method

closes odoo/odoo#44813

Signed-off-by: Josse Colpaert <jco@openerp.com>

Normally, the number of column option adjusts the width of each column
after changing their number so that they always fit in one row. In
previous versions, the sequence of the code was correct thanks to
jQuery's deferreds executing their then callbacks synchronously if the
promise was already resolved. However, native Promise objects always
put their then callbacks in the microtask queue, and this was resulting
in the column width classes being recalculated before their number had
actually changed.

This commit fixes that by calculating the width of the columns based on
how many columns there will be after addition/removal. It also
introduces a new field on the option that is used to update the UI so
that it displays the correct number.

closes odoo/odoo#44776

X-original-commit: 1745281a1956caf669eb27191b356726c9e65253
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

- install e-commerce;
- In the website settings, orders followup, set a salesperson;
- By something as a public user;
- Pay the order.

Before this commit:
- 2 emails where create to assign the salesperson to the SO, but these
    emails didn't have a from and the salesperson didn't receive the
    emails.
- 1 email was also create to assign the salesperson to the contact, this
    mail is not necessary.

Now, only one email that assigns the salesperson to the SO is sent,
with a correct from address.

opw-2189683

closes odoo/odoo#44717

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

- Activate 'Round Globally'
- Create a 21 % tax included in price
- Create a product costing 21.5
- Add the product in a pos order, make the payment

The `price_subtotal` is saved as `17.768595`, while it should be
`17.77`.

When these amounts are added in [1] (coming from [2]), it can lead to an
inconsistency in the final computation, preventing the closing because
of an unbalanced journal entry.

Actually, the total and the subtotal must always be rounded following
the currency precision, as done in [3] and [4].

It was probably not causing an issue before 13.0 since the creation of
the journal entry from the POS was different.

[1] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/point_of_sale/models/pos_session.py#L381
[2] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/point_of_sale/models/pos_session.py#L557
[3] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/account/models/account.py#L1654
[4] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/account/models/account.py#L1740



opw-2181486

closes odoo/odoo#44692

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>