The try/except is there to check that the string can be interpolated, so
it is catching a ValueError. But if there is a singleton error (when the
length of `self` is bigger than 1), it will raise a ValueError too.
The UserError raised in the except is then weird/wrong.

closes odoo/odoo#69538

X-original-commit: 36ebbb6f312d488b33bae098546ff71baf578a08
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>

Revert commit
"[FIX] base: clearer message in case of conflict for no_gap sequences"

This commit changed the error returned in case of SQL conflict for no_gap
sequences, wrongly disabling the automatic retry (service/model.py) in case
of such errors.

Also adds a comment in the dedicated test to ensure the behavior is explained
and the automatic retry isn't broken once again by the same kind of change.

closes odoo/odoo#59904

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

The raw error message from psycopg2 wasn't clear for users and led to 
multiple support tickets.

In case of such "concurrency" errors, the user should retry later, it's 
not a "real" bug.

closes odoo/odoo#57810

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

ir_sequence is currently broken when trying to view the list of
sequences (if there are any in the system) and when trying to create
one:

During the sql-thingie, I prepared the `params` local to differentiate
the params to provide in both cases of a conditional, then promptly
forgot to do that, so no parameter is provided when one is needed,
which breaks... on every pg >= 10 (which at this point is probably all
of them).

Correct this error.

Furthermore, the "computes are onchange" was not impacted on
`_get_number_next_actual`. On creation, this leads to trying to format
a NewId as a number. If that is just defaulted, we will then try and
`_predict_nextval` for a sequence which doesn't exist in the database.

Just yield `0` if the sequence hasn't been created yet.

closes odoo/odoo#56397

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

The linter would miss / fail to warn on injection of *local variables*
in some cases.

Try to improve it to be stricter and more reliable, after discussion
with odo, sql which is "correctly" dynamic should use psycopg2's sql
package in order to bypass the linter (bonus: it should also properly
escape & quote identifiers).

closes odoo/odoo#53938

Related: odoo/enterprise#11718
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Purpose
=======
The main definition of 'assignation' is the following:
   "an appointment to meet someone in secret, typically one made by lovers"

The correct word we should be using is 'assignment':
   "the allocation of someone or something as belonging to a particular group or category"

So in this commit change every iteration of the word
'assignation' to 'assignment', across all modules.

closes odoo/odoo#45041

Taskid: 1966215
Closes: #45041
Related: odoo/enterprise#8375
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

When `invoice_sequence_number_next` is set in [1], the move date is not
taken into account to find a corresponding `ir.sequence.date_range` in
[2]. We use the current date instead.

However, when the move is posted we use its date to find the
`ir.sequence.date_range` [3]. This leads to an inconsistency: we set
`invoice_sequence_number_next` on the `ir.sequence.date_range` of the
current date, but at posting we use the `ir.sequence.date_range` of the
move date.

The fix is to take into account the move date when we set
`invoice_sequence_number_next`.

[1] https://github.com/odoo/odoo/blob/40c8da4bd47d99a97b7231f2749c8e981f35a1a0/addons/account/tests/test_account_move_in_invoice.py#L829
[2] https://github.com/odoo/odoo/blob/40c8da4bd47d99a97b7231f2749c8e981f35a1a0/addons/account/models/account_move.py#L1153
[3] https://github.com/odoo/odoo/blob/40c8da4bd47d99a97b7231f2749c8e981f35a1a0/addons/account/models/account_move.py#L2096

closes odoo/odoo#42580

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

From now on, if one wants to force following operations to happen in a given company,
use with_company(company) or with_company(cid) to update the environment.

This branch is the combination of several optimizations in the ORM:

* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;

* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;

* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);

* make method `modified` take advantage of inverse fields to inverse
dependencies;

* filter records by evaluating a domain on records in Python;

* a computed field with `readonly=False` behaves like a normal field
with an onchange method;

* computed fields are computed in superuser mode by default.

Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.

closes odoo/odoo#35659

Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>

Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.

Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`