Issue
- Install Contacts
- Create a contact: Company A
- Add a contact to that company: John
- Add a private address for John
- Save
- Change John's company
- Go back
- Look for the private address
The display_name contains the old
company name
Cause
The private address display_name is
not recomputed when the contact's
company changes.
Solution
Recompute child_ids display_name
when the company changes.
OPW-2253785
closesodoo/odoo#51450
X-original-commit: b112c8921eec60c63cead37c74946d06b499eb6a
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Allow groups_id on top level view as a way to relax the access of some
views
There was some scenarios where ir.ui.view were still needed to be
accessible.
For instance the website.snippet is needed to display the website
editor sidebar to designers. The website.compiled_assets_wysiwyg is
needed to display the app switcher on the website to employees.
This should cover most of the cases where a view still must be
accessible and no specific controller is available.
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The method fields_view_get should be the only way to retrieve the view
content. This method is executed in a super-user context.
To avoid retrieving views for a model a user does not have access to
(as it may reveal some informations like name of fields), add a
verification of 'read' rights before retrieving the view content.
Execute _postprocess_access_rights with sudo(False) as this method is
used to evaluate which buttons should be displayed.
Remove the su flag to avoid misleading the user and displaying a
button they won't be able to use.
Retrieving the database id from an view key is not considered as a
sensitive information and get_view_id and viewref can be left as a
public methods.
Add missing sudo when needed
Change _handle_visibility in website to avoid increasing the query
count: Checking the visibility (to fail most of the time) to retry in
sudo was making unecessary queries.
Currently, scheduled Actions only work if you choose "Python Code" as
the action type ("Action To Do"). Other action types are not really
supported as they work "record-wise" (using active_ids) which makes no
sense for scheduled actions.
We should help users avoid surprises by hiding the "Action To Do" field
on scheduled actions, and default to "Python Code" implicitly.
Example steps to reproduce :
- go to scheduled actions > create a new action
- select "Execute several actions" as action to do
- add several actions to execute
- run this action
=> the sub-actions were not executed
opw-2227082
closesodoo/odoo#51242
X-original-commit: b19c7c54efceb780806d876efc65a8813e3491d1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Activate Studio from dashboard of database A
- Export studio customizations
- Activate Studio from dashboard of database B
- Import studio customizations previously exported
The imported data don't have the boolean studio field set to True.
Since v12, when loading a module, a query is executed to create or update XML ids.
The create and write methods are not called anymore.
Therefore the overridden create and write methods of "ir.model.data" defined in Studio module
are not called and thus cannot set the studio field to True.
The generation of the query creating XML ids has been moved to a private method
allowing another module like Studio to override it.
opw-2245578
closesodoo/odoo#51203
X-original-commit: 198ab837e466f3155ea1c3b35811b981b1c1e537
Related: odoo/enterprise#10586
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Let field F of model M be a Selection field.
Before this commit, creating a database with field F, removing/renaming
field F by changing its definition within the code then upgrading the
database to reflect the changes would result in a registry crash because
the field would still exist in the database but not in the ORM (memory),
thus trying to fetch the field in DB from the memory would result in a
KeyError.
This is due to the fact that field renames / removals are not stable
operations and should be handled with a migration script when upgrading
an existing database, nevertheless this can be quite an annoying
behavior while developing which is why this commit simply skips the
processing of the field if it does not exist in memory.
The ORM already foresees these cases and logs a warning to the developer
saying that the field was deleted anyway but that it was only a
partial delete and that it should be handled in a migration script in
order for the change to be production ready.
closesodoo/odoo#51099
X-original-commit: a54fecc35386f8e00018ff3d858b383d43f1dded
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Since a required field can not be empty: a warning message will
be thrown if a many2one required field has the "on_delete"
attribute set to "Set NULL".
Task ID 2250533
closesodoo/odoo#50751
X-original-commit: 084555c6395b484a85ec9d386fbc8afc8aec1f8c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit introduces several changes in the search panel with
respect to record counts:
- the record counts are now also available for
the fields with select="one" attribute
(if not disabled explicitely).
- the record counts are better computed using the idea that
selected values within a group should not impact the counts
for the group values but only the counts for the other
group values.
On the way we have changed two keys in the values returned
by the server:
- 'count' becomes '__count'.
It has been done to avoid a possible clash in case a model would
have a field named 'count' and that the field values would be
wanted for some reason.
- 'name' (multi case) becomes 'display_name'.
It has been done in order to make the select one and multi cases
more similar and factorize some code.
TASK-ID: 2166814
Co-authored-by: Raphaël Collet <rco@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Alexis Lacroix <laa@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
It has been a recurrent request from customers to be able to send email
messages to email addresses containing non-ascii characters. [IDNA] is a
domain extension to allow unicode characters in domain names. [SMTPUTF8]
is a SMTP extension to allow unicode in any header.
IDNA defines the [punycode] encoding which translates unicode to an
ascii representation. This encoding MUST be used to encode domains.
SMTPUTF8 is an SMTP extension that allow utf-8 in all headers on the
envelope.
[IDNA] https://tools.ietf.org/html/rfc5890
[SMTPUTF8] https://tools.ietf.org/html/rfc6531
[punycode] https://tools.ietf.org/html/rfc3492
Task: 2116928
opw-2229906
opw-2248251
closesodoo/odoo#47709
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If an action has for instance twice "tree" in view_mode, you get a crash
when displaying the action.
This patch adds a python constraint on the model which will prevent such
change.
closes odoo/odoo#50189
Opw: #2241415
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
1. Create an invoice and upload a picture file as the only attachment
2. Try to print "origin bill" for the invoice (From the invoice tree
view select one and click print > origin bill )
An error will raise "PIL.PdfParser.PdfFormatError: trailer end not found".
Fixing by using another BytesIO object as the output.
opw-2244625
closesodoo/odoo#50469
X-original-commit: 378551193d8199cfab13b06a48aa706f420a7823
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When computing the `arch` from the arch_db, the field gets translated
as a matter of course as `arch_db` is a stored field with a
translation method. This means `arch` is assumed to be in the proper
language in the cache.
However when reading from the filesystem (dev=xml) this is not the
case, and the view XML ends up untranslated.
Fix the issue by applying the translation function from arch_db onto
the stuff we got from the filesystem.
Note: under the assumption that we *do not* want to store translated
archs in arch_db, explicitly set the lang to None when resetting
views.
Task 2059557
closesodoo/odoo#50389
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Cache should be invalidated when updating `arch_db` via `arch`.
closesodoo/odoo#50512
X-original-commit: 1a14ca163ee256eb26661c900227db49426ec3af
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
ref() always trigger a database query to verify record still exists.
In frequently used methods, it's best to avoid ref calls if not needed:
* either the records should always exist
* either the record isn't always needed and the ref can be sometimes
avoided.
X-original-commit: c1e05da7b71c8274aff00d67f8d1bc7e209fcaab
Steps to reproduce:
- Create a second company
- Enable this company only
- Create a new company
=> Access error is raised because the `intercompany_user_id` is
OdooBot by default and OdooBot's partner cannot be read from
other companies. Hence, the company creation fails.
Like all other internal users/partners, OdooBot's partner should
be shared across companies, even if its user is inactive.
Task 2157039
See also 2390ba6
Task 2157039
closesodoo/odoo#50372
X-original-commit: 379d14d4aa7862176fb7e3f79292a1228c254aa9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Commit 8c1bb22ec0222dca652e0649454b986c06cb1368 forgot to take into
account migrations, during a migration it is possible that some modules
need to be uninstalled because the target version may have removed /
moved them and since during a migration all modules are set `to
upgrade`, the previous condition made this impossible for migration
scripts that use the ORM for module uninstalls (not Odoo's case, mind
you)
With this commit it is again possible to uninstall modules from a
migration script during a migration.
closesodoo/odoo#50322
X-original-commit: a7c90a6d080a77316924cec9d3c64f9662ac7436
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Purpose
=======
For a tag to be displayed on a kanban card, it needs to have a color set.
We won't be changing that behaviour, since it would mean having
two options > the color, and whether or not to show it in the kanban
The purpose of this task is to set a color on new tags to make the user
save a bit more time, set a color for him as he might not find the feature,
and make sure the tag will be on the kanban cards.
Specification
=============
For each of the following models, at creation, set a random integer between
1 and 11 in field 'color'
Models:
res.partner.category
crm.tag
project.tags
hr.applicant.category
helpdesk.tag
hr.employee.category
event.track.tag
mrp.eco.tag
repair.tags
closesodoo/odoo#49967
Taskid: 2234527
Related: odoo/enterprise#10112
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Http routing and websits module will already do it later and handle the case.
The only ModelConverter used that will be impacted is:
/web_editor/attachment/<model("ir.attachment"):attachment>
that is a json controller called with eisting data
task-2211013
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Followup fix of #48912
The multi-company group should be given to users if they have access to
multiple companies and do not already have this group.
closesodoo/odoo#50233
X-original-commit: 0c721d90c5cd428ef8d51f195da8e02ee91d4364
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Instead of triggering one has_group by user (one sql query/user if not already ormcached),
and potentially filling the `has_group` cache with new users data (we don't know if and when this data
will be used anyway), compute this field from the groups information already in cache.
X-original-commit: d771d7e9c8503543d29fdbf2ab961c2a32cc3bac
Improve the performance of the default method for user groups by avoiding a `ref` call,
using the group in cache instead.
Calls to ref always trigger one SQL query to verify record still exists
This means that creating 10k user would trigger 10k queries only for the default.
X-original-commit: e67efb88338ef669059591728e7722fe1dff4bf0
The main classes of partners and users support batch creation, but
the majority of their overrides doesn't support creation in batch.
Adapting those overrides to support records creation in batch shows
great performance gains:
* On `res_partner` : 2 to 3 times faster
* On `res_users`, with the inherited `res_partner` created in batch:
up to 10 times faster.
Tests done with 500 to 4k records:
* `res_partner` with only a name provided
* `res_users` with a name and login
X-original-commit: 9c3c5f161580039c1fe50f68acac808c18817997
When creating new translations, do not prepopulate the translation
with src.
Take the following scenario:
- set a value in a translatable field in English
- open the translation popup -> creates all ir.translation
- notice an error in English, close the popup
- correct the error in English
- reopen the popup -> existing translations not modified
Add test about reseting
closesodoo/odoo#50147
X-original-commit: 619eccc7a533eedfb3aec0c3740ead1006e0f2f7
Related: odoo/enterprise#10194
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
With this commit, module operations such as install, upgrades and
uninstalls are henceforth forbidden inside unit tests and instead such
tests must be performed with standalone Odoo scripts.
This is done because module operations during tests are not
transactional, this can leave the registry in an unclean state and
further tests may be affected by this, it also creates a new registry
which complicates registry cleanup if anything crashes,
because the registry to be cleaned up is not the same one that crashed.
Instead, what should be done is a script that imports odoo as a library,
and loads the database necessary then performs whichever operations
necessary. This script should contain a single function with a single
parameter (env) and should be decorated with
@odoo.tests.common.standalone in order to be executed properly, this
decorator accepts any amount of positional parameters as tags that can
be specified when calling the script in order to execute only a select
subset of scripts.
Special tags are: 'all' and <module_name>, these are generated
automatically, the first will execute ALL scripts available whereas
<module_name> will execute all scripts introduced by said module.
When calling the test_module_operations script, only scripts found in
*installed* modules will be executed, script discovery is only possible
if the code is loaded therefore it is only possible if the module is
installed.
closesodoo/odoo#49669
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
- Create 2 companies C1 and C2
- Install any module with access rules, e.g. `account`
- Create an invoice in C1, attach a document
- Switch to C2
- Go to Settings > Technical > Attachments
An `AccessError` is raised.
This happens because the `_search` skips the ACL and record rules for a
system user, while they should only be skipped for the superuser.
opw-2236561
closesodoo/odoo#50067
X-original-commit: 9a71d60c25804bc4bae8c2c680c537f8a7a0900f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Werkzeug 1.0 adds a `merge_slashes` feature which calls rule.build()
*during match*[0] (= during dispatch).
However at this point our environment still contains an invalid /
placeholder UID, so `display_name` / `name_get()` fails dramatically.
One possibility would be to update the slugifying to not access the
record (outside of the id) if the environment is not "proper", an
other alternative is to just disable the feature since it seems to not
have been necessary so far.
The latter seems less hacky so do that for now, we can always swap the
solution later if we need to.
[0] https://github.com/pallets/werkzeug/blame/048cdfd9b969c0c3a133d7ff43b8ad1ad6a673ec/src/werkzeug/routing.py#L904
Set a default email signature to an empty string to avoid `False` when
evaluating `${user.signature | safe}` in email templates.
opw-2229846
closesodoo/odoo#49558
X-original-commit: 96f46fba2635d8050aef03c7d4744a87ac8a597e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Currently, sometimes users are getting confusing between the concepts
of 'objects' and 'models' when doing advanced configuration or
customization.
So, In this commit we replace 'object' label by 'model'.And also add
quicksearch on the relation field.
TaskId: 2209594
Related Ent PR: https://github.com/odoo/enterprise/pull/9556
closes odoo/odoo#48647
Closes: #48647
Related: odoo/enterprise#9556
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* add a `raw` computed field, though only update some of base to use
it (addons for which that makes sense can be migrated progressively)
* avoid working with base64 data when it's possible to work with the
actual data
* improve datas (base64 encoded content): should depend on bin_size
closesodoo/odoo#47212
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
While installing a module on an existing database, the modification of
groups should reset the `base.user_groups_view` to a dummy view in order
to validate user views. The `user_groups_view` is set to its "right"
value at the end of the installation.
closesodoo/odoo#49114
X-original-commit: 071bd77944484bad6f2c0cb9a7a98785dcc693c6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Toggle method defined on ir.ui.view does the same job of toggle_active that
is the generic one available on all models.
Task ID 2170708
Community PR odoo/odoo#46563
Simply avoid computing a field when not necessary.
This saves 0.5% of the total installation time.
closesodoo/odoo#48967
X-original-commit: f3fa93228b6ea8e9e171aaa508ca0218d70406f3
Related: odoo/enterprise#9655
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This reverts commit f7d7c53cd5.
Need to investiguate debug=assets mode.
Revert to unlock others devs
closesodoo/odoo#48675
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Similarly to method _binary_set_headers, when we serve an attachment
(e.g. image) where an unique is present in URL we add a long time of cache.
We considere that the hash will be changed if attachment is updated, so
while we ask for same checksum, lets the browser return the cached response.
closesodoo/odoo#48653
Signed-off-by: Christophe Simonis <chs@odoo.com>
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.
[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module
Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.
[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification
Version 1 is still supported, so no need to backport this.
[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)
This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.
[IMP] account: make it possible to mark manual payments as sent with a button on the form view
This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.
closesodoo/odoo#44839
Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- 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, method `postprocess_pdf_report` was public and can
be called over RPC while there is no usecase to allow it to be called
over RPC.
Clarify helper of field attachment_use
Remove helper of report_name as QWeb is the only supported type
Log wkhtmlerror
closesodoo/odoo#33770
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In case of short controller that don't use qweb template, we don't need
anyhting else that this url code that don't change frequently.
It make only sense for model like lang, website, ... that will not change
frequently. And are called on each call by the dispatcher.
In case of a website page, we will btw browse lang later, but in case of
small controller like /favicon.ico, or page without qweb, ... we can just
use the same from last query.
If model is already an ir.attachment we don't need to do a new search_read.
We can use it record directly.
After this commit, we don't do extra request if we already have the info,
else we don't change the behavior.
task-2211013
Most of the time, the record exists, but we still ensure it does, every single
time, making an SQL query.
Doing a try catch will result in the same behavior, but won't make that query
most of the time.
task-2211013
jvm-odoo