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


Before this commit Internal user (With no other Rights) cannot perform any activity on Reminder Popup due to missing rights to set calendar_last_notif_ack field.
With this fix, we are now using sudo to write calendar_last_notif_ack

closes odoo/odoo#39407

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

In case of a multi-record and multi-page (i.e. 2 pages per PDF) report
the assertion is triggered b/c we have 4 pages and only two records with
a PDF of 2 pages each, so the outline_page needs to be unique before
assertion.

len([0, 0, 2, 2]) != len([record_id1, record_id2])
len([0, 2]) == len([record_id1, record_id2])

closes odoo/odoo#39701

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

From Sale create a new (or edit) SO. Add a note to the order with a long
line without dash or whitespace (i.e. a url). Save.

The table will adapt to display the long note on one line, shifting
right all the headers, creating an ugly and long overflow scrollbar.

Adding a "break-all" rule to mimic the behavior introduced in
a32aa05a

opw-2088589

closes odoo/odoo#40009

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

instead we do a simple try/except and catch the ValueError

closes odoo/odoo#40014

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

Since the deployement of the forward-port bot, chances to merge code
with conflict markers has greatly increased.

With this commit, a new test is added to grep for those markers in most
common code files.

closes odoo/odoo#39984

X-original-commit: 80f22f98
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Prerequisites

    - Configure a mail server (incoming)
    - Enable leads in CRM app
    - Create a sales team with a mail alias (ex: testcrm@odoo.com)
      and check "Pipeline" and "Leads"
    - Set a partner email with one of yours (ex: bob@odoo.com) /!\
    - Send a mail from bob to testcrm
    - In the incoming mail server click on "Fetch"

Reproduce the issue:

    - Convert the generated lead to an opportunity
    - Choose "Existing customer" and set another one than the actual
    - The opportunity is created but the customer is the old one

Cause:

    The given partner_id is overriden by the old one in the
    `handle_partner_assignation` method.

This commit gives the priority to the new partner_id.

OPW-2089404

closes odoo/odoo#40001

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

Firstly bd49f9fd did some fixes that removed a bunch of code containing 'install_mode_data'. Later, 627292f7 replaced 'install_mode_data' for 'install_filename'. Finally, 43dd9ecd reverted bd49f9fd (including 'install_mode_data' remnant).

closes odoo/odoo#39992

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

- Create the following invoice:
  Line 1: price 0.50, tax 15 %, analytic account set
  Line 2: price 0.10, tax 15 %, analytic account set
- Validate
- Go to the journal entry, cancel it
- Edit the entry, remove an analytic account

The tax line is recomputed from 0.10 to 0.09.

This is because the onchange performs the tax computation on all grouped
lines at once, which is equivalent to a 'round globally' configuration.

We need to split the logic depending on the tax calculation rounding
method.

opw-2117398

closes odoo/odoo#39960

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

closes odoo/odoo#39977

X-original-commit: 75b1d412
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Reproduce this issue:

    - Go in the lunch module
    - Create several orders for the same vendor
    - Go in "previous orders"
    - Select them and click on "actions > Lunch: Order meals"

    A traceback appears, no mail is sent and the status change to
    "ordered".

Cause:

    The `order` method in the lunch module returns an action but without
    enough information to send the mail correctly.

This commit add the missing information.

OPW-2118041

closes odoo/odoo#39959

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

Usecase to reproduce:
- Create a purchase requistion with type Call For Tender
- Update a line and set the price to zero.

UserError 'You cannot confirm the blanket order without price.' raised.
It happens because the write don't process the same check than create
and don't check if the purchase_requistion is a blanket order or a call
for tender. It also doens't check the current state of the
purchase_requisition.

closes odoo/odoo#39883

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

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>