Previous to this commit, if one were to create an ir.model.field with a
poorly constructed domain (read: SyntaxError), the server would properly
send an error message stating that an Error occurred, however this would
be too late as the registry with the bad code would have already been
reloaded, this meant that the registry would be left in an unstable
state (read: crashed).
With this commit, a constraint on the domain is added so that we confirm
that the code in the domain field is properly constructed, thus no need
to reload the registry and therefore no crash.
closesodoo/odoo#30157
Create an automated action that creates a new record (of target crud_model_id).
Try using a link_field_id: nothing appears to be selectable, even if some fields
satisfy the intended conditions.
The issue is that the crud_model_name field was related to crud_model_id.name,
instead of the correct crud_model_id.model (note the apt naming).
Note that in the onchange the value of crud_model_name was correctly set to
crud_model_id.model, adding to the confusion.
opw 1910671
closesodoo/odoo#30145
The method `read()` may be very slow when reading relational fields and
computed fields, because the computed fields can be computed on a recordset
that is larger than expected.
The issue occurs on model 'res.partner' when reading fields 'child_ids' and
'purchase_order_count', for instance. Suppose we read those two fields on a
partner with 1000 contacts. First, the one2many field is read from the
database and stored to the cache; the latter adds the value ids to the
prefetching of 'res.partner'. Then, the fields are fetched from the cache.
When 'purchase_order_count' is accessed on the partner, the field is computed
on all its children as well...
closesodoo/odoo#29867
Following 4a3fd02af4 on the portal when displaying an invoice we may get
a report_type variable (with value 'html' or 'pdf') on the portal.
This was used to not display the page number when checking the report,
but when the report is printed in the backend this report_type was unset
so the page number was mistakenly removed too.
With this changeset, the report alway know if he is pdf, html or text
and only print the page number if it is of type pdf.
opw-1924729
closes#30095
During uninstallation of a module, recompute operations may be triggered.
The prefetch might thus try to read a column that has already been deleted.
Install CRM, create an opportunity then schedule a meeting
(itself a calendar event linked to the opportunity).
Note that the CRM module adds an opportunity_id field on events.
When you try to uninstall the module, the bug is triggered.
The calendar model contains a res_model field, which is related to res_model_id.
Its recompute triggers the prefetching of the opportunity_id field,
which has already been removed.
opw 1917354
closesodoo/odoo#29979
This commit adds a test to test the scenario fixed in the parent commit.
Creating a new test module is necessary as the bug is only revealed when the
current module is different than the model._original_module (cf c9837ac5dc)
Before that commit, was failing only the second search of
test_ir_model_data_inherits_depends.
Add other test to avoid regression of the bugs corrected at 574f4c3d and c9837acclosesodoo/odoo#30116
* website_theme_install
This commit will add MODULE_UNINSTALL_FLAG to the cleanup methods of themes and
modules.
This is necessary to also unlink inherited views of those we try to unlink.
Before this commit, an error would be raised when trying to delete a view that
still had other inherited views (either created manually by the user, or with
just bad luck in the order of which the views are deleted).
PR: #29753
If a module has a view that has been copied (copy on write, web editor,
customize show, manual copy, ...), currently the copied view will not be deleted
if the module of the original view is removed.
If the copy is not used anymore, it is not a problem (but still polluting the
database), but if the copy is still used (ex. it is an inherit of a view still
in use), then it will crash if that copy references other data (views, fields,
...) that were in the module that is now removed.
Eg.
The view `website_sale_comparison.product_add_to_compare` is inheriting
`website_sale.product` and calls `website_sale_comparison.add_to_compare`.
If the view `website_sale_comparison.product_add_to_compare` is copied (when
using the web editor on the product page -> copy on write is making a copy of
the `product` view and all its tree), then the product page on website will
crash when the module `website_sale_comparison` is removed because
`product_add_to_compare` will call the deleted view `add_to_compare`.
The solution is to also remove copied views when removing a module. Instead of
just using the xml id, we should look for the `key` starting with the module
name currently removed, because copied views don't have an external id.
task-1920005
PR: #29753
With 12.0's (#28297) empty translations were no longer added by default
with the idea that if needed the "Generate Missing Terms" wizard should
be used.
But that wizard itself used what was modified so also did not added
empty translation.
With this changeset, empty translations are added when using the
"Generate Missing Terms" wizard.
fixes#29184closes#30037
When using multi-company, the base currency of a product is the currency of the
main company, not a contextual company.
closes#29905closes#29946closes#30046
In case a record is no longer referenced in the updated module, its external id
is deleted.
If the linked record still exists, it is deleted as well.
This last clause was incorrect as the record may still be referenced in other
modules.
If a field is declared in module A
class FooA(models.Model):
_name = 'foo'
bar = fields.Char()
and overriden in module B
class FooB(models.Model:
_inherit = 'foo'
bar = fields.Char(translate=True)
In case the field is no longer inherited in module B (code change, moved to
another module,...), the ir.model.field record for bar was deleted.
Two external ids are linked to field bar:
A.field_foo__bar
B.field_foo__bar
The ir.model.field record should be dropped only if both ir.model.data entries
are no longer loaded.
Otherwise, only the ir.model.data entry should be deleted (i.e. B.field_foo__bar
in the above example).
Fixesodoo/odoo#29820closesodoo/odoo#30018
In community, when entering the Manufacturing app, the first view is the
Manufacturing orders list view as it's not the case in enterpise, the
two steps are only necessary in enterprise.
Note: even if it fix the tour, the main bug could still be there.
closesodoo/odoo#30016
In dff64b6f7ca some copied views with no link to a module would be
removed after module uninstall.
But this has some side effects when the website module is being removed.
For example:
- website_theme_install, website are installed
- website is uninstalled (which will uninstall website_theme_install)
- website.theme_customize view can't be removed because it is used by
copied view website_theme_install.customize_modal
- after uninstall _remove_copied_views will remove the view
website.theme_customize but when trying to remove associated
website.page will throw an error because website_page table does not
exist
This issue does not happen if we uninstall first website_theme_install
then website (since like this the reference is not an issue).
The issue also happen with overriding views in theme_bootstrap and
possibly elsewhere.
With this changeset, copied views are removed before uninstalling module
data.
opw-1924714
closes#30191
Combining a list of elements containing only the monoid's unit should return the
unit.
Since the unit is skipped, it would return an empty domain instead of the unit,
meaning that (0, '=', 1) could not be used in a group rule.
To test this, create a record rule on a model M with domain (0, '=', 1)
that applies to group G.
Log in with a user in group G and access model M; you can read everything
(provided no other record rule applies) whereas you should see nothing.
Because of expression.AND(global_domains + [expression.OR(group_domains)])
we want the empty domain to still be left untouched, even if it violates
the OR's unit rules (i.e. OR(empty, OR(R)) = OR(R) <=> OR(empty) = unit).
Meaning that no group rule would reduce to having a (0, '=' 1) group rule.
So in the end we don't really care about all that algebraic nonsense.
closesodoo/odoo#28765
Currently name_search on res_partner holds code to be done by a customized SQL
query allowing to speedup the search [1]. However when dealing with given args
there may be a crash if there is a domain based on user_ids fields.
Indeed this field is defined as auto_join [2]. It means the result of get_sql
returns where parameters based on joined tables. Those tables are not available
in the from clause in the original query.
This commit fixes that issue by correctly taking the from_clause from get_sql.
That way joined tables are available. Small update of the query is necessary
as fields are now res_partner.{id/email/vat/reference} as there may be several
tables linked in the query.
A test has been added to avoid regression.
[1] See https://github.com/odoo/odoo/commit/05ec12692f99b69924765fd0ce384632547f03f9 for a recent modification
and implementation of this query, even if it exists since a looooong time
[2] See https://github.com/odoo/odoo/commit/db8203c27a21acdbcad2cf1c394b6fea3cf13688 for the auto_join addition
closesodoo/odoo#29827
Adrian Torres