* When setting company_id on the res.partner, the parent might have had
a different company_id
* We should not consume res.partner's when creating res.user's but
creating new ones instead.
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
closesodoo/odoo#64885
X-original-commit: 61b0a859b76ebffe083e10b25e4af52702dfb61f
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.
closesodoo/odoo#64783
X-original-commit: 824a6515a528cd2b682c3d3504c0d27ed9427cdb
Signed-off-by: Raphael Collet (rco) <rco@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
closesodoo/odoo#64752
Before: the value is not removed
After: value is empty, translations are removed
X-original-commit: 3ef5e63f62f0f84d6e92cb55eb112ab2f2924faa
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
closesodoo/odoo#64715
X-original-commit: 8663f1e20727c315924bb20fc1de1accf3014c61
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
In order to clarify the purpose of the account_lock module, slightly
update its description.
Task id #2382740closesodoo/odoo#64559
X-original-commit: f15188907a63d3f50c80c8254e60b9f31a666c55
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit:
- The precision on geolocalisation fields were set to (16,5) which
caused rounding when data was comming from Goolge.
After this commit:
- The precision on geolocalisation fields are set to (10,7) which is
aligned with what Google does.
This precision of (10,7) is actually already used in the Sign App.
task-2426985
closesodoo/odoo#64401
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Currently, the signature of the admin defaults to 'administrator'. Odoo
does not take into account the actual name of the user. The onboarding
experience would be better if the signature was personalized
for the user.
SPECIFICATIONS
The default signature of the admin is his name (Mitchell Admin) instead of 'Administrator'.
Task-2416715
closesodoo/odoo#63914
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Most of the modules have a square icon but some don't. For instance, the
flags of l10n modules, or other third party modules.
Flags have very specific proportions, and we don't want them to be
resized when rendered.
While we could hardcode a square icon for each problematic icon, it
would be more manipulations, and the flags are already in the repo
without the right proportions; we don't want to duplicate binaries.
The many2many `module_ids` kanban field of the uninstall wizard has also
been updated to look more like the generic kanban view for the modules.
The classes in the kanban view of `fleet_vehicle_model_view_form` seem
to have been copy-pasted and are useless. It has been removed to reduce
future possible side effects of changing css.
closesodoo/odoo#56421
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Create a new cron job with a server action that sleeps 10 seconds, while
the cron is executing, triggers the cron. The trigger fails because the
implicit select performed by the foreign key on the ir_cron conflicts
with the lock acquired to execute the job.
When one access a record that references another table record with a
foreign key, a `KEY SHARE` lock try to acquire the referenced record in
order to prevent other transactions from removing it. The only lock that
conflicts with `KEY SHARE` is `UPDATE`.
When a job is acquired for execution, an `UPDATE` lock type was set on
the row. This ensure no other worker will select the same job but it
also prevent triggering the job as the trigger mechanism involve
inserting rows in the `ir_cron_trigger` table which have a foreign key
to the `ir_cron` table.
The `UPDATE` row lock was replaced by `NO KEY UPDATE` row lock. Just
like `UPDATE` the new row lock conflicts with all other locks BUT the
`KEY SHARE` lock that is acquired by foreign keys. The new lock type
still prevent multiple workers from acquiring the same cron
simultaneously but allow concurrent insertion of new triggers.
closesodoo/odoo#64424
Task: 2368911
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Since odoo/enterprise@937b9214cb 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#43880closesodoo/odoo#64538
X-original-commit: 572e05284c1a7587e989acebd43f3c07e7e99fb1
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.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.
X-original-commit: 2ccc735253405b03927e2b08eab57427e65e4050
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.
closesodoo/odoo#64433
X-original-commit: 25760348859f594abb796b5bc7b28f63e298cd53
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
When printing barcodes for a large amount of records, wkhtmltopdf will
make the same amount of http requests to the server in order to retrieve
barcodes. This can lead to performance issues or wkhtml to crash.
Fortunately, an already existsing qweb widget exists that include
barcodes images as inline base64.
With this commit, the web widget is a bit improved to accept attributes
for the generated image tag. Each option dictionary key starting with
`img_` will be converted into a tag attribute with the corresponding
value.
e.g.: `'img_alt': 'Barcode'` will result in `<img alt="Barcode"...`
The `alt` img attribute now defaults to `'Barcode %s' % value` with the
barcode value.
Also, the `quiet` reportlab option is also avalaible in the widget
options, as well as the `mask` option.
Finally, if the `symbology` option is not given, the widget defaults to
`Code128`. If `symbology` is set to `auto`, the action report will try
to guess the barcode type, based on the len of the value.
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
closesodoo/odoo#64320
X-original-commit: 851fe64f7789bb398383c22e3ebbaebb051791f6
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.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
closesodoo/odoo#64304
X-original-commit: e6ccdb397792db62c3b08d96435b3c1667c1aa9d
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.
closesodoo/odoo#64264
X-original-commit: b7676ec33172e6196b5fd1eda4df730ebf90eb6b
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose of the task, is to prevent users from inadvertently
creation/opening countries from country_id fields.
Countries should be managed from their dedicated menu item.
so in this commit, we have set both no_open and no_create to True
so user should not update and create a country from the many2X fields.
closesodoo/odoo#63773
Taskid: 2241677
Related: odoo/enterprise#15464
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*: web_editor, website
In stable versions, [1] was made as a fix to allow access to read
the colorpicker template for mass mailing users when they do not have
the read access right on ir.ui.view records.
This commit, for master, remove the need of using the confusing
read_template method by using render_public_asset instead (thus turning
the read into a render, which is the same for our colorpicker but might
be a change for potential custo). At the same time, this allows to
remove the read_template public method entirely.
Related to task-2412544
[1]: 8af75e00bdcda3d5ff4facd2f5f146e1d6bf79e4
closesodoo/odoo#64100
Related: odoo/enterprise#15580
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.
closesodoo/odoo#64117
X-original-commit: 9fe4fe404b73e9ab18ab6b3b913f075c64bb6954
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet (rco) <rco@openerp.com>
Reason: In Employees app, it is confusing for the first time users to see
both 'Employees' and 'Employee Directory' folder. Also, first user
is not assigned to any departments.
Solution: If the user can see the folder 'Employees', don't show
the folder 'Employee Directory'. Assign the first user to the
'Administration' department.
Task - 2377506
closesodoo/odoo#63038
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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
closesodoo/odoo#63999
X-original-commit: 0918b29ce765a159ba2b128bca9170f1230fdb78
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The call to reset() when simulating requests during HttpCase tests
leaves the test class into an inconsistent state. Indeed, the test
environment is no longer into Environment._local, and this may trigger
record cache errors, because new environments use a record cache that is
different from the test's environment.
As this issue only occurs in the context of unit testing, it is not
worth fixing on a stable release, because of the involved risk.
Instead, we modify the test so that the failing operation is made in
method setUpClass(), before any environment reset.
closesodoo/odoo#63730
X-original-commit: c8604df6e3eab4090ffcb4c3f311e72c8bceac7c
Related: odoo/enterprise#15439
Signed-off-by: Raphael Collet (rco) <rco@openerp.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: cd19c2d93db8911fe42802640ea32e5d87aadeec
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.
closesodoo/odoo#64005
X-original-commit: cf2b0a505c117a50a91fa022bc1d6bf1eb6d9f77
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
closesodoo/odoo#63912
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
closesodoo/odoo#63844
X-original-commit: d9097c2b6244154ea64142b5e8fd31cfdd34e66e
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Allow a False email as valid valid. Generate an email only if not given but
keep void values.
Ensure company_id / company_ids match, notably to ease creation of users
in a multi company test environment.
LINKS
Task ID-2421795
COM PR odoo/odoo#63677
X-original-commit: 21999058800957a08c5e129c527afe6b84812a8a
Display names of user, company_id and company_ids in order to better
understand what is failing. Otherwise a generic message does not really
help understanding the actual issue.
Add translation of new constraint. Also add translations of new modules
added recently.
LINKS
Task ID-2421795
COM PR odoo/odoo#63677
X-original-commit: 15d47bec4a6316dd6a873973572273c913801330
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.
closesodoo/odoo#63646
X-original-commit: 45422d56bce413b8577f1784e10dd22ede93c751
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 d8c5cc1335. 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 is much simpler than former versions, which are constrained by
the stable branch policy. We simply normalize the selection field's
name by ordering the group ids used in the name.
OPW-2394209
closesodoo/odoo#63462
X-original-commit: 399b4f1ceb31f560ce534ee8d9605ca43733f68c
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Nasreddin (bon) <bon@odoo.com>
This reverts commit d431f94c75 and even
upgrade the EcmaScript version further to ES10/2019.
The original commit mainly targeted the support of MS Edge
(pre-Chromium) and earlier versions of iOS 11.
As with the release of Odoo 14, we don't support either of those (MS
Edge only Chromium-based and iOS 12), the original restriction can be
lifted and again target EcmaScript 9/2018.
But furthermore, some features of ES10/2019 are already in use in Odoo
14+ (e.g. `Object.fromEntries()` used in SpreadSheet, PoS, WebEditor,
Website Sale...) and the only browser not supporting them is Safari on
iOS versions < 12.2.
As there is no drop of supported devices between iOS 11 and 12 and they
all have access to - at least - the latest revision of iOS 12 (cf.
12.5), it looks reasonable to target the latest revision only and not
the earlier ones. This policy also matches the "ever-green-browsers"
policy applied on desktop.
Note: please note that the tool (es-check) used for testing the
EcmaScript version targeted has for primary goal to catch unsupported
syntax and reserved keywords only, but not the actual APIs available for
a given EcmaScript version. (e.g. async/await keywords or string
literals are tested *but not* Object.fromEntries() or
Array.prototype.flatMap()).
References:
- https://kangax.github.io/compat-table/es2016plus/
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/fromEntries
- https://en.wikipedia.org/wiki/IOS_12closesodoo/odoo#63430
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.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
closesodoo/odoo#63318
X-original-commit: 0322febbea2cfd2d2fd7aedc42ef03632b17c967
Related: odoo/enterprise#15285
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In Belgium, the company registry and the VAT number (no country code) are identic.
The company registry field is not mandatory, but is needed to export the belgian Intrastat XML file.
Now:
- belgian company registry is set by default to vat number.
- missing company registry warning message redirects to company settings.
closesodoo/odoo#58047
Task: 2335088
Related: odoo/enterprise#15270
Signed-off-by: Laurent Smet <smetl@users.noreply.github.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
closesodoo/odoo#63259
X-original-commit: 47079f67f586adf45da15fc98dbc81571f7a9100
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When installing/upgrading a module with broken xml views, the module
installation fails with an error message that should help the developer
locate and correct the error.
Before this commit, a 3-level traceback was thrown at the developer:
1. The initial ValueError containing the original error message and some
view context information.
2. The noisy re-cast of the ValueError to a ValidationError with no
additionnal information.
3. An additionnal re-cast of the exception to add the original source
file path plus the entire XML source code that failed to be parsed.
We argue the error contains too much noise as developers are mostly
interrested in correcting their erronous tag of their view, they are not
interrested in `ir_ui_view` internals.
The new exception report is much less talkative, the two tracebacks from
`ir_ui_view` are logged at the `DEBUG` level. The new exception still
contains the original error message with some context on the view record
and the original source file path but it only show 5 lines of XML around
the erronous tag.
closesodoo/odoo#62757
Task: 2366612
Related: odoo/enterprise#15104
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Create a model as follow:
class FooModel(models.Model):
_name = 'foo'
bar = fields.Char(compute="compute_bar")
@depends('bazz') # wrong dependency, bazz does not exist
def compute_bar(self):
for rec in self:
rec.bar = "Babar raconte des beaux bobards."
Uppon -u foo_module, a ValueError is rose for the invalid dependency
with the following message:
> Field foo.bar cannot find dependency bazz on model foo.
We had feedback the error message was not very clear to some users,
the new error message is:
> Wrong @depends on 'compute_bar' (compute method of field foo.bar).
> Dependency field 'bazz' not found in model foo.
closesodoo/odoo#62328
Task: 2366612
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Introduce a way to schedule the execution of cron jobs *soon*. Triggered
jobs are included in the next execution batch.
Heavy refactor of the `ir.cron` model so the various parallel queries
use the (not so new) `SKIP LOCKED` postgresql select option which skip
rows that are locked instead of throwing an exception like `NOWAIT`
would do. Various methods has been renamed and the overall selection,
execution and update of job records have been re-architectured.
The cron workers can now to wake up early via a notification on the
`cron_trigger` channel of the meta `postgres` database.
closesodoo/odoo#62124
Task: 2368911
Signed-off-by: Raphael Collet (rco) <rco@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.
closesodoo/odoo#63045
X-original-commit: c36aa16c2cc431a1e3b3bb7047dbae4fcac13946
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+)\.([^ ]+)`.
closesodoo/odoo#63017
X-original-commit: 52bf0e331fb9230423b76b9014bb13d490930e76
Related: odoo/enterprise#15189
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
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#59980closesodoo/odoo#62989
X-original-commit: 3d1c7231a080eebb4f6a7d56cbfa5721bf76befd
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).
X-original-commit: c4a94bc99285aba085badeb1a41e8fe04562ef50
This is a minor issue, but determinism is better than non-determinism.
closesodoo/odoo#62904
X-original-commit: 1b0869554d8755f8fdeb73dd2aa2ae7426522e84
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
william