The attribute `group_expand` allows to reorder and add empty groups to the
result of `read_group`. Enable this feature for other fields than many2one
fields.
Problem: the update of custom models/fields is not fully transactional, and may
potentially lead to an inconsistent database. An other problem is creating two
custom fields by writing on a model: if the second one fails, the first one has
been committed without notice. Retrying the request will give an unexpected
error (duplicate field name).
Solution: never commit in the middle of a request. If the changes have an
impact on the registry, then mark it as invalid (with a new flag), and signal
registry invalidation after everything has been committed. If the request
fails, reset the registry. Both registry and cache invalidation are handled
the same way.
This fixes the following issue. Assume a custom field F is created on
`res.partner`. This field will appear on `res.users` as an inherited field,
and will be reflected in `ir.model.fields` as a 'base' field. When F is
removed from the parent model, it no longer appears on the child model in
registry, but remains in `ir.model.fields`.
The patch allows the proper removal of the no-longer-inherited field from
`ir.model.fields`.
get_formview_action is now called as sudo to avoid access rights issues
when browsing it and trying to determine the ID of the form view to
display.
However in some cases it can be interesting to know the real user trying
to access the form view. The original uid is therefore added as parameter
of the method to have the best of two worlds.
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)lang can be None
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
Previously availability of meta-information (failing constraint,
impacted table and column, …) in pg errors (e.g. constraint check
failure) was limited and only available through formatted error
messages, which could be localised (by PG itself) so not did getting
that information require string extraction it was brittle in the face of
localised instances.
Postgres 9.3 adds this meta-information to error diagnostic data
(`PQresultErrorField`), allowing easy programmatic access to it.
Psycopg2 [added a Diagnostic
object](http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.Diagnostics)
around the time pg9.3 was itself released.
Assuming Odoo now requires pg >= 9.3 we can remove the old string
munging extraction for diagnostic.
* funny story, the handling of 23505 didn't actually work because
"duplicate key value violates unique constraint" is a literal part
of the error message, I'd misunderstood "value" as a field name
because my test model's field was called "value". Makes sense too
since you can set UNIQUE constraints on multiple fields (and UNIQUE
indices on expressions)
* for both errors, it should be possible to use the table_name or
constraint metadata to provide messages about sub-model issues (a
constraint on an m2o), but that's not currently handled
Fixes#15323
When copying a record in an other language L than US, first a translation
was created for L by the create called in the copy function and afterwards,
a second translation was created by the function copy_translations
So there were two duplicated translations for L instead of one.
opw:706865
The call of the name_get on records with falsy ids was unnecessary
as it wasn't used afterwards and could lead to errors if a name_get
doesn't handle falsy records.
solves https://github.com/odoo/odoo/pull/16244
The fields objects are responsible for creating their column/table and indexes.
The methods that update the schema are overridden to handle cases specific to
each type of field.
Christophe Simonis