Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
There are two issues with the index naming convention used by the ORM:
Problem 1: it is possible to have naming conflict for indexes. For
instance, the name 'slide_channel_tag_group_sequence_index' is used for
both fields slide.channel.tag.group.sequence and
slide.channel.tag.group_sequence. Only the first index will be created.
Solution 1: we separate the model and field names with a double
underscore instead of a single one, which is the same strategy as with
LEFT JOIN aliases. This is correct because model names don't contain
such double underscores or underscores as prefix or suffix (it is not
forbiden but model name should follow the 'dot notation'.)
Problem 2: index names can be longer than 63 chars, but PostgreSQL
silently truncates it. This doesn't actually break anything (PostgreSQL
also truncates values when we check the existence of indexes) but it can
lead to using the same name twice. There is hopefully not any example
in our code.
Solution 2: if the name is too large, we truncate it and pad it with a
hash of the complete name to match 63 characters, which is also the
strategy used for LEFT JOIN aliases.
task-2984730
closesodoo/odoo#100736
Related: odoo/upgrade#3957
Signed-off-by: Raphael Collet <rco@odoo.com>
A related field copies the attributes from its target field, except for
the attributes defined on the related field itself. The implementation
of this feature was not working properly for attributes with a truthy
default value.
closesodoo/odoo#79025
X-original-commit: dec4a7ec478fa02f19dee8c8426c88d17dc3c7f3
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This mainly keeps field.related's type consistent.
On a registry with 296 modules, this saves 325 kilobytes of memory,
which is about 3% of the registry's memory footprint.
- Let A and B be two different modules.
- A defines a required Selection field F of model M and B extends
it through the `selection_add` argument.
- Create records of model M and have some of them have any of the
options introduced by module B selected for field F.
- Uninstall module B.
The result will be records of Model M with an option for field F that no
longer exists, this makes the registry inconsistent and prone to
crashing (it is sufficient to access the form view of such a record to
trigger a crash).
This commit introduces a mechanism similar to the `ondelete` argument
found in Many2one fields, the argument name is the same but it's
different both in behaviour and in implementation.
The `ondelete` mechanism for Selection fields is enforced for **any**
Selection field with required set to `True`, this means that the
developer is required to set a cleanup behaviour for when their module
is uninstalled. For possible cleanup options, see fields.Selection's
docstring.
As far as implementation goes, everything is implemented in Python
unlike with Many2one fields where the behaviour is delegated to
PostgreSQL.
The `ondelete` setting will be processed during
`ir.model.fields.selection.unlink()` to ensure that the registry is left
in an appropriate state after module uninstall.
Before this commit, x2m fields were described as 'sortable'
This was odd since:
- When actually sorting on one of those fields through the webclient
the sorting was gibbrish
- Even the orm silently warned in the log that
the field was not a sql column and therefore was not sortable
After this commit, only a field which is column (and a few other conditions)
can be sorted
Task 1863492
closesodoo/odoo#46921
X-original-commit: dd3094378fc322447d1aef994f6bace3f0c24288
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The selection values of a selection field are now stored in database in the
model ir.model.fields.selection
This will allow to have a modular approche on selections and each selection
is now linked to the module that declared it.
Previously to this change, the selections were linked to the field, meaning
uninstalling a module had no impact on the selections stored on database.
With this change, the selections will now be translated in the correct module
(having an external id) and the records having a used selection will now be
reset to null.
closesodoo/odoo#30228
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
Yolann Sabaux