| Age | Commit message (Collapse) | Author |
|---|
|
Configure an email server and create a login account with a space like
"foo bar". In odoo configure an Outgoing mail server using that account,
there is an error because the username is misconsidered invalid.
The errors resides in the IDNA implementation of Odoo, we try to split
the username to get a login and a domain in order to encode the domain
using the ponycode algorithm. In case the username was not an email
adress but just a single name, the single name was mistaken for a
domain. As domain cannot have spaces, an error was thrown.
opw-2419024
closes odoo/odoo#64864
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
|
|
The call model.browse('xxx').exists() should not return the record.
Instead, it should fail as the string 'xxx' is not a valid ID.
closes odoo/odoo#64779
X-original-commit: 824a6515a528cd2b682c3d3504c0d27ed9427cdb
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
commit 31e1322b40ab33bf81d4c000f2b2a3f3eb8d0958 is allowing the
customer to increase is decimal accuracy for currency without
consequences but triggering issue upon lowering it if entries
already exist.
+ Remove the redirection to the support.
Let's ensure that the behavior is consistent and the users are
warned on first modification. To do so, adding an alert msg
in addition of the blocking message in case of lowering the decimal
accuracy after already creating accounting entries.
opw-2428857
closes odoo/odoo#64344
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
cache_value could be empty string rather than None. I'm not sure why it was
different before.
STEPS:
* install an app that adds menu Products (e.g. Sales)
* activate second language and switch to it
* create new product, set some value to field description ("Internal Notes"),
save
* click edit, remove description, save
BEFORE: the value is not removed
AFTER: value is empty, translations are removed
closes odoo/odoo#64591
X-original-commit: 32465251e19efe63d2015b799b8de9b4e8db438f
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
|
|
The emails sent via Odoo reveive a poor score on various spam tools,
the reason being the missing `MIME-Version` message header. This header
inform what MIME version is in use in the message. Even if there is only
one standardized version of MIME (1.0), the header is mandatory.
Citing [rfc2045] "MIME: Format of Internet Message Bodies" section 4:
> the MIME-Version header field is required at the top level of a message.
Setting the charset on the envelop forces the EmailMessage API to also
include the missing `MIME-Version` header.
[rfc2045]: https://tools.ietf.org/html/rfc2045#section-4
Task 2393865
closes odoo/odoo#64651
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
|
|
|
|
Since odoo/enterprise@937b9214cbe92a6e0c0f14acb6c9bfebf9125a06 module
'studio_customization' has a dependency on module 'web_studio', in order
to automatically remove customizations when uninstalling 'web_studio'.
As a side effect, this marks 'studio_customization' to be upgraded when
'web_studio' is upgraded. An error is logged, but the module stays in
state `to upgrade`, thereby blocking the execution of cron jobs.
The fix simply adds an explicit (though not very elegant) condition on
the module name to filter out module 'studio_customization' when marking
modules in method `button_upgrade`.
A cleaner fix would be to use the `imported` flag, but we don't want to
risk breaking existing features in stable and will be done in master
instead.
Slightly linked to closed #43880
closes odoo/odoo#64534
X-original-commit: 572e05284c1a7587e989acebd43f3c07e7e99fb1
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
|
|
In order to clarify the purpose of the account_lock module, slightly
update its description.
Task id #2382740
closes odoo/odoo#63394
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
|
|
Consider a model with a field F and a computed editable field G that
depends on F. Assume we open a form view, and both F and G have a
default value. The first onchange should return F and G with their
respective default values. In other words, the field G should not be
recomputed even if its dependency F was assigned a default value.
The use-case that showed the issue is batch payments. When adding a new
payment in the one2many field of a batch, the new payment should use the
batch's payment method by default. The default value for the payment's
method is assigned by context on the one2many field in the view. Before
this patch, the new payment's method was given by the computation of the
field, and its default value was ignored.
Side note: another test was fixed, but that's because the test was not
consistent with the way Odoo 14.0 manages defaults and onchanges.
|
|
Consider a constraint method with two fields: a normal field, and a
field with an inverse method. When calling write() with both fields,
the constraint method should be invoked once.
closes odoo/odoo#64411
X-original-commit: 3b39d7efa94484b3bbf04fce756394a7e424f625
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
|
|
Steps:
- Install accounting
- On the dashboard, try to upload an "encrypted" PDF like this one https://launchpadlibrarian.net/24827090/DS-0157.pdf
Bug:
Traceback:
PyPDF2.utils.PdfReadError: file has not been decrypted
Explanation:
In 13.0, these errors were caught in a catch all `except` as shown here: https://github.com/odoo/odoo/blob/4e089041252c25cc197a30f9e285d82f7162d809/addons/account_facturx/models/account_move.py#L303-L328
From this SO comment: https://stackoverflow.com/questions/52047944/pdfbox-extracting-blanks-from-pdf-encrypted-with-no-password#comment91054285_52047944
> A PDF can be encrypted with two passwords: a user password and an owner password. When a PDF is encrypted with a user password, you can't open the document in a PDF viewer without entering that password. When a PDF is encrypted with an owner password only, everyone can open a PDF without that password, but some restrictions may be in place.
From time to time, we get a PDF encrypted with an owner password. The
content is still readable, but PyPDF2 fails because it thinks the PDF is
encrypted. With this fix, we try to unwrap the PDF by providing an empty
user password. This way, PyPDF2 thinks the content is now decrypted.
However, PyPDF2 only supports decrypting versions 1 and 2 of the
encryption implementation. If the version is different, we skip reading
the attachments and carry on to allow the user to upload the document.
opw:2375993
closes odoo/odoo#62557
Signed-off-by: backspac <backspac@users.noreply.github.com>
|
|
Issue
- add a new language with locale code KUR (for Kurdish)
- print any report with a datetime on it (RFQ for example)
Cause
Babel (version < 2.7.0) does not handle locale "KUR".
Solution
If wrong locale or not managed by Babel, try to fallback
on server default locale.
If still wrong locale or not managed, then fallback on "en_US" as locale.
opw-2416482
closes odoo/odoo#64301
X-original-commit: 0276c3ef20c79e7061ea5b92aafd6dea190c6a27
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
|
|
|
|
This takes a former patch one step further.
Assume you recompute a field on two records, and the computation assigns
the first record but not the second one. Before this patch, the
recomputation process was accessing the field on both records. When
accessing the first record, both records are recomputed, and the value
of the first one is found in cache. When accessing the second record,
no recomputation is made (it has been done already), and the cache is
empty. The field is thus fetched from database, and this crashes because
of insufficient access rights.
This scenario was causing some obscure nondeterministic crashes in
tests. The nondeterminism comes from the choice of the environment for
flushing (it should not be in superuser mode); the order of records in
the set to compute; the order in which records are assigned in the
compute method; the fact that the compute method should assign some
records and some not.
The fix consists in adding a method that processes pending computations,
without doing anything special for unassigned records. The method is
used in field accessors (__get__ and mapped) and in method recompute().
The access error is gone because the recomputation no longer tries to
get the value of a field to compute.
closes odoo/odoo#64250
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Some modules may be removed by the upgrade scripts with the help of the
ORM and are done in `end` scripts.
This is the case for uninstalling the themes which use the `_theme_remove`
method [1].
[1] in 12.0: https://github.com/odoo/odoo/blob/e2084a4356f63249920d8c777e92f1710be8b5a6/addons/website_theme_install/models/ir_module_module.py#L337
closes odoo/odoo#64216
X-original-commit: e5ab5410dbc006fc4bcdd21e603026483bf5d360
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
*: website, base
The normal flow to render a template is now to use `render_public_asset`
which bypasses the read access rights if the user matches the groups
the view declares.
For public users, we still cannot use that as they do not have access
to calling model methods at all. The route `public_render_template` is
thus still needed, but it should use the `render_public_asset` util. In
master, it will only rely on it but as a stable fix, we still need to
use the whitelist as we cannot change the related views' group.
This commit also adds deprecated comments to the read_template method
which has been removed in master.
Related to task-2412544
closes odoo/odoo#64137
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Fixes 3a6ac95 that ignores computation of recursive stored fields during
creation of records.
The problem happens when we have:
* a recursive stored computed field
* an `api.depends` of this field which is a relation to another record
When this "another record" is created and should recompute the recursive
field, it is ignored.
closes odoo/odoo#64031
X-original-commit: 79634eefb225a7aaa6c3c26af126fb69078c22ac
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet (rco) <rco@openerp.com>
|
|
closes odoo/odoo#63931
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
|
|
Steps to reproduce the bug:
-Let's consider two vendor bills VB1 and VB2
-VB1 and VB2 have both a PDF in attachment P1 and P2 respectively (the original bills from the suppliers)
-Let's consider that P2 is encrypted
- In the list view of vendor bills, select VB1 and VB2 and print original bills
Bug:
An error was raised because it is not possible to merge P2 with P1 as P2 is encrypted.
opw:2389679
closes odoo/odoo#63990
X-original-commit: 0918b29ce765a159ba2b128bca9170f1230fdb78
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
When performing the onchange for the first time on a new record, if a
field has a default value, it could be two times in the `todo` field
list to compute.
closes odoo/odoo#63983
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
those field sizes were deleted from orm definition in 2014 https://github.com/odoo/odoo/commit/026e38b48f3963aed08bba4e76a0a796d662f6a4
STEPS:
* set manifest's summary attribute to a long string
* create empty database
BEFORE: error
```
2020-12-28 10:44:51,325 1 ERROR ? odoo.sql_db: bad query: UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')
ERROR: relation "ir_module_module" does not exist
LINE 1: UPDATE ir_module_module SET state='installed' WHERE state IN...
^
2020-12-28 10:44:51,325 1 ERROR ? odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 338, in load_modules
odoo.modules.db.initialize(cr)
File "/opt/odoo/custom/src/odoo/odoo/modules/db.py", line 63, in initialize
info['sequence'], info['summary']))
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 173, in wrapper
return f(self, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 250, in execute
res = self._obj.execute(query, params)
psycopg2.DataError: value too long for type character varying(256)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 88, in new
odoo.modules.reset_modules_state(db_name)
File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 558, in reset_modules_state
"UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')"
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 173, in wrapper
return f(self, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 250, in execute
res = self._obj.execute(query, params)
psycopg2.ProgrammingError: relation "ir_module_module" does not exist
LINE 1: UPDATE ir_module_module SET state='installed' WHERE state IN...
```
AFTER: database successfully created
---
opw-2415057
closes odoo/odoo#63907
X-original-commit: 2a44e233deffd17460e0e9a8f8225602a28c24a6
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
|
|
What are the steps to reproduce your issue ?
1. Install website_blog
2. Go to website and add a new blog post
3. Remove the block content
4. Save and go to Blog page
What is currently happening ?
Crash:
Template fallback
An error occured while rendering the template website_blog.post_teaser
opw-241937
closes odoo/odoo#63840
X-original-commit: d9097c2b6244154ea64142b5e8fd31cfdd34e66e
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
|
|
|
|
This fixes an issue that occurs when marking fields to compute in the
following situation:
- it occurs before the actual modification,
- a relational field is marked to compute,
- the same field is traversed to inverse some dependency.
When the marking occurs after the modification, the traversal of the
field should actually recompute the field. However, if the marking
occurs before the modification, the inversion of dependencies must be
based on the current value of the field. This is the case with method
unlink(): we call method modified() to mark the fields that currently
depend on the records to be deleted, and the fields must be computed
only after the deletion!
X-original-commit: 3a6ac95ddf6a8719aa714a83fc339ba838c3811d
|
|
When a form view is opened, the first call to `onchange` should always
compute fields, even if their dependencies have no default value. Make
sure it is the case for main records, and for records inside one2many
fields. The latter case was actually not working as expected.
closes odoo/odoo#63627
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
To reproduce this issue, install the module "Accounting" in English,
then switch language to Dutch, and go to a user's form. The selection
field for accounting groups is missing from the users' form view.
The source of the bug is the special case introduced for accounting
groups in d8c5cc1335806d379134866262840fcafb05b643. The groups in that
selection field are not totally ordered, and the non-ordered elements
are de facto ordered by name, which is a translated field! In the
example above, the English version uses the field name
`sel_groups_22_23_24_25` while the Dutch version uses the field name
`sel_groups_23_22_24_25`. Because the first one is used in the form
view, and it is not found in the model's documented fields (which uses
the second one), the field is discarded from the view.
The patch modifies the override of method `fields_get()` to consider all
the possible names for that selection field, and returns them all.
OPW-2394209
closes odoo/odoo#63423
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Consider a model M with a one2many field with comodel L, such that
deleting records in M cascade-deletes records in L. Import a bunch of
records in M with one2many lines having specific external ids. Delete
the imported records: the database cascade-deletes the corresponding
lines, but the lines' external ids are not deleted. Now re-import the
same records: this crashes, because the import process finds the lines'
external ids and tries to update the deleted lines!
The fix consists in checking that an external id's record actually
exists. The existence check was removed for performance reasons by
https://github.com/odoo/odoo/pull/26496. We reintroduce it by resolving
the external id with a join on the model's name, which checks the
record's existence faster than an extra query. This patch allows to
re-create the imported records' lines.
Another patch is necessary to actually update the external ids that
refer to deleted records, otherwise they remain dangling, and importing
the same records again duplicates the lines, because their external ids
do not match any existing record.
OPW 2409649
closes odoo/odoo#63077
Related: odoo/enterprise#15202
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
When you mark an crm.lead as "won" using the "mark as won" button, the user
will be shown a rainbowman under certain conditions. This happens notably
when you win your first lead.
This commit fixes the 'ir.actions.act_window_close' model to allow the
'effect' key within its readable fields (even if it's not a real field) which
is in turn picked up by the web client to display the infamous rainbowman.
At the same time, we add the tour that is testing the rainbowman of the crm app
in the test suite, since it was missing and never actually executed by the CI.
Some fixes were also necessary to make the test run properly.
Task ID-2394745
closes odoo/odoo#62420
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
The hungarian time format is not %H.%M.%S, but %H:%M:%S
closes odoo/odoo#62929
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
|
|
Despite being part of the requirement.txt, xlrd apparently was still
optional-ish, and absent from some environments like the iotbox.
Restore this by only monkeypatching xlrd if it's actually present.
closes odoo/odoo#63025
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
The parsing of external ids was made with the regexp `(\w+)\.([\w-]+)`.
This regexp is inadequate for external ids that contain non-alphanumeric
characters like. We have such a use-case with the selections of field
`rating_operator` in module `sale_subscription` that uses the values
`">"` and `"<"`.
The fix consists in replacing the regexp by `(\w+)\.([^ ]+)`.
closes odoo/odoo#62976
Related: odoo/enterprise#15182
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
X-original-commit: 745564629748dbce10156fc164d3f126e8630999
|
|
Python 3.9 has 10 new bytecode instructions, for now this commit adds 8
* CONTAINS_OP / IS_OP: moved out of COMPARE_OP which is now only used
for *rich* comparisons (bpo-39156)
* JUMP_IF_NOT_EXC_MATCH: also moved out of COMPARE_OP for the sole
purpose of testing exception types
* RERAISE and WITH_EXCEPT_START (bpo-32949) used to simplify the
context manager bytecode, but RERAISE was then used for
try/except/finally, we don't support context managers in safe_eval
so we don't care about the latter
* LIST_TO_TUPLE, LIST_EXTEND, SET_UPDATE, DICT_MERGE and
DICT_UPDATE (bpo-39320) updates to unpacking (* and **) in various
contexts
* LIST_TO_TUPLE we're skipping as it's only used when calling a
function with two `*arg` parameters (aka `foo(*a, *b)`)
* SET_UPDATE is used for set literals of 3 or more items or
unpacking ({*a})
* LIST_EXTEND is used in the same cases as well as function calls
with unpacking
* DICT_MERGE is used for function calls with `**kwargs`
* DICT_UPDATE is used when unpacking in a dict literal (`{**kw}`)
See odoo/odoo#59980
closes odoo/odoo#62498
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Old naming has been deprecated for a long time, it's been removed
entirely in 3.9 (bpo-37804).
|
|
|
|
This is a minor issue, but determinism is better than non-determinism.
closes odoo/odoo#62899
X-original-commit: 1b0869554d8755f8fdeb73dd2aa2ae7426522e84
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
|
|
In case a user has installed a module where the code becomes unavailable or during migration a module was removed and needs to be removed after migration it is impossible to uninstall the module from a database still holding the fields or the models.
In order to disable prefetch based on information from the database it is needed that the module and models of the unavailable module are initialized with related fields and models.
closes odoo/odoo#62892
X-original-commit: e4a1121e572d07cc720ede8c1b1116d4f1d7ae98
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Upon the first call to `onchange`, the `values` dict is filled with
default values. But the fields without a default are left unassigned.
This allows to compute fields when accessing them, but non-computed
fields will ask again for their default value, which is a waste of time
because we know they don't have one. This may even be a performance
issue on forms with many fields.
Fix this issue by completing `values` with falsy values, and consider
the fields with some initial value (given or default) as the assigned
ones for triggering onchanges. This explicitly triggers the computation
of fields that depend on fields with some initial value, without forcing
them to `False`.
Also avoid accessing x2many fields on the record in `snapshot.diff()`.
Enable the prefetching by simply putting the right value in cache.
closes odoo/odoo#62627
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Bug
===
Sometimes, the registration testing tour failed.
The bug can be semi-deterministic if we add a "sleep(1)" in the endpoint
"/event/<event>/track".
Reason
======
The reason for that is the service worker. It will pre-fetch all the
links in the page (see "prefetch-pages"), so for the "Online Reveal"
we will pre-fetch ~100 pages... If the server is slow, it can cause
issues.
If one endpoint takes some time, all other HTTP requests done by the
service worker will be waiting for it.
So, at the end of the testing tour, the service worker will continue to
make HTTP requests (because it makes the request sequentially) and so
some threads will still be created after the tour.
Even if "_wait_remaining_requests" is called to wait those threads, as
the service worker is still running, it will still continue to make HTTP
requests, creating new threads...
Fix
===
The solution to this issue is to kill the service workers of the browser
when we stop the tour before waiting for the end of the "HTTP request
threads".
Task 2381066
closes odoo/odoo#62248
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
This fixes the issue introduced by revision fd50ba9fb838067fab0b920470cf79b9c94d785c
The way computed fields are invalidated depends on the order of the dict
passed as a parameter to method onchange(). This causes some unexpected
behavior when dealing with computed editable fields: the user loses the
value in that field because of the onchange.
Explanation: during the onchange, the modified field is cached by
record._update_cache(changed_values, validate=True)
If the field is a one2many, 'value' contains an update command for each
modified line. Because of 'validate=True', the assignment triggers
field computations on the lines, which are already handled by another
call to onchange(). In case anything on the parent model modifies some
line, the whole one2many values are returned to the user, and
accidentally recomputed fields show up in the interface.
closes odoo/odoo#62060
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
|
|
Before this change, the apikeys' ``_check_credentials`` override would
hard-check the ``'interactive'`` key. This turns out to be less than
ideal for compatibility with older code which might not properly
forward the environment (or might call ``_check_credentials`` from a
non-override and pass in an empty env) as it straight crashes.
Update the override to assume an interactive login if the information
is missing (as that seems like the more secure option: it ignores
apikeys and takes 2FA in account if enabled). Also trigger a warning
if the key was missing from the environment, such that the maintainer
hopefully takes a look at the issue.
Also allow a ``user_agent_env`` of ``None``, this will also trigger
the warning so seems OK.
closes odoo/odoo#62664
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
This fix makes sure we can still remove a company from a contact linked to a user.
Related: https://github.com/odoo/odoo/pull/62418
opw:2391464
closes odoo/odoo#62585
X-original-commit: 59413ad88a97b3221526c2b560178a0f94ddee05
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
|
|
|
|
Courtesy of Transifex's translators for reporting bad/unclear sentences.
closes odoo/odoo#62539
Related: odoo/enterprise#15032
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
This reverts commit 80902bee453cf485906bb07be6af9072aee2e76f as the
backport to 12.0 did not apply.
closes odoo/odoo#62520
Related: https://github.com/odoo/odoo/pull/62418
X-original-commit: d6b50b76432d620a86f3a1c63523cb4122b95709
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
|
