The purpose of this patch is to avoid `filtered_domain` to crash with
domains on date/datetime fields when the fields are `False` on some
records:
records.filtered_domain([('date', '<', '2019-10-28')])
closesodoo/odoo#39449
X-original-commit: dae379adebedb3ed9bd38a2d6925ba6aefef1e7f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
res_name is made non-stored in 8fffe89b0481af057fd6908a52af775578b9fce1
but the groupby filter using the field is not. The filter has to be
removed as well because groupby only works with stored fields.
closesodoo/odoo#39396
X-original-commit: 495124497c733b4bb272fb0d65e132b024a99917
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before, en_US was almost always the default in case of 'no language'.
Now, that should be superseded by lang=None;
yet still, en_US plays the role of source language.
In a multilanguage database where en_US was not installed,
writing a translation with lang=None would crash.
This could prevent module installation.
A test is added to cover that case.
In the case where we write a record with lang=None, the source is the
same as the record; in that case the cache contains the value for the
field.name under the context keys en_US and None, so we need to
invalidate the cache to avoid getting back the old value.
co-authored with mart-e
opw 2088487
opw 2083710
closesodoo/odoo#39130
X-original-commit: 1a5a999c2dd69c9a6a2dacb59e8bf45b09c6bc13
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Since https://github.com/odoo/odoo/commit/a5b6f31cf28e5381e1c85f66730bcdb55998e643,
the current companies of the user are saved in the context as "allowed_company_ids"
context key.
In case of invalid context content, the api was computing the intersection
between the context content and the user company(ies) and falling back on user
company_id(s) when catching an error.
A sanity check was done, but no feedback was given to the user,
saying that the context change was falsy.
This commits changes this behavior to :
* raise an AccessError when trying to access self.env.company(ies) when
invalid or unauthorized companies are defined in the context.
* take sudo mode into consideration, allowing inter-company impacts,
even when current user doesn't have access to a given company,
if the code is done in a sudoed environment.
Co-Authored-By: Raphael Collet <rco@odoo.com>
This is a preliminary work for task 2088171 that will
improve server action creation usability in marketing automation.
When creating a marketing automation activity, one can choose to trigger a server action.
This task aims at improving a the usability of this option for non-technical users
as well as cleaning the view a bit (because so far we display the standard server action form view).
closesodoo/odoo#38922
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The queries made by the method `_is_an_ordinary_table` represent about
8% of the time to do a full Odoo installation. Use a cached query for
all tables on the registry to reduce that time to some negligible
amount.
closesodoo/odoo#39262
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The nightly clickall runbot fail due to a crash of the underlying chrome
browser used to run the test suite. The problem is related to the
resources the browser is using. We leverage the problem by starting one
dedicated browser per app.
closesodoo/odoo#39190
X-original-commit: 228e57d980839bd2b4e9123bf26f8a64de2ae6ab
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The basic ORM methods should not silently discard unknown fields, as
they may be a sign of broken code.
X-original-commit: 9595dd06a1d349b2fb84969374d57c32a5faab74
This commits fixes user duplication.
Suppose there is a monetary field, with a currency_field that is a related.
When going through model's _create, we do:
`if field.type in ('one2many', 'many2many'):
self.env.cache.set(record, field, ())`
knowing that thse values are false, with the intent to clean them later:
`for record, field in cachetoclear`
However, when setting the scalar values, we go through:
`accessing cache_value = field.convert_to_cache(value, record)`
In the case of the monetary field, this depends on another field value
(the currency_field). If it is a related, we can access its value.
However, at this point, if we check any access rights, we might use the value
of a relational in cache for which the value is incorrectly set to False.
In the case of the user, this is what happens: it inherits its currency_id
from partner, as well as its debit_limit which depends on it.
When the access if checked, company_ids is set to False in cache.
So when going through the rule 'user rule', which checks that the company_ids
intersects with the env.companies.ids, the result is always False.
In some way this is essentially hiding the problem, but the true fix is
probably not feasible in stable.
opw 2086661closesodoo/odoo#39017
X-original-commit: aa05a9359b42317261c8e7ffcadbeb9fe74dcd58
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Start odoo-bin using a tier module (like `python3 -m pdb odoo-bin`), the
odoo/addons __path__ contains the relative link to the modules instead
of the absolute link like when directly started (`python3 odoo-bin`).
This cause trouble importing modules because it reuses the relative path
from within other directories.
closesodoo/odoo#39182
X-original-commit: 941e051fc6b33e7a90400c77d63d589049b027a6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This fixes a regression introduced by 291a0e99d137142bd24addd1054c1357ddd7125a.
closesodoo/odoo#39178
X-original-commit: 852ee32e3419c210a3844b0f943af8dd2bbdae88
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Do not return a boolean but skip bad translations
Introduced at 19e50ea374Fixesodoo/odoo#39001
At least fix the error that is thrown, however, this does not solve
the initial error of trying to export the terms of a record that is no
longer present in the database.
As this issue is no longer reproducable, just log a warning as it was
expected.
closesodoo/odoo#39122
X-original-commit: 5c0677bf2fbf6d18978989f1ee70e4a0946da035
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, if `max_width` and `max_height` are 0, the image would not
be opened by Pillow at all (to gain a bit of CPU) however this was actually a
bad idea in this case because then we don't ensure the given value is actually a
valid image when we save it, only later at display we notice it and it crashes.
This optimization only made sense when `image_process` is called many times,
from the route displaying images every time a visitor is requesting an image,
for example. It doesn't really have an impact for one time operations such as
creating/writing.
So when size parameters are 0, which is the default, another parameter must be
passed to `image_process` to ensure image validity, and `verify_resolution` is
actually built for this, as it does the minimal amount of processing:
- loading the image
- making sure it is valid
- and ensuring the resolution is not completely crazy (`IMAGE_MAX_RESOLUTION`).
It doesn't alter the original image if no other operation was requested.
Pr: #38292
X-original-commit: e16c36bb4bfa3ae1739712c69c72849665a057dd
Binary fields are supposed to be saved as binary in cache, and not as string
which is also supported as an input value.
Pr: #38292
X-original-commit: 64e0d106adccd8132cbfeb6b60da74b3feaf05e1
The compute methods are always expecting the real value and not the bin_size.
The solution is to always compute with `bin_size=False`, and then manually
compute the `bin_size` and set it on the cache of `bin_size=True`.
PR: #38292
Co-authored-by Sébastien Theys <seb@odoo.com>
X-original-commit: 7744886d6141ca7971d91807d0444c707e10fdf8
Assets bundle creation will try to find previous version of assets and unlink them.
This needs to invalidate ormcache to notify other workers.
Since assets are never commited during test, assets will be generate at each request if request is
not commited (cursor closed) whtch is the case with 404.
Invalidating the orm cache only when a previous attachement was existing will help to
mitigate the problem, and slightly improve HTTPCases test speed.
closesodoo/odoo#38979
X-original-commit: d4d63549e1b31e3f3c97a2b91155023dbac62847
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Without this patch, if a view defines a `<label for="forbidden_field"/>` anywhere, the web client tries to fetch the field data, but since the user has no access, it gets an error.
Now, if the label targets a forbidden field, it gets removed from the view, as happens with the related field. The client doesn't know of that field's existence and no errors happen.
closesodoo/odoo#38876
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Users sometimes define custom models on SQL views
e.g. @nseinlet
In such a case, Odoo should not attempt to create foreign keys
as it just cannot work on views.
This could prevent the migration of a database
with such a custom model using a view
when it attempted to fix the missing foreign keys
when updating the modules.
closesodoo/odoo#38988
X-original-commit: dfaea03de57394a9a188f499da664c57dd9adc29
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Purpose
=======
It sometimes happens that the last runbot build is green, but it's
impossible to create a basic record (a new user for example) in the
interface.
This commit adds new tests using the Form tool (so triggering the
onchanges, and so on), to check that those basic models can be
instanciated without any issue on the interface.
closesodoo/odoo#38962
Taskid: 2070350
X-original-commit: e6d8c471c036a35b2c86f91d0053435f468c0ab8
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
It is possible to get to a situation where Odoo would try to send an email without a `From:` header address.
In such case, you're unlucky if you don't have access to the underlying deployment, or if you use multiple databases in a single Odoo instance and each of them uses a different mail configuration.
To make this configuration easier to use and cover those use cases, here I add support for a new ICP: `mail.default.from`. It will be used when present, so it shouldn't affect existing deployments. When present, it will allow a admin to configure the default sending address just with Odoo itself.
closesodoo/odoo#38874
X-original-commit: 5010ce630a7f0e01d45d99c9083318b50f9f624a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After the refactor of mail sending with the newest python API
(18299d7e50),
the order of multipart/alternative was wrong for email.
Indeed, in the MIME protocol [1], for The Multipart/alternative subtype
the order is significant: "In general, user agents that compose
multipart/alternative entities should place the body parts in increasing
order of preference, that is, with the preferred format last".
This bug caused some issues with mail marketing (see related task)
with Gmail web client (see the plaintext instead of html mail).
The fix is to inverse the order of adding alternative in the mail
content.
[1] https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
TASK_ID : 2084989
closesodoo/odoo#38490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* use an editable tree to edit the supplier info
* keep the original forms because they're used in the "vendor pricelist"
menuitem
* updated tour
* change the position of requisition_id
Task-2029380
closesodoo/odoo#35972
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In 12.0 it was 3.5 but for 13.0, it is acceptable 3.6.
Debian Buster has 3.7 and Ubuntu 18.04 LTS has 3.6
This will avoid undeterminist errors with OrderedDict
CentOS 7 still does not ship python3 by default but it is possible to
install it and CentOS 8 with python 3.6 was released in septembre 2019
closesodoo/odoo#38827
X-original-commit: 14e3e7524c2edd08ddf19afe512cb4462d070c0b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Let a model M define a Many2oneReference field F1.
- Let a model N define a One2many field F2 whose inverse is M->F1
- Define a computed field N->F3 that depends on N->F2
If, for whatever reason, a recordset of M contains records that have
been unlinked already and we try to unlink them again, the system will
crash with a MissingException error.
This happened because, while most _modified_trigger cases cover the case
of a MissingException (i.e. record not in cache), the case for a
Many2oneReference didn't.
This is fixed by simply ignoring these "stale" records in the
_modified_triggers section for Many2oneReference fields.
closesodoo/odoo#38816
X-original-commit: f3b05032f0576befda4dca870718afd429c21b0f
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: mreficent <miquel.raich@eficent.com>
Before this commit, some images would display incorrectly orientated.
This typically happens for images taken from a non-standard orientation
by some phones or other devices that are able to report orientation.
The specified transposition is applied to the image before all other
operations, because all of them expect the image to be in its final
orientation, which is the case only when the first row of pixels is the top
of the image and the first column of pixels is the left of the image.
Moreover the EXIF tags will not be kept when the image is later saved, so
the transposition has to be done to ensure the final image is correctly
orientated.
closesodoo/odoo#38717
X-original-commit: 0f8e132ec0495fcdfa0a47d5b9c98a2f6f10c7d8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Create a sales order for a company with a contact name.
- Click the Preview button.
- The company and contact names appear on the same line, only separated by a
comma.
Before this commit:
it's not possible to easily override this behavior.
After this commit:
it's possible to override `Partner._get_contact_name` to change the format of
contact name.
Beware that this method is used in `_get_name` which is called from various
places. A check on the context may be necessary.
closesodoo/odoo#38712
Opw: 2077294
X-original-commit: 0b8f3f93a2cb05cc9c940964fe80acd23b86b8a0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, in base we use bus to notify the user but bus module
is not always installed and so we can't call it.
After this commit, now we use a client action to notify the success test.
Steps to reproduce:
* install a Odoo with no apps
* go in debug mode
* go to "Outgoing Mail Servers" technical settings
* create a valid SMTP record
* click on "Test Connection" button (BUG)
closesodoo/odoo#38709
X-original-commit: ea4113745024a72bd170d9ceef38e97acd420d4e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Because of 4b1cb41cf7, we might try to read
the field 'active' on a record on which we can't read fields besides the name.
This thus triggers an access error where there should not have been.
In particular, this is the case for portal users: most often the records they
can access point to records that they can't read
(e.g. the partner of the internal user assigned to the ticket).
As a result, clicking on any link creates an ACL, and thus redirects to the
home page.
It turns out that filtered_domain was primarily used on already loaded records,
typically for the write, so it was assumed that the records could be read
in the first place.
However in the use-case of the portal, there is an explicit check on the read
rights with the portal user, explaining the discrepancy.
Since in the general case filtered_domain should be able to read all fields
to evaluate the domain, we put it in sudo.
fix co-authored with @rco
closesodoo/odoo#38540
X-original-commit: cff5cc8cc78a32eb204368e84ec4980324046405
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Example of workflow to reproduce the issue:
- Add a selection field 'Test' to `project.task` with Studio
- Go to Projects > Planning > By Project
- Switch to list view
- Add the newly created field to the view 'Task > Test'
The interface loops indefinitely because the server is stuck in an
infinite loop.
The loop is the following:
https://github.com/odoo/odoo/blob/89270ee39c0daa46ae8e2e3e57d7e512a1a65ddf/odoo/models.py#L5624-L5625
The root cause of the issue comes from an incorrect object ID added in
the list of fields to recompute. Since the method is set in a
`post_init`, the object `field` is different from `recs[field_name]`.
To prevent the error, we retrieve the object directly in the
`mark_fields_to_compute` method.
opw-2083852
closesodoo/odoo#38550
X-original-commit: 446cd3f3d610c9a872969f5d6843ccb6ebdb0d40
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Denis Ledoux <dle@odoo.com>
Fields created with Studio are case-sensitive, so we need to properly
quote the query.
opw-2083852
closesodoo/odoo#38544
X-original-commit: 2c50b663c7656b49e06804f30c5dc6d0dcff1af4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install timesheets and studio.
- In timesheets add a time of -0.5 (minus half an hour).
- Enter studio
- Switch to the Reports tab, and click Timesheet Entries.
Before this commit:
The time is displayed as 00:30.
After this commit:
The time is displayed as -00:30.
closesodoo/odoo#38542
Opw: 2036188
X-original-commit: b12374a266d4b5f2783d84e3a65b1c273e343a81
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Computed fields that depend on the context now have to be declared as such.
To reproduce the issue:
- go on the form view of any view
- update the arch of the view
- save
- click on action "reset view architecture"
- select hard reset
- no diff is shown
Expected: a diff should be shown
`arch_base` depends on `arch`, so even though no current flow actually uses it
when the context is changed, update its `depends_context` as well to be safe.
closes odoo/odoo#38536
Pr: #37363
X-original-commit: be658bb87a9e9dd84909e6e6d2cb9107b87a0d52
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Export a partner with country set to False, using EXCELL
- Try to import it with the xls file
Bug:
It raised: "No matching record found for name 'False' in field 'Country' at row 2"
opw:2080376
closesodoo/odoo#38379
X-original-commit: 01caf1e44f653a8e9bf5edd583bc2421905d9464
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- fix condition to correctly display company logo placeholder
- use avatar_grey on the "Contacts & Addresses" as white on white is not visible
- use `cover` to avoid excessive zoom on mobile
closes#38001closesodoo/odoo#38319
X-original-commit: 1210cb70bec421936c9d332b1347797bc83845cf
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Commit 5a9e1af64a has the unfortunate side-effect of crashing early
if for any reason the content cannot be decoded.
However, simply ignoring that the content cannot be decoded is no better idea:
some functions pipe the result to decoding functions that crash the same.
The resulting traceback pollutes the log with uninformative message such as:
binascii.Error: Incorrect padding 5 0.002 0.016
In case the content cannot be decoded (data corruption, or simply missing file)
we return a clean 404 instead, which is morally almost equivalent,
and is clean even from functions that depend on binary_content.
opw 2072586
closesodoo/odoo#38318
X-original-commit: a68f7e6e72dbfd44e14c2f293fa6dc6aa402308a
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Starting with Python 3, queries sent by psyocopg2 are stored as `bytes()` objects.
Logging those raw makes them appear unformatted, harder to read than in v10 or lower Odoo versions (i.e. `\n` instead of a raw newline character).
Decoding the query into unicode makes it easier to read in the logs.
closesodoo/odoo#38074
X-original-commit: 329accde2ed6d4dbfdde6d3d99d71e21d15396b7
Signed-off-by: Christophe Simonis <chs@odoo.com>
One2many fields can use it actually
closesodoo/odoo#38193
X-original-commit: 765566032e60252ec8fb7800200ed05addbfce65
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Raphael Collet