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>

In the detailed operations view and in an immediate transfer:
    - add a line
    - select a random lot_id
    - select a random product_id
    - validate

The system won't raise while the combination of product_id/lot_id may
not make sense. We add a constraint to solve this isse.

Closes #25766
opw-1868453

closes odoo/odoo#39112

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

Actually, docker is used to test Linux packages once they are built.
The packaging process is done on the host system where package.py is
run.

Consequences:
    * difficult to reproduce an exact same build on another host
    * changing a Debian/Ubuntu target version means some upgrade steps
      on the build host (mix that with the fact that the host also
      could build old Odoo versions)
    * Fedora rpm package is built on an Ubuntu system (which is not a
      real problem but it could be)

With this commit, the package.py utility is refactored to use Docker
containers to build the Gnu/Linux packages.

Backport of 8c4c4394

closes odoo/odoo#38940

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

closes odoo/odoo#38861

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

closes odoo/odoo#38797

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

Users sometimes define custom models on SQL views
e.g. @nseinlet
In such a case, Odoo should not attempt to create foreign keys
as it just cannot work on views.

This could prevent the migration of a database
with such a custom model using a view
when it attempted to fix the missing foreign keys
when updating the modules.

closes odoo/odoo#38951

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

Without this patch, if a view defines a `<label for="forbidden_field"/>` anywhere, the web client tries to fetch the field data, but since the user has no access, it gets an error.

Now, if the label targets a forbidden field, it gets removed from the view, as happens with the related field. The client doesn't know of that field's existence and no errors happen.

closes odoo/odoo#28755

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

The method ``action_pos_order_invoice`` is multi, and has a ``for`` to
each record, then, inside of that for, is called the method
``_action_create_invoice_line``, but is called with self, not with
order, that is each record.

This was fixed to avoid singleton error.

closes odoo/odoo#38809

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

- Create 2 rates for a secondary currency
  2019-01-01: 1.0
  2019-10-01: 2.0
- Create an invoice on 2019-09-01 in the secondary currency
- Register a payment on 2019-10-02: pay the invoice partially in the
  secondary currency, and mark the invoice paid

No journal entry is created for the currency rate difference.

Backport of commits e1306066, 8bec4fa0 and
f7971a95.

opw-2072519

closes odoo/odoo#38252

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

In manufacturing orders, there is a kanban view.

The kanban items are drag & droppable from a column into another.
When moving an item into the "cancelled column", the stock move
is not applied.

Actually, you can't change the state of a MO by clicking on the state
in the status bar. So, the expected behavior is that you can't drag
and drop an item into another column.

According to this, I reproduced the same behavior than in V13.

Before this commit:

    - The kanban items can be drag and dropped from a column into
      another but there is no stock move

After this commit:

    - The kanban items cannot be drag and dropped like in V13.

OPW-2081255

closes odoo/odoo#38761

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

Before this commit, trying to print a registration without a name
specified (not required), was failing

Fixes odoo/odoo#38564

Replace and closes odoo/odoo#38582
Courtesy of Swapnesh Shah

closes odoo/odoo#38767

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

Operators child_of and parent_of fail if the right hand side is empty or yields empty results for many2many fields. We should avoid the exception generated by writing a query of the form ... id in ().

Closes https://github.com/odoo/odoo/pull/30121



closes odoo/odoo#38380

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: mreficent <miquel.raich@eficent.com>