Before this change the rollback hooks were never called since rollback() was never explicitely called by the framework. At the end of a transaction, if no error occurs the famework call commit() on the odoo cursor. In all cases, the transaction ends with a call to close(). Into the implementation of _close()  rollback() is called on the underlying connection to ensure that not committed changes are rollbacked. That's the reason why despite the fact that rollback() was not called on the Odoo cursor, changes are not committed into the db in case of exception. To keep the same behaviour and avoid to have to explicitely call rollback() on the odoo cursor to trigger the execution of registered rollback hooks, these hooks are now processed in _close(). Since the list of registered hooks is emptied if commit() is called, we are sure that rollback hooks are only executed in case of rollback.

OPW #2294911

closes odoo/odoo#60334

X-original-commit: dce9a05f3a5d37fab711c8ca3c5444941f98e814
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>

This fixes a crash in some controllers with `auth='None'` where some
updates are flushed with an environment where `uid=None`.  When there is
an environment with a real uid, preferably use it.

closes odoo/odoo#59650

X-original-commit: 2795c86df54389b858a454cbc1782b1f34f3ba4f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Use the more convenient `cr.postcommit.add()` instead.

closes odoo/odoo#56990

Related: odoo/enterprise#12914
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.

While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).

Also, the API of `GroupCalls` turned out to be unusual and weird.  The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions.  The API is now:

    callbacks.add(func)     # add func to callbacks
    callbacks.run()         # run all callbacks in addition order
    callbacks.clear()       # remove all callbacks

In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.

Discovered by @william-andre

Related to odoo#56583

References:

* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
  (no direct link because individual entries are not linkable, look for
  bpo-1617161)

X-original-commit: a986f4929bab95759086cc77ca5e60795f82e91a

Upon cursor `commit()`, the pending computations are performed with
method `flush()`.  However the latter method leaves fields to compute on
new records.  As the `commit` ends the current transaction, we can clear
those pending computations.

X-original-commit: d27e98d9048d0cb1250522205286ebc7b7d5ea39

- A bug has been introduced by the PR https://github.com/odoo/odoo/pull/46719
  This issue prevented flushes to database when no `uid` is set in the
  current environment.
  This happens when database changes are made in `auth="none"` routes.
  In a MonoDB setup this was working because Odoo consider `None`, `False` as
  `null` and was always bound to a database.

  Nothing prevents to write `null` in the columns `create_uid` and
  `write_uid` in database.
  The PR that introduced the bug wanted to block the cases where
  `uid` is an instance of the class `RequestUID` to avoid `Cannot adapt
  type` errors.
  So testing that `uid` is an integer isn't enough.

  Two fixes were possible here, either check if `uid` is an instance
  of the class `RequestUID` or if it is either an integer, `False` or `None`.

  To avoid noise and imports from `odoo`, we test that `uid` is an instance
  of `None`.
  The case where it is `False` is already tested in the python code:

  ```python
	isinstance(env.uid, int)
  ```

(manual) forward-port of odoo/odoo#48685

closes odoo/odoo#48693

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

When routing an HTTP request, the dispatcher uses an environment with a
placeholder for the user (the object `RequestUID`).  This environment is
not supposed to be used after routing has been done.  However, the
flushing function takes any environment with a given cursor, and it
crashes when this environment is chosen (`psycopg2` cannot adapt the
type `RequestUID` for `write_uid`), and simply does not make sense.

closes odoo/odoo#48495

X-original-commit: da61a64bf6731a08557d23680eabf4d910035ebd
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

The `__closer` attribute is filled with the origin of a call to
`cr.close()`. That information is reused in the `check` decotator that
ensure the user is not using a closed cursor. In case he is using a
closed cursor, an error is raised with that optional origin in case of
`--log-sql`.

The attribute is a dundler so it is only accessible within its class, as
the decorator has been moved outside of the class by 058cf208a8e7 it is
not directly accessible thus `__getattr__` is called as a fallback. The
`__getattr__` itself is protected by the `check` decorator thus they
call each other in a infinite recursion.

As the related dundler is no more used internally, it has been decided
to remove it entirely.

closes odoo/odoo#47616

Task: 2199895
X-original-commit: 3ebf7cb9cca37b05f44aaffc0b1f289cc65f300f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

Starting with Python 3, queries sent by psyocopg2 are stored as `bytes()` objects.

Logging those raw makes them appear unformatted, harder to read than in v10 or lower Odoo versions (i.e. `\n` instead of a raw newline character).

Decoding the query into unicode makes it easier to read in the logs.

closes odoo/odoo#38074

X-original-commit: 329accde2ed6d4dbfdde6d3d99d71e21d15396b7
Signed-off-by: Christophe Simonis <chs@odoo.com>