Our usage of domain on fields One2many seems to trigger an obscure behaviour on
onchange.
With the following (simplified) config:
Message(models.Model):
_name = 'test_new_api.message'
important = fields.Boolean('Important')
Discussion(models.Model):
_name = 'test_new_api.discussion'
name = fields.Char('Name')
important_emails = fields.One2Many('test_new_api.emailmessage', 'discussion',
domain=[('important', '=', True)])
Email(models.Model):
_name = 'test_new_api.emailmessage'
_inherits = {'test_new_api.message': 'message'}
discussion = fields.Many2one('test_new_api.discussion', 'Discussion')
message = fields.Many2one('test_new_api.message', 'Message')
Steps:
- We change 'name' on discussion, triggers an `onchange()` call
- we ends up filling cache on virtual record (on secondary fields, we calling
record.mapped('important_emails.important'))
- we get a cache miss ('important' field not provided, only 'important_emails' ids,
i.e with no change on existing records)
- we fill the cache, this mark 'important' field as modified
- because of commit 5676d81 and because 'important' is that case is a related (i.e
computed) field we triggers cache recomputation
- as there is no way to recompute 'important_emails' for virtual record (no real
ID) we ends up with empty 'important_emails' generating removal of existing records.
=> Finally changing any value for 'test_new_api.discussion' that trigger an onchange
will always reset 'important_emails' to empty
Fixed by Raphael Collet <rco@odoo.com>, and test by Xavier Alt <xal@odoo.com>.
This reverts commit d780f9476d.
Did not work due to the size=3 on name field that strips the code to the first
three letters only (removing the " (copy)" part).
Copying a currency has a few business cases as the rates are not copied.
As can not increase the size of a field in stable, remove the method that had no
effect.
Fixes#11036
The _auto_init method was overriden without keeping the return value of
the super on some models.
This break the new stored computed fields computation at field creation.
Closes#11985
opw-677232
Invalidate the cache of a x2many field when any of the fields appearing in its
domain is modified. Use the invalidation triggers mechanism for that purpose.
On the `res.company` model, the fields
`name`, `phone`, `email`, `website`, `vat` are
related field on the `partner_id` of the company.
When creating a new company, the partner
associated to the company is created automatically,
it's handled in the overrided `create` method
of the model, but it forgots the values
`phone`, `email`, `website`, `vat` at the moment
the partner is being created.
opw-675526
This fixes the case where the lines of a one2many field are modified several
times by onchange methods: instead of retrieving the most recent updates, we
merge them with former updates.
This solution was written as an improvement of a proposal made by Alexis
Delattre and Sébastien Beau as #11620.
This revision corrects a regression introduced by
8395f0d217e16df18fcc6f4309fe74b0dd8d50a2:
the possibility to call
`ir.qweb.field.datetime`.`value_to_html` with
a datetime string directly, instead of calling
`ir.qweb.field.datetime`.`record_to_html`
(which call `value_to_html` as well).
opw-675427
The dates of an event on the website was always
within the user timezone. If not signed in,
it was within the public user timezone
(which is quite not user-friendly to change)
For this purpose, we weed get the context
from the record (the context used when using
`record.with_context`), and therefore
the QWeb field
`ir.qweb.field.datetime` is slightly altered,
to use the context from the record.
opw-675427
Users may sometimes need to edit their own partner records directly,
although indirect access by writing on `res.users` directly works
fine in most cases.
Could not edit t-field content if modified by inherit xpath,
and could not inherit qweb views with non "xpath" nodes with
`position="attributes"`.
Examples:
Can't edit: `<data><xpath expr="div[@t-field='object.test']"
position="replace"><div t-field="object.test"/></xpath></data>`
Inherit doesn't work: `<data><h1 position="replace"/><h1
class="test">tata</h1></data>`
Closes#11561Closes#11547
To reproduce the bug:
- Create a partner.
- Set it state "Alaska".
- Country becomes "United States".
- Set a country for YourCompany, such as Spain.
- Create a partner.
- Set it state "Alaska".
- Country remains blank.
Also, `node.xpath("//field")` was running over every `<field>` in the
view, not just those inside the `<div class="address_format">`. Now it
only traverses the right nodes, which renders every affected view
faster.
The ir.actions.todo record base.open_menu is used to redirect the user
to a menu after installing a module.
To do so, a new module override the record changing its action (toward a
menu) and setting its state to "open".
But with f7fe753 when one such changed action is removed after
uninstalling a module (or removing the action by any other way) the
base.open_menu would also be removed. Thus thereafter the open_menu will
not work anymore (since type "automatic" is lost).
With this commit, when whenever base.open_menu is removed, instead its
action will be replaced by base.action_client_base_menu which is the
original action.
closes#11224
related to: #11216, opw-660269
This is related to revision 80b373f.
The above revision leads to the inability
to import new records without any `xml_id` set
Technically speaking, this is because
you cannot concatenate `False` with `'_'`, in
`xml_id + '_'`
opw-668962
The result of searching on a o2m field for a missing ID was
the whole set of records which do not have any lines in the
o2m fields. This is definitely not the desired behavior,
and could lead to disatrous performance, because the
returned set could be extremely large.
One example of such behavior is for recomputing fields
in the env cache in 8.0+. When a o2m line gets deleted,
it triggers the recompute of any dependent fields.
In order to locate the records to recompute, the ORM
searches for the 'parent' records in the comodel table.
When this operation is done by 2 users concurrently
the o2m line may not exist anymore, and the bug
is triggered: dependent fields are recomputed on a possibly
very large set of records that did not need any recompute!
While the signature makes sense in an old API context (sort-of) it's
very easy to misuse in a new API context as one'd expect `has_group` to
use the subject (recordset), not the user in the environment, compounded
by ``env.user`` being browsed as administrator, resulting in the
"obvious" ``env.user.has_group(foo)`` checking if the
administrator (rather than the current user) has the specified group.
Adds a divergent v8 version of has_group which first checks if it's
called on a non-empty recordset, and in that case use the recordset id,
otherwise fallback on the context user (to handle new API conversions
which used the "correct" call convention rather than the obvious one).
fixes#9649
When writing on a recordset with duplicates, the ORM raises a `MissingError`
because the rowcount gives a difference with the injected ids. The fix simply
eliminates duplicates from ids.
Traversing new records in a different cache requires that all new records on
the path are copied across caches. Make the copy across caches recursive when
the first record on the path is a new record.
The keep_query() function has to **keep** all or selected query parameters
or add new ones but not change them by merging those with the same name.
That unnecessary parameter merge breaks the *Change language* feature in the
website_sale module when *Website -> Customize -> Product Attribute's filters*
is enabled and there's 2 or more select type attributes created and at least
one of them is selected.
Merging params was added in:
* 8.0: commit 7759af7c4c
* 9.0: commit daf8bdf688
When inheriting from a view in extension mode created in the same module, this
view was not loaded during check_xml of the last view.
This caused an error when the last view wants to modify elements added
by its direct parent view.
Example :
- View1, created in module "account"
- View2, mode extension, created in module "customer", inherits View1
- View3, created in module "customer", inherits View2
During update of module "customer", when loading View3, the check_xml
call didn't load View2, because it's defined in the same module (and,
obviously, this module has not be totally loaded at this point)
This is fixed by adding direct parent of each loaded view in the
check_view_ids list in context, to force them to be loaded.
Closes#9135
Description: When updating the product module, if the "Service"
product.product has been deleted, but not the corresponding
"product.template" part, the update will crash on a "duplicate xml id"
error.
This commit fixes the bug by :
- Adding the link to existing inherited model xml id in values
- Avoid creating the duplicated XML ID
If the XML ID is found, but orphan, it's simply deleted.
Closes#8966
opw-658454
Once set for the loading of terms for a lang,
the flag `overwrite` was propagated to all
other following languages, even if not actually needed.
Use case:
- Installed languages: en_US, de, fr_CH, it
- Update of the `sale` module
- In `load_module_terms`, the system iterates through the languages:
1. en_US: No problem
2. de: No problem
3. fr_CH: The flag `overwrite` is set to `True`,
because the sub-language `fr_CH` should overwrite the `fr` terms
4. it: The flag is still set to `True`, because of the previous iteration,
while it must not.
opw-654042
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
close#9925
When creating translations (click on blue flag) of a duplicated record, it used
to have the module information of the duplicated record.
It is also not useful to check the module when trying to find if a translation
exists on this record as the res_id is present in the query.
Fixes#9480
When a translated term is modified (e.g. content of an email.template),
reloading the translations of the module (e.g. when updating the module) used to
recreate a new, duplicare translation for the modified term (instead of ignoring
the existing one).
This was due to the fact the matching expression (find_expr), when loading
translations, used the field 'src' (source term) as criteria for (almost) all
ir.translation records.
While this is true for type 'code' or 'selection', this is not true for 'model'
where the source content may have been changed.
In case of translation of type 'model', matching on the name and res_id should be
enough for the matching expression and then, avoid creating duplicated
translations.
Note: this patch must NOT be present in 9.0 due to the xml_translate
attribute that splits an xml content into small parts.
opw 654031
When creating missing translations on an object (e.g. using blue flag icon on a
field), the value of the module was not set.
This was problematic as could create a duplicated translation when the module
was updated or the translation reloaded (as the module is used in find_expr).
opw 654036
res.users form contains virtual fields in_group_ID to be added in res.groups.
Groups with boolean share=True (added by share module) must not be displayed in
the form and should not be modifiable through the user interface.
However, if a module adding/modifying a res.group is earlier in the dependency
graph than 'share' (e.g. only depends from 'base'), the update of the user view
is done before share is loaded and the overrride of 'get_application_groups' is
never executed.
As we can not guarantee that the module is share loaded, put the logic of
hidding the module in base instead of share.
This workaround is quite hacky but is necessary in stable version.
Better fix in 9.0 at cf63d4d
Fixes#6324Fixes#5820
This revision is related to 1b8c9aed9f
As `manual` is now the default value of the `state`,
if `state` is not given in the values when passed to
`create` or `write` of `ir.model` and `ir.model.fields`,
we must assume the value is `manual`, so the columns and tables
are instanciated in database
opw-657750
This was possible to create custom fields `x_*`
but seen as base fields.
For instance,
- Go to Settings > Technical > Database Structure > Fields
- Select a field (any)
- Click on the model link, to be redirected to the model form
- Edit & add a custom field from there.
- Save
- Notice that the field you just added is saved as a base field.
We solve this issue by assuming that all created fields and models
are customs, except the ones created by the ORM, by the database
initialization, the fields coming from the modules in python.
We therefore remove the mechanism on which a field was set
as custom according to the fact `manual` was set to True within
the context: This is now the case by default.
No change was required for the base fields: The `state` `base`
was already forced for those fields, that are created using
direct SQL requests `INSERT INTO`.
opw-657312
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 attribute `data-oe-*` (`data-oe-id`, `data-oe-model`, ...)
must not be added when rendering the assets, to avoid
having different assets content,
e.g. a different content for the assets_common,
according if the user is signed in or not,
if the user can edit the website or not.
A different content for an assets according to the
users rights or the user being signed in or not means
that the assets are permanently re-written in the filestore,
which is against the point of the assets.
The content of the assets (assets_common) must not be
different from time to time, it must always be the same
(except when installing a new module, obviously).
Adding the `data-oe` attributes was pointless for the assets
anyway, and prevented having an identical content all
the time, therefore rewritting the assets all the time
in the filestore.
opw-657046
Odoo Translation Bot
Xavier ALT
Martin Trigaux
Christophe Simonis
Sylvain GARANCHER
Raphael Collet
Olivier Dony
Denis Ledoux
Christophe Matthieu
Jairo Llopis
Nicolas Lempereur
Cedric Snauwaert
Xavier Morel
Goffin Simon
Holger Brunn
Eric Antones
Jeremy Kersten
Frédéric Garbely
qsm-odoo
Jesús Alan Ramos Rodríguez