The protection prevents fields to be invalidated/recomputed on some records.
This mechanism is useful against accidental cache invalidation when computing
or inversing fields. It also prevents to trigger the recomputation of fields
before and/or after their inversion.
Add a test on stored field with compute and inverse methods: the test checks
how many times the compute and inverse methods are invoked in several cases.
Essentially, the field should not be recomputed when it is written.
The prefetching now has a more intuitive and controllable model: every
recordset is linked to a "prefetch object" that tells which record ids to
prefetch for any model. The prefetch object of a given recordset is shared
with the records obtained by iteration and relational field access. All other
operations instantiate recordsets with a fresh prefetch object.
records = model.browse(ids)
assert records._prefetch is not model._prefetch
for record in records:
assert record._prefetch is records._prefetch
assert record.relation._prefetch is record._prefetch
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
or in @onchange for that matter. They should already generate a warning,
but only the first time they're used.
This is done lazily because it introspects the instance/class which can
be costly when performed during the repeated setup of registry setup.
closes#5595
Add the possibility in the decorator to specify the `upgrade` and `downgrade`
functions that convert values between APIs. Both function have the same API:
upgrade(self, value, *args, **kwargs)
downgrade(self, value, *args, **kwargs)
The arguments ``self``, ``*args`` and ``**kwargs`` are the ones passed to the
method, following its new-API signature.
Fixes#4944, #7830.
The goal is to avoid recomputing field several times. Consider, for instance,
two fields F and G, such that G depends on F. Suppose that G is recomputed
before F. Saving G to database proceeds well, but when F is saved to database,
G is invalidated and marked for recomputation. Field G is possibly recomputed
twice on some records.
Avoid this situation by chosing a field such that none of its dependencies must
be recomputed; use a topological sort based on field dependencies for that
purpose. In the example above, G will never be recomputed before F.
Enable the prefetching of several fields while evaluating an onchange. Special
care is taken to not prefetch computed fields or fields already in cache. The
latter is necessary to avoid "cleaning up" dirty fields by accident.
The effect of this change is to trigger the recomputation of fields on larger
recordsets. This takes advantage of batch computations within compute methods.
* alter docstring of @api.one to mark it as deprecated for 9.0,
recommend using @api.multi instead
- deprecation notes were not correctly styled, add styling
matching "warning" alerts
* move @api.one down the doc page to deemphasize it
* fix "backend" tutorial to remove all instances of ``@api.one``
closes#8527
Pretty much completely rewritten theme with custom HTML translator and a
few parts of the old theme extracted to their own extensions.
Banner images thought not to be that huge after all, and not worth the
hassle of them living in a different repository.
co-authored with @stefanorigano
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
The `set` method of the one2many class returns a list
of the fields that require recomputation,
the computing of the function fields being delayed
for performances reasons.
Nevertheless, if the `set` method was called
through another `set` method, in other words,
nested `set` calls, the fields to recompute returned
by the second, nested, call to set were never recomputed,
the result list were simply lost.
e.g.:
```
create/write
│set
└─── create/write with recs.env.recompute set to False
│set
└─── create
with recs.env.recompute set to False
```
To overcome this problem, the list of old api style
compute fields to recompute is stored
within the environment, and this list is cleared
each time the store_set_value has done its job of
recomputing all old api style compute fields.
opw-629650
opw-632624
closes#6053
The computation of property `digits` was creating a new cursor to call the
function that determines digits. This technique is fragile because the current
cursor may have pending updates that the new cursor will not see.
The issue was discovered by Cécile Tonglet (cto). She observed an infinite
loop during a database migration, and a traceback inside the loop showed the
presence of the `digits` property. This change fixes the infinite loop issue.
In a workflow context (for instance, in the invoice workflow),
context is not passed.
Therefore, relying on the 'recompute' key being the context
in order to not recompute the fields does not work with Workflows.
It leads to huge performance issues,
as fields are recomputed recursively (instead of sequentially)
when several records are implied.
For instance, when reconciling several invoices with one payment
(100 invoices with 1 payment for instance),
records of each invoice are recomputed uselessly in each workflow call
(for each "confirm_paid" method done for each invoice).
With a significant number of invoices (100, for instance),
it even leads to a "Maximum recursion depth reached" errror.
closes#4905
This reverts commit 8cd2cc8910.
It turned out that forcing recomputing fields as user admin breaks some
existing behavior. Instead, we make the recomputation as user admin explicit
by adding compute_sudo=True in the field's definition.
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
This fixes an issue where the same function is used in several model classes:
once the function is wrapped for the first class, it is erroneously considered
as a wrapper for the second class, and is therefore not wrapped in other
classes.
Raphael Collet