The new-api record prefetching algorithm attempts
to load data for all known records from the requested
model (i.e. all IDs present in the environment cache),
regardless of how indirectly/remotely they were
referenced. An indirect parent record may therefore
be prefetched along with its directly browsed children,
possibly crossing company boundaries involuntarily.
This patch implements a fallback mechanism when
the prefetching failed due to what looks like an
ACL restriction.
The implementation of `_read_from_database` handle
ACL directly and set an `AccessError` as cache value
for restricted records.
If a model (like `mail.message`) overwrites `read` to
implements its own ACL checks and raises an `AccessError`
before calling `super()` (which will then call
`_read_from_database`), the cache will be not fill,
leading to an unexpected exception.
If this commit messae looks familiar to you, that's
simply because this is the new-api counterpart of
b7865502e4
Some models (e.g. calendar.event), use "virtual" ids which are not represented
as integers. It was not possible to use sorted method on those models as calling
int() is failing.
This commit fixes the method, making it agnostic to the type of the
'id' member variable.
Fixes#7454
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
Using `field.translate(callback, value)` returns the translation of the given
field value by using the function `callback` to translate simple terms in
`value`. In practice, the function `callback` uses a translation mapping
retrieved from `ir.translation`.
* add missing columns in base.sql
* add missing fields 'help', 'readonly', 'required', 'selectable' in reflection
* add field 'help' in `ir.model.fields` views
* do not patch registry with translated field string and help upon `ir.model.fields` update
* add the necessary fields in `ir.model.fields`
* when loading translations, convert types 'field', 'help' into 'model'
* add specific methods to retrieve translations of field string and help
The `search` method of models has an additional keyword parameter, `count`.
It not being specified in the docs could lead people to inherit `search`
without defining it, which would result in a `TypeError` when called with
`count=`.
Closes#7451
Revert 83282f2d for a cleaner sanitizing earlier in the generation of the error
message.
If the import is failing, the error message contains the value that is
problematic. Escape this value in case it contains '%'
The methods `BaseModel._inherits_join_calc` and `BaseModel._generate_order_by`
are modified to add a JOIN to the translation table for translated fields, so
that the translation value is directly accessible in the query itself.
For the JOIN with the translation table to work, the method `Query.add_join` is
extended to take extra conditions in the join clause, together with parameters.
The following methods have been decorated with `@api.model` so that they can
carry the context: `_generate_order_by`, `_generate_m2o_order_by`,
`_inherits_join_calc`, `_read_group_prepare`, `_read_group_process_groupby`.
Rename the field 'osv_memory' on 'ir.model' into 'transient', and make it a
regular field instead of a computed one. When instantiating a custom model,
use its value to make transient models.
This commit alone will make your server crash on an existing database. A small
database migration is needed: simply add a boolean column `transient` (with
default value false) in table `ir_model`.
- 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.
- remove useless cache clear_prefix
- add a route cache attribute when used it will save the rendered page into the
ormcache for the specified time, this is only enabled if the user is public
and reponse code is 200
- enable it on /page controller for 5min
In commit 04ba0e99, we introduced an optimization for reading inherited fields
in a single query. There is an issue when you have more than one level of
`_inherits`. The query looks like:
SELECT ...
FROM table0, table1 AS alias1, table2 AS alias2
WHERE table0.link0 = alias1.id AND table1.link1 = alias2.id AND ...
^^^^^^
should be alias1
This fixes the issue, and adds a test to reproduce it. The fix is based on
@emiprotechnologies's own proposal, but is cleaner and does not break APIs.
Change the condition to disable the prefetching in onchange mode only. The
prefetching of fields was disabled in draft mode in order to handle the case of
onchanges on records: computed fields must to be recomputed and not fetched
from database.
This saves a few queries when computing a field. For instance, viewing a
question on the forum takes 66 queries instead of 85.
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
Consider a new field that uses the same compute method as another existing
field. When the field is introduced in database, its value must be computed on
existing records. In such a case, the existing field should not be written, as
its value is not supposed to have changed. Not writing on the existing field
can avoid useless recomputations in cascade, which is the reason we introduce
this patch.
Accessing `field.digits` can crash if no environment is available at that
point. This happens in function `get_pg_type()`, which is called from method
`_auto_init()`. An environment is simply created in the method's scope to be
available for `field.digits`.
As done in write and already in next version (see 0fd773a), accessing a deleted
record (through read or check access rights) should always return a MissingError
instead of the generic except_orm.
This will allow code ignoring deleted record (e.g. 'recompute' method) to safely
process the other records.
Fixes#6105
When method `fields_view_get` retrieves the toolbar actions, let it `browse`
the actions to check instead of `read`ing them. This enables prefetching and
reuse of cached values.
On the list of Customers, `fields_view_get` takes 62 queries instead of 73.
Enhance current widget="monetary" client-side feature and
convert it to a first-class type of field, allowing proper
server-side behavior.
- fields: add field.Monetary, similar to fields.Float but
supporting a `currency_field` attribute instead of the
decimal_precision attribute.
`currency_field` indicates the field holding the
related currency on the same record.
The symbol of that currency is used when displaying
the field, and the rounding of the currency is applied
instead of the usual decimal precision.
- avoids application of a second decimal precision rounding,
as was the case when the model field was a `fields.float`.
- removes the need for adding explicit boilerplate to each
view containing a monetary field, i.e.:
widget="monetary" options="{'currency_field': 'currency_id'}"
- res.currency: add new field decimal_places needed to round
value at the correct decimal places
- web: cache all currencies, rounding and symbols at
webclient startup to speedup monetary fields
- new widget monetary for list view + adapt widget monetary
on form view
Limitations:
- if the currency_field is a related field, the server-side
application of currency rounding will only work when the
record already exists, not during creation (to be fixed)
- this field is only supported in the new API
A cross-registry cache was introduced by e2ea691ce.
The initial idea was praiseworthy but sub-optimal for servers with a
lot of registries.
When there is lot of registry loaded, the cache size was huge and
clearing some entries took a lot of CPU time, increasing the chances
of timeout.
Also, the cache was not cleaned when a registry is removed from
registry LRU (this operation would also consume time).
The following case has shown the issue: extend the model `res.company` by
adding at least two fields F and G, where F has a default value defined as:
lambda self: self.env.user.company_id.name
If the column F is created before G in the database, the existing records will
be filled with the default value of F. When the default value is computed, the
field `name` from a `res.company` is read, and other fields are prefetched,
including G. This operation fails, because G does not exist in database yet!
Christophe Simonis