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>

On product categories, the `total_route_ids` field is shown without
label. This is confusing for end users since the same route seems to
appear twice.

opw-2173783

closes odoo/odoo#44799

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

1) Go to purchasing, and in the search area type "8888"
2) Click on the little arrow next to "Search Product for: 8888"
3) Select "[FURN_8888] Office Lamp"
4) Choose Purchase Order PO00009 which has FURN_8888 on the second line:
5) Choose Action > Duplicate

The 1st line end up with the searched product, not the original product.
This happens because the search add the context key
'default_product_id'. By chance the product.product model has a
'product_id' field which may happen to be not filled.
This cause the model api to look for a default value in the context and the
first line of the order get overridden.

Removing the specific key from the env solve the issue

opw-2188429

closes odoo/odoo#44760

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

closes odoo/odoo#44548

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

Usecase to reproduce:
- Set the lot_stock_id as a view location
- Create a PO and validate it

-> The forecast quantity on stat button is correct but it's missing in
the forecast quantity report.

It happens because the condition for stock_move is based on valuation
strategy. However it's not correct since it's not True that a product
is in the stock if it's valuated (as subcontracting, owner, ...)

In order to fix it uses the warehouse in order to define if a move is in
or out (the same way than the _get_domain_locations on product).

- Create a default value for 'Source Location' or 'Scrap Location'
- Create a Scrap Order

the default value is not taken into account since it is overridden by
`_onchange_company_id`.

We avoid changing the location in case the company matches.

opw-2189578

closes odoo/odoo#44753

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

- Create the following tax:
  Tax Computation: Percentage of Price Tax Included
  Amount: 100 %
  Included in price
- Create an invoice, add a product with this tax
- Save

A ZeroDivision error is raised.

opw-2186998

closes odoo/odoo#44724

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

closes odoo/odoo#44668

Co-authored-with: Xavier Dollé <xdo@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Have a company with Croatian address but no street2 set.
Create and invoice, print it. On the report the street2 will appear
blank (Empty line).

Correcting the formatting of the address fix the issue

opw-2182621

closes odoo/odoo#44706

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

Nothing prevents to delete a bank statement linked to an open pos session,
which leads to a KeyError when validating and posting entries at closure.

closes odoo/odoo#44229

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

Steps to reproduce the bug:

- Create a journal entry
- Create a line L1 with an account A and a partner P
- Create a second line L2 with an account A and a partner P
- Create a third line by clicking on 'Add line'

Bug:

The account A and partner P was not suggested as in saas-12.3

opw:2188921,2152827

closes odoo/odoo#44656

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

Before this commit, it was possible to change the state of the Purchase Agreement when Grouped by `state` on Kanban view which is not Ideal Behavior.

Now we block drag and drop when grouping by State.

closes odoo/odoo#44674

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Steps to reproduce the bug:

- Let's consider a partner P without property_payment_term_id
- Create a SO for P, confirm it and create an invoice I
- In debug mode, on the SO click on the smart button 'invoice'
- On I, click on the 'Set Default' in the debug menu
- Set a payment term PT as default value (ir.default) for all users
- From this view, create a new invoice

Bug:

The default payment term PT was not set on the new invoice

opw:2184367

closes odoo/odoo#44648

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

Since synchronization of tables was added in POS restaurant,
requests are frequently made to the server to display the
number of open orders on each table.

The implementation of the counting caused O(num_tables) queries,
and those queries were slow on large databases because there
was no index for the `table_id` column.

This patch fixes both problems, and the counting now uses
3 fast queries regardless of the number of tables.

On a sample database with 2k tables and 50k POS orders,
calls to `get_tables_order_count` went down
from 1 s and 100+ SQL queries to 10 ms and 4 queries.

About 2 orders of magnitude faster, with server load drastically
reduced as well.

closes odoo/odoo#44660

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

Steps to reproduce:
- install sales
- activate units of measures and variants
- set imperial units under general settings (pounds for weight and ft³ for volume)
- create at least 2 variants on a product and access them via the smart button
from product.template

Previous behavior:
the volume remains in m³, it is hardcoded in the template

Current behavior:
the volume is printed just like the weight (generic uom notation)

opw-2186965

closes odoo/odoo#44649

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

Before this commit, when printing in safari a receipt that contains
products with long names, parts of the name were overlapped. This occurs
because, in safari, the library that transforms the html into text
mismanages the spaces.
This is a well known problem, see : niklasvh/html2canvas#1654

Now, the name is printed correctly in safari, same behaviour than the
others browsers.

opw-2169656

closes odoo/odoo#44658

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

Highlight the 'Validate Inventory' button only if there is at least one
inventory line.

opw-2187225

closes odoo/odoo#44628

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

Don't ignore correction layers when computing the anglo saxon price
unit. We use the `stock_valuation_layer_id` field on the layer to point
the correction layer to the corrected layer. When computing the average
price of the delivered things, ignore correction entry but take them
into account when choosing a corrected entry.

opw-2179900

closes odoo/odoo#44498

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

We chose the vendors by searching random res.partner but sometimes
partners of another company are returned, making the _check_company
mechanism raise an error.

closes odoo/odoo#44367

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

in anglo saxon accounting
- receipt products through an rfq
- when creating the vendor bill of the rfq, directly add a landed costs
  product
- post the vendor bill then create the landed cost, validate the landed
  cost
- the aml of the LC is not reconciled with the aml of the vendor bill
  for the lc product because the "You are trying to reconcile some
  entries that are already reconciled." error.

We fix this by filtering out the already reconciled aml.
Not that the flow is behaving as expected if the landed cost is created
in another vendor bill, such as the tests were doing. We thus add
another test.

opw-2184988

If some filter domains use M2O to models current user cannot access,
using sudo() permit to filter even when user cannot access linked
models.

for the accuracy of the fix, add a unit test which reproduce the exact
reported bug.

closes odoo/odoo#43582

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

    When you have su == True in your env and you call _name_search
    the _name_search was switching back to su = False
    when you call with_user with the same user or with None

    To reproduce the issue, take a model where a user has
    no access.control.list allowing to read the model
    call name_search with sudo.

Because the tax closing entry is created (empty) at the creation of the
CoA, it is not possible anymore to change it later, even if the user
didn't create any journal entry.
By checking that there are no account.move.line instead of account.move,
and also there are no entries with a name different from '/' (to ensure
that the sequences are untouched) we can change the CoA if needed.

closes odoo/odoo#44647

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

Since commit 92737f21 (finetuning of 7b49f583) field website_id, website_tag_ids
are missing from form view of res partner.

Now we use a more precise xpath, hardcoding the group name into the xpath to
be sure that fields are correctly added below the company_id field from a
visible tab.

closes odoo/odoo#44120

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

Steps to reproduce the bug:

- Give 'Administrator' rights for the Sales app and no rights for the Point of Sales app to the demo user
- Try to access CRM > Sales > Team Pipelines as Marc Demo

Bug:

Access Rights error on pos.session

opw:2184032

closes odoo/odoo#44618

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

pass move type to journal for filtration but it is removed by this commit https://github.com/odoo/odoo/commit/a9b762870651e607b244d8fd5681a9f3557cc0e9#diff-59b30a3c3997659843dcc916225f508a

 so no more in use

closes odoo/odoo#44538

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

- Create a partner which is a company
- Add a contact
- Create an invoice for the contact, post it

Both the contact and the company are set as followers of the invoice.

Only the contact should be, there is no reason to make the company
follower too.

opw-2179084

closes odoo/odoo#44474

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

Simple `this` instead of `self` mistake which prevents the widgets to
trigger up events.

closes odoo/odoo#44609

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

* Inherit the new _prepare_default_reversal method to be able to set the document type and number in the reverse move from the values we have in the account.move.reversal wizard.
* Document type not set in credit note wizard: Set the move_id field in defaults and add it to the view. with this change the document types are properly computed.
* Make document number required in refund wizard.
* Document type field can be copy: This way when using the refund wizard for the 3rd option will create the new one with the same document type of the original one.

closes odoo/odoo#43514

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

to change the values to use when creating the oreverse move via inherits
of the new method.

When an order is synchronized to the server, there is a timeout of 7.5
seconds that is left before considering that the order has not been
synchronized, and should be re-syncronised.

Since syncronization of order in pos_restaurant have been made, there
are more operations than before that are performed, and the
synchronization of an order can take more than that.

The validation of a picking can also take a lot of time, almost when
products are kits and compose of multiple products.

The problem, is that if it takes more than 7.5, the same order will be
pushed again to the server, even if the previous sychro still running,
which will lead to wait the previous request that has the lok on the
same records, all this blocked request can lead to block all workers of
the server because all requests are trying to modify same objects.

So we've increased the timout for flushed orders.

closes odoo/odoo#44600

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

Since you can only reconcile entries from the same partner, you must always use
the commercial partner when creating some journal items.

closes odoo/odoo#44555

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

With the commit some time ago #d3822883, I removed to take the first,
but you can have multiple transfer accounts in one company.

The best way is to just do a limit=1

closes odoo/odoo#44592

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

Purpose
=======

Before this commit, the method _mail_find_partner_from_emails could
return a list mixing partner ids and partner recordset, that could
lead to issue when trying to read the different elements.

With this commit, we ensure that we return a list of records only.

closes odoo/odoo#44588

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

Before this commit, Creating New Template from "Send Invoice" wizard doesn't update template_id on the Wizard.

In this commit, We write newly created template_id on the wizard.

closes odoo/odoo#44553

X-original-commit: 454e6ed9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

[FIX] mail: fix issue when posting a message on a document whose first message / parent is not readable

How to reproduce
================

Have a portal user commenting a task on the customer portal. He may experience
a crash if previous message / first message is not available, for example
if it is internal or not published.

This is due to reference computation used in outgoing emails as it is based
on parent messageID. Accessing it crashes although it should not as it is
used only for technical purpose.

Fix
===

In this comme we fix that issue by browsing the reference message as sudo
to access its messageID. A test is added to avoid regressions.

Task ID 2061760
PR #36845

closes odoo/odoo#43332

X-original-commit: 2b3d9241c982f6fd0bbfb9f475f75b44a96f27d4
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>

Since this option is soon to be used, this rename is a last tweek
to make it more logical to use since it will point to a single
upgrade dir most of the time.

closes odoo/odoo#44558

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