Fine tuning of this commit: f93fcaff

Steps to reproduce the bug:

- Open runbot v11
- Restrict Demo's access to Sales Manager for sales and employee for Employee
- Try to create a new quotation

Bug:
- You got Odoo server Error
Sorry, you are not allowed to access this document. Only users with the following access level are currently allowed to do that:
- Inventory/User
- Accounting & Finance/Billing
- Purchases/User
- Purchases/Manager
- Other Extra Rights/Portal
(Document model: purchase.order.line) - (Operation: read, User: 5)

opw:2120692

closes odoo/odoo#40094

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

self.env.user returns the current user but browsed with the superuser:
- self.env.user == current user
- self.env.user.env.user == administrator

get_context uses self.env.user to retrieve the context of the user.
Before this patch, the name of the filters was translated in the
language of the administrator instead of the current user.

Closes odoo/odoo#40086

closes odoo/odoo#40108

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

When using the flamegraph module from a parent directory of odoo, the
dirname method returns a relative path, leading to a traceback.

With this commit, the odoo_path is enforced to be an absolute path.

closes odoo/odoo#40100

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

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

closes odoo/odoo#39588

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

Usecase to reproduce:
- Create a BoM with 2 components for a final product
- Create a MO for 100 final products
- Produce 50
- Post Inventory
- Update the MO quantity to 200
- Produce 50 more

The total quantity for components consumed is 175 (instead of 200)

It happens because the update quantity do not take care of existing
produced unit when it updates the raw material moves and their unit
factor. (FYI unit factor is used later in order to know the quantity
to consume depending the produced quantity)

Fix #39866

closes odoo/odoo#39963

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.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#39813

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

closes odoo/odoo#39772

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

Usecase to reproduce:
- Create a product tracked by serial number
- Do an inventory adjustement for it with the selected option 'one
product only'
- Add a new line with a serial number
- Save

Error due to missing product_id field at the inventory.line creation.
It's due to readonly set on the view. It will select by default the
inventory product but it will not send it to the server.

Add force_save in order to send the field even if it's readonly

Fix #39902

closes odoo/odoo#39935

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

Steps to reproduce the bug:

- Let's consider a user U linked to employee E
- U is allowed to access to company C1 and C2
- E is in the department D in company C1
- Log as U in C2
- Create an expense XP
- Submit XP to your manager
- Click on button 'Save'

Bug:

An access rights error was raised because D was not readable in C1.

opw:2092710

closes odoo/odoo#39928

Signed-off-by: Simon Goffin (sig) <sig@openerp.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#39884

Signed-off-by: pimodoo <pimodoo@users.noreply.github.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#39811

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

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

closes odoo/odoo#39354

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Without hr_recruitment it was not possible to import/export the hr.job
as they were not visible.

closes #22069

closes odoo/odoo#38881

Taskid: 2088277
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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#39792

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

When a boolean field is readonly is should not return any focusable
element.

This commit is a backport of 58c64558 (v12.0).

OPW-2075243

closes odoo/odoo#39790

Signed-off-by: Aaron Bohy (aab) <aab@odoo.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#39742

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

Without this commit, if you have the hr_timesheet installed, the one2many analytic lines view (in the Journal Items form) shows the hr_timesheet_line_tree view instead, which is not desired.

closes odoo/odoo#39670

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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#39341

Signed-off-by: Xavier Morel (xmo) <xmo@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#39660

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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#39499

Signed-off-by: Nans Lefebvre (len) <len@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.

closes odoo/odoo#39590

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

closes odoo/odoo#39527

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


This commit thus also contains a backport of that work.

closes odoo/odoo#39497

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#39575

Signed-off-by: Quentin Smetz (qsm) <qsm@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 https://github.com/odoo/odoo/pull/39117

 for details

OPW 2057845

closes odoo/odoo#39205

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

These changes were announced in the new Annex 24 RFM 2019 [1] and define
the new code for  accounts for the northern border zone. This change affects a
part of the CoA because these accounts were changed from the middile to the
end of the group.

[1] https://www.sat.gob.mx/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1461173776384&ssbinary=true



closes odoo/odoo#39399

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#34044

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

The profiler was too optimistic. If the local variable self was not a
cursor, it assumed it was automatically an Odoo model.
Instead, only do the custom tracer methods when self is an instance of
BaseModel.

Full scenario to reproduce explained at odoo/odoo#39237

In case a method like the default_get of utm.mixing was profiled, the
tracer crashed when evaluating `__bool__(request)`.
The tracer considered self as an Odoo model while it was a werkzeug
instance with its custom __getattr__ that crashed while trying to
retrieve the content of `_name`.

Fixes odoo/odoo#39237

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#39270

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

partial backport of 8a0fc647 from task-2065018

closes odoo/odoo#39307

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

Ref: https://en.wikipedia.org/wiki/Tanzanian_shilling



opw-2091857

closes odoo/odoo#39253

Signed-off-by: Richard Mathot (rim) <rim@openerp.com>

This commit intend to allow better inheritance in the
account_move_line_creation_process

The new _prepare_account_move_and_lines method only prepare
the move and the lines but does not write and post them.

This is done by the former _create_account_move_line method.

Needed to fix pos_sessions with unbalanced journal entries
caused by round globally option with taxes included in price

It is a backport of https://github.com/odoo/odoo/commit/52d68984459210cc1a1da039707eb47ae937da07



closes odoo/odoo#39108

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

Before this commit, the calendar searched records on the wrong time ranges
which did not take into account the timezone of the user
It obviously resulted in some records not being there

After this commit, all the relevant records are fetched according to the right
time range in UTC, corresponding to start/end of the week/month/day of the calendar

OPW 2076114

closes odoo/odoo#39184

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

Was comparing b'0x02' and '0x02'

closes odoo/odoo#38407

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#36149

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

closes odoo/odoo#39162

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

Makes it easier for users to match Odoo payments with information
from the Stripe dashboard.

closes odoo/odoo#39092

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