When a pos order is created and should be invoiced, the argument
to_invoiced is sent when the order is finalized. But if you were offline
during this sale, when you are back online, the 'to_invoice' is lost,
because the value stored on the order is not sent to the server.

So we are now sending the value from the order.

closes odoo/odoo#39937

X-original-commit: c3e77812
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

From Sale create a new (or edit) SO. Add a note to the order with a log
line without dash or whitespace (i.e. a url). Click on "Preview".

The sale portal will try to display the long line which will overflow
the standard size of the column creating an ugly overflow with a very
long horizontal scrollbar.

Adding a "break-all" rule to fix the sale portal case.

opw-2088589

closes odoo/odoo#39878

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

In editable list view, moving to next cell using TAB key crash when the
following field is read-only (i.e non-focusable) and an onchange() event
is triggered.

Consider an editable tree view like this:

<form>
   <field name="o2m" onchange="1">
       <tree>
          <field name="description"/>
          <field name="date" readonly="1"/>
          <field name="type"/>
       </tree>
   </field>
</form>

1. Adding a new line will give focus to `description` field widget
   (currentFieldIndex is 0)

2. issuing a TAB keypress, will call _onNavigationMove which calls
   _selectCell() with fieldIndex of 1

3. The _selectCell() method set widget currentFieldIndex to the new value
   (currentFieldIndex is 1) add call _activateFieldWidget() to activate
   on the corresponding widget.

4. _activateFieldWidget() will fail to activate the `date` field as it's
   readonly, then try for next ones and succeed to activate the `type` field
   cell

5. When focus is given a `type`, the `description` field is blurred which
   trigger an onchange() and the controller apply those changes to the
   editable list rendererd using the confirmUpdate() method.

   The confirmUpdate() will try to get the current selection, but that
   field is actually set to the `date` field (currentFieldIndex = 1),
   which is readonly and so has no focusedElement - triggering the crash.

This commit ensure we don't try to call getSelectionRange() it current widget
has no focusable element.

OPW-2075229

closes odoo/odoo#39913

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

Reproduce the issue:
 - In the CRM app, create a lead/opportunity.
 - Schedule a meeting for this opportunity via
   the chatter and click on create.
 - Go back, the "Meeting" stat button is now at 1
 - Schedule a meeting for this opportunity via
   the chatter and click on edit then create.
 - Go back, the "Meeting" stat button is still at 1

Cause:
When we click directly on create, the opportunity ID is in the defaults
option but when we click on edit, there is no opportunity ID.

So, this commit use the context to retrieve the concerned opportunity
and set it if it is not already set.

I splitted the solution into a private method for a better readability.

OPW-2092920

closes odoo/odoo#39853

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

In the Time Off/Leaves app, there are leaves types.
Go on the list view, there is the handle widget on each line.

We don't want this widget because it is misleading. The leaves types
have a specific order algorithm and cannot be reordered.

Fine tuning of 160a08c2

OPW-2089593

closes odoo/odoo#39865

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

The list comes from the selection values on the field license of
ir.module.module

closes odoo/odoo#39897

X-original-commit: 23f89363
Signed-off-by: Nathan Perry <servel333@users.noreply.github.com>

- Create a child company B in parent company A
- Go to company A
- Create an invoice, create a payment (less than the invoice)
- Open the payment matching widget
- Associate the invoice and the payment, add a line for the open balance

It is possible to choose accounts from company B.

This is due to an incorrect forward-port of commit fb48e497.
It was valid in v11 but needed to be changed in v12.

Fixes #39533
opw-2116411

closes odoo/odoo#39847

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

Before this commit, when an event have multiples notifications, if the
first notification is not ack when the second notification is shown, not
only two are visualized but multiples notifications are raised.

Now, only the correct number of notifications are shown.

opw-2070852

closes odoo/odoo#39807

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>

Fixes #39688

closes odoo/odoo#39721

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

Reproduce this bug:
 - Create 2 companies: Indian and Belgian for example
 - Install accounting & l10n_in
 - Create an invoice & print it

The `<td>` dedicated to the HSN is always present so there is a
cosmetic issue for the not indian companies: the table is a *little*
bit too large. This issue is caused by a missing conditional statement
on the `<td>` who is present on the HSN `<th>`.

OPW-2090663

closes odoo/odoo#39815

Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>

Backport of a68f7e6e

Commit 5a9e1af6 has the unfortunate side-effect of crashing early
if for any reason the content cannot be decoded.
However, simply ignoring that the content cannot be decoded is no better idea:
some functions pipe the result to decoding functions that crash the same.
The resulting traceback pollutes the log with uninformative message such as:
binascii.Error: Incorrect padding 5 0.002 0.016

In case the content cannot be decoded (data corruption, or simply missing file)
we return a clean 404 instead, which is morally almost equivalent,
and is clean even from functions that depend on binary_content.

opw 2117114

closes odoo/odoo#39806

X-original-commit: e923a965
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

Go on the accounting module, you'll find a kanban view with a few
cards including "Bank" and "Cash". Click on the Cash card.

The default import button doesn't appears because it is hidden.
The reason of this hiding is that the bank statements of type "Bank"
have a custom import method and the users where confuse. They
didn't know which is the right button for the special import so
we hid the default import button for the whole model.

But there is also a "Cash" type bank statement who doesn't have that
special import and his default import button is hidden too.

This commit checks the type of the bank statement and hide the default
import button only if the type is not "Cash".

OPW-2090477

closes odoo/odoo#39787

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

* the employees file apparently never worked as the marital status was
  updated before template files were added (respectively
  0eb58775 and
  b60de0db)
* the purchase template was never updated to reflect the Big Demo Data Changes
  (58fc4e44).

Fixes #39074

Employees file update split off of task 2059779.

closes odoo/odoo#39800

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>

- Create a project
- Create 3 tasks in the project (top, middle, bottom)
- Set top as the parent of middle
- Set middle as the parent of bottom

We don't want to allow multi level subtasks. The behavior is not the
same if you set middle as the parent of bottom first. The "parent task"
field will not be displayed.

This commit remove the tasks who have a parent from the m2o field.

OPW-2087921

closes odoo/odoo#39718

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

- Create an event
- Add a mail reminder for it
- Run the mail scheduler manually
- Duplicate the event

The mail reminder is sent on the duplicate too.
This commit remove the field `mail_sent` from duplicating.

OPW-2117343

closes odoo/odoo#39765

X-original-commit: 7fede2c0
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>

The test suite is an HttpCase so it must be started post install, as it
is started post install and `payment_stripe_sca` is automatically
installed. The test 30 is incorrect.

closes odoo/odoo#39740

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Followup for d22866f8
Without this fix the rendering associated with this view would crash
because after the replace the field became a string and it crash when
retrieving it with t-field

closes odoo/odoo#39732

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

odoo/odoo#30688 (6ce2d6ef) added an
indirection in prefork workers: Python-level signal handlers are
delayed until native calls have ended (e.g. accept() or
execute()). Running the actual work in a sub-thread allowed the main
thread to handle signals in all cases.

However there is apparently an issue with SIGXCPU on linux (possibly
other cases as well): SIGXCPU is delivered to the child thread (if
possible?) and Thread.join apparently stops it from redelivered to
the main thread (Thread.join is signal-interruptible since 3.2 but
possibly not Python-interruptible).

Blocking SIGXCPU on the child thread causes the OS to deliver on the
main thread and fixes the issue.

Also split set_limits so it sets the signal handler in the parent
thread but properly updates the soft limit in the child after each
request, as the goal is to put a hard limit on the CPU time per
request, not on the worker. 6ce2d6ef would set the limit once then
never update it, likely cycling workers more than desired.

While at it:

* block other signals with a handler set, they seem to work
  regardless on linux but other OS may have a different way of
  dispatching process-directed signals
* unset signals which are set by the prefork server but whose
  set behavior makes no sense in workers:

  - TERM and CHLD were already unset
  - HUP is used to restart the server, workers can just be killed
  - TTIN and TTOU configure the number of workers

closes odoo/odoo#39712

X-original-commit: 549bd199
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

The title says it all -_-

closes odoo/odoo#39699

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Install purchase, configure in company settings a Tax (i.e. BE 231312).
In "General Settings > Business Documents > Fomat" select A4.
Open a purchase, print the report.

The "TAX ID" string in the footer will be split into two lines, while it
should be consistent with the rest of the footer (inline items).

Adding a nbsp (xml version) entity fix the issue

opw-2089238

closes odoo/odoo#39704

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

After of this commit 12a2bd67, returns a
traceback when overwrite the translations (Spanish by example)

The error is
ERROR: ON CONFLICT DO UPDATE command cannot affect row a
second time
HINT:  Ensure that no rows proposed for insertion within the same
command have duplicate constrained values.

And is returned because the field field_mrp_routing__location_id now
have 2 translations

closes odoo/odoo#39680

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

By default, the name of a file input field is 'Custom File Upload'.
If there are two fields with the same name, then they both end up in
self.form_fields with the name 'Custom File Upload[0]', and their values
are concatenated, which are file objects. So the concatenation of two
files is a String, ('[object File],[object File]'), because JavaScript.
(And if you don't like it you don't like the web nor human progress.)

The resulting bug is that instead of adding attachments to the created
record, it adds the string message to the notes.

Adding the outer loop index disambiguates the names, so that all
attachments are created as intended.

opw 2092653

closes odoo/odoo#39655

X-original-commit: 5df3f662
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

On the 'Vendors > Refund' view, the fields 'Tax Excluded' and 'Tax' are
positive, while the 'Total' is negative.

We apply the same loginc than d7c0c5c1.

opw-2115019

closes odoo/odoo#39652

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

- Create a BOM with a rounting
- On the routing, set a location
- Create a MO with the BOM

The 'Raw Materials Location' is set on the location on the picking type
although in practice, the location of the routing will be used:

https://github.com/odoo/odoo/blob/f65bdd17308d6fa5f984dd23f0b345cd92c977cb/addons/mrp/models/mrp_production.py#L457-L460



This is confusing for end users.

We improve the onchange mechanism to set the location which will be
used. We also rename 'Production Location' since it is confusing for the
users.

opw-2116760

closes odoo/odoo#39647

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

Make an invoice in Foreign
Make a refund in Foreign
reconcile the two, partially

Make a payment in domestic, partial also, but with writeoff

Before this commit,

The invoice was not fully reconciled and -0.02 was yet to pay on it
Notice the negativity of that number, which actually means that it HAS been
fully reconciled !!!! (there is too much payment compared to invoiced)

This was because, the account.payment in domestic currency is doing:
Invoice residual in foreign, converted to domestic

Then that amount minus payment's amount gives write off amount in domestic

Then, at reconciliation, the whole payment's amount, which is
the payment + the writeoff contained the expected and mathematically
correct conversion and currency rounding errors
(which should make out the exchange difference)

The exchange difference IS created, and rightfully too
that is, it records the exchange difference as debit 0.01 in the receivable !

What was tricky though, is that the partial line recorded the debit 0.01 receivable
as its CREDIT move line !

After this commit, the receivable line is recorded as the DEBIT move line of
the partial between the payment and the invoice
so the invoice, is fully paid.

We keenly admit this is hackish, but justified:
- business-wise: the rounding/exchange errors are appearing ex-post
to the choice of the amount of the reconciliation between the payment
and the invoice, because we are reconciling them on the domestic amount

- technically: our hands are tied because some key information is not present
every time, and weirdly, not symmetrically. That is, the computation of
line.amount_residual[currency] may be different if your are on a line with a currency,
or on a line that doesn't.
We should really think of systematically putting the currency on the line
whichever it is ! The same goes for partial reconciliation model !
Touching the current behavior is out of the question.

Moreover, we should take into account that comparing amounts at different
points in time should be done by actualizing those amounts to a common date
See #39117 for details

OPW 2057845

X-original-commit: 40db7a8c

Note that the tests did not change in spirit, but the writing
of the exchange difference may vary from happened in v11.0
Indeed a quite big refactoring has been done in between
The tests reflect this

closes odoo/odoo#39631

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

`is_false` relies on no small part on equality tests between the input
triplets and either `TRUE_LEAF` or `FALSE_LEAF`. While these are
defined as tuples, RPC domains will always be lists (as neither
XML-RPC nor JSON have tuples, and their arrays deserialize to Python
lists).

This is an issue, because tuple and list never compare equal. As a
result, while the in / not in predicates can succeed, the TRUE_LEAF /
FALSE_LEAF never will, and thus domains which contain either and might
shortcut (avoid a query entirely) will always go through the entire
process.

Fix by having domain normalization also ensure all triplets are
tuples: that's the first thing `is_false` does, it should never cause
issues and could fix / improve / shortcut other routines.

Note: Also implements TRUE_LEAF and FALSE_LEAF handling in the
      SSF's modifiers evaluator. And fixes the ValueError to work
      correctly if it breaks on a tuple / dict.

closes odoo/odoo#39637

X-original-commit: 225f14e2
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Activate Google Synchronization, create on OE a recurrent event,
synchronize the calendar, then delete an event of the recursion on GC,
sync again on OE.

The event will be deleted from GC but not from OE after sync.

This appens because of this "rewrite" rule
https://github.com/odoo/odoo/blob/12.0/addons/calendar/models/calendar.py#L918


that occur on event creation from OE, altering the event parameters when
is marked "allday".

When an "allday" event is deleted from GC the unlink is triggered in OE with the
default time "00:00:00". During the creation of the exclusion '
_inverse_dates' will be called altering start and stop datetime but not
recurrent_id_date, so the new record will not match the event generating
the recursion and the exclusion will not occur. The problem require
particular carefulness because when a recurrent event is fetched from
google the '_inverse_dates' is not called, so in that case the default
time is fine.

opw-2060526

closes odoo/odoo#39580

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

Fine-tunning of 937b5c07

Have a multiwebsite setup
have a payment installed for one of the two websites

Make an order on that website and try to pay

Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP

After this commit, the payment success page is opened as we took
the request's url as the return url

opw-2080352

closes odoo/odoo#39587

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

Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider website W
- Activate multi-company
- Disable common contact book and common catalog
- Switch the superuser in company C2
- Activate pricelist
- Create a public pricelist PL for C1 and available on W
- Set up a pricelist with compute price = formula and  based on = cost
- Go Sales > Configuration > tick Multiple Sales Prices per Product and tick Prices computed from formulas
- Create a portal user PU and set PL on him
- Create a product P with cost = 10$ and publish it on W
- Set up the product valuation as: automated
- Log as PU and go on the shop
- Put P on your cart

Bug:

The price of P was 0$ instead of 10$

opw:2092695

closes odoo/odoo#39589

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

closes odoo/odoo#39603

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

Commit https://github.com/odoo/odoo/commit/c3c98e937e575853fe0b25fa6cb3c916e73fc591
introduced a z-index on parallax element to restrict the z-index -1 of
the s_parallax_bg in the snippets... this was however a bad idea as it
also restricts other positioned elements in there (like dropdown menus)
making them go under other elements in the page.

Fortunately, this z-index is in fact not needed at all since the
z-index -1 mentioned above has been removed with another commit:
https://github.com/odoo/odoo/commit/22745668cf66d802899dac526d810eba64b28c4b

However, the z-index -1 was necessary to force the s_parallax_bg under
static elements that go after it... and this was solved in 12.0 by
making those relative elements. See snippet refactoring in 12.0 with
https://github.com/odoo/odoo/commit/4dce6cc98b2b95a00249ac29245305e08f288e6c#diff-a50ffff96791f36c6dbe5c9273135e5aR783

closes odoo/odoo#39599

X-original-commit: https://github.com/odoo/odoo/commit/dc3bf304056d0e1c56724a1ee55a3b8d1c9be7c2


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

It was technically possible that two editors for the same element are
created in the same JS stack execution... and since 13.0 and the
use of native promises, it happens everytime a block is dropped in the
page.

Note: this commit fixes the problem with minimal code but the logic
should be improved in master.

closes odoo/odoo#39593

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

[FIX] stock_account: anglosaxon valuation: don't generate re-reconcile original bill and iterim lines when returning a picking for a purchase with unreconciled interim entries

To reproduce the issue fixed by this commit, on a clean DB with demo data, accounting, inventory, purchase, USD as company currency and aglosaxon accounting activated:

0) Make sure you have two currrency rates set between EUR and USD (we'll call them A and B, B being the most recent one).
1) create a PO in EUR for a product in FIFO automated valuation, validate it
2) receive the product (this will create a stock valuation account.move, using rate B)
3) create the bill in EUR for a date such as it will use rate A instead of B
4) Validate the bill. This will automatically reconcile stock interim entries and create an exchange rate entry
5) Manually unreconcile the stock interim entries and exchange rate difference that were just created
6) Create a return picking for this PO

+> This had the effect of re-reconciling the bill with the stock interim entries, hence re-creating an exchange rate difference entry.

We solve that by simply filtering which kind of invoice we want to reconcile interim entries for depending on the stock move we are creating.

opw:2062040

closes odoo/odoo#39517

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

Be in Right to left

Open a m2o search more, to get onto the list modal
toggle the filters menu

Before this commit, the filters dropdown was almost invisble
and too much on the right anyway

This was because the RTL was not taken into account

After this commit, we anchor the dropdown on the right
(both as in good and as in side) side of its trigger button

Also, when modifying the dropdown, by developping the Custom Filter
we force the repositioning of the dropdown, to take those new elements
into account

It is expected though that after this commit, in RTL, the
dropdown in a modal that has a scrollbar (which is on the left)
will be slightly pushed to the right. It is usable and visible though
Some kind of plumbing using $el.data('offset', fn) from popper.js
is possible, but has been deemed not robust enough

Docs
https://getbootstrap.com/docs/4.0/components/dropdowns/#methods



OPW 2088934

closes odoo/odoo#39353

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Have two companies A and B, A is the parent company of B.
A and B have fiscal positions set (FPA and FPB respectively). FPB has
autodetect set to True.

Before this commit, when creating a new Vendors Bill in company A, the
fiscal position of the invoice was auto-detected to FPB (from company
B).

Now, only the fiscal positions of the current company can be
auto-detected.

Closes #39085

opw-2091198

closes odoo/odoo#39458

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

Before this commit, when a refund of a salary slip was done, the 'Salary
Computation' lines where recompute from the 'Worked Days & Inputs'
lines. This generates falsely data if the structure or the contract
changes between the salary slip and the refund.

Now, when a refund is done, all the lines are copied from the salary
slip to be coherent with the salary slip.

opw-2081454

closes odoo/odoo#39412

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

The two method valid valid_alternative_icon_text and valid_title_icon
represent ~13% of an install all. Rewriting them in master
with in #36373 is the main reason of the performance improvement.

Those two method logic were broken, because
`xpath += '[not(//*[' + valid_attrs_xpath + '])]'`
will actually search for valid_attrs_xpath from view root,
not from fa- node.

-since this check will only log a warning and so only impact
 bugfix, no impact on user editing views,
-since a new check is added in master with the corresponding fix in views,
-since this check doesn't really test what it is suppose to check,
-since fa accessibility is great, but not critical

->removing those check will slightly speed up build without major impact
on views quality

closes odoo/odoo#39494

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

In the contacts app, you can select 2 partners and merge them.

Before this commit:

    - If a partner was added by a SQL query and not directly on Odoo,
      the create_date will be empty. This causes a crash because the
      merge wizard try to sort the partners by date

After this commit:

    - If a partner do not have a create_date, it will be considered
      as 01/01/1970. The merge wizard will sort the partners by IDs too.

OPW-2091925

closes odoo/odoo#39503

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

[FIX] l10n_es: change fiscal position name

[FIX] l10n_es: name suggested

[CLA] Update CLA with new mails

closes odoo/odoo#39473

X-original-commit: cbfcf710
Signed-off-by: Josse Colpaert <jco@openerp.com>
Co-authored-by: Pedro M. Baeza <pedro.baeza@tecnativa.com>