Currently in 13.0 when creating a new model through studio and convert
the x_name field to a computed fields with a dependency set on a
custom field from a native model, user get a Key_error when upgrading
or installing a new module
due to the custom field with an invalid depends raise error through a
transitive dependency.
The loading of the registry completely fails,
because the loading of the field custom_field raises a `KeyError` exception
in `def transitive_dependencies` @ `dependencies[field]`
it happens here because the custom_field was skipped at
`dependencies[field] = set(field.resolve_depends(model))`
task - 2366502
closesodoo/odoo#61663
X-original-commit: 92f6908bae4a6678f76a3ce9e29ac3907803ceb2
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
In some cases, the edit mode on the production form view is not already
rendered when hte tour try to write '1' in the qty_producing field. This
lead to a fail of the Main Flow Tour.
This commit specifically trigger the input tag to be sure the text will
be inserted in edit mode.
closesodoo/odoo#61541
X-original-commit: 426a4306c911de2a47bd804dde0d67aa19a22b67
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This fixes a very obscure bug that happens on workers serving multiple
databases. Consider two databases A and B with the same model M, that
does not have a field 'name', but has a custom field 'x_name' only on
database A. The bug can be reproduced with the module 'account' and its
model 'account.register.payments'.
Assume the server loads a registry for database A. In that registry,
the model M uses 'x_name' as its _rec_name, and the field 'display_name'
on model M determines its dependencies to be the field 'x_name'.
Now assume the server load a registry for database B. In that registry,
the model M has no _rec_name. However, an optimization reuses the field
'display_name' for the model M on the registry of A. The field's
attribute 'depends' is equal to the tuple ('x_name',). When the ORM
tries to resolve the field's dependencies, it does not find the field
'x_name' on M and crashes.
In order to avoid this situation, we forbid the usage of 'x_name' as
_rec_name on non-custom models.
OPW 2349238
closesodoo/odoo#61534
X-original-commit: 731e676fa8a9f7bdc6a66056c124c3b39a0800ad
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When you make a payment, if a supplier have multi bank account, the bank name is not show in the selection. With the bank name it is more simple to find the good bank account.
closesodoo/odoo#51930
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Commit [1] made a stupid mistake forgetting nodes with the t-field
instruction can also have the position attribute in case of inheritance
without xpath node.
... It did not crash because there actually is no case of it in the
current codebase, but this is used by some custo on our prod however.
The test introduced by mentioned commit has been extended to crash,
should this specific case be broken again.
[1]: https://github.com/odoo/odoo/commit/92ef3b2dd4655913198d10d06598b799fdcae6d0closesodoo/odoo#61288
X-original-commit: b05c7f1e8054be4e74289ac366e0ddcc7da2228e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Homepage tour starts with a very generic step 'drop snippet'
So, you can be in the middle of another tour and see the step of homepage tour.
This doesn't fix all cases, but make conflict less frequent.
E.g.
go to step 4 of tour event
click on save (before doing the step 5)
click on edit
Element is no more dirty (because save before step 5) so the step 5 not visible,
Tour with higher sequence (== lower priority) become visible. (e.g.: homepage)
Forward-Port of bca6cf2693d38c76b1af08398a3125bb16b59c15
closesodoo/odoo#61157
Related: odoo/design-themes#416
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Previously, in multiple modules, long names would result in an overflow of text.
With this commit long texts should appear like this: [aaaaa...] instead of
going out of their boxes.
Various views are updated, depending on which fields we wanted to prevent
from overflowing and the probability they do so.
Task ID-2325219
PR odoo/odoo#57713
PR odoo/enterprise#13226
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The access rights of a model was checked but not the records themself.
In case a user has access to a model but not to a specific record, he
should not be able to execute a server action on it.
Correct the ir.rule on private partners to be also verified for other
operations than read.
While it was not possible to actually write on it (due to side effects
of ORM where write implies a read operation),
check_access_rule('write') was working on a private address
closesodoo/odoo#61253
X-original-commit: b0028c05d6ba9c67f16992ddb446eea6a854d099
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Consider some model A that "_inherits" from model B, which itself
"_inherits" from model C. Also consider a field F on model C, which is
inherited by both models B and A. Now create a record from model A,
with a given record for model C, no record for model B, and a default
value for field F. This should create a record in A, connected to a new
record in B, connected to the given record in C, and the default value
should be ignored, as a record from C is given.
Before this commit, the given record in C is modified with the default
value for F. The default value is considered because no record is given
for B, and that value is used to modify the given record in C. The fix
consists in discarding default values by considering potential ancestor
records when parent records are not given.
closesodoo/odoo#61165
X-original-commit: b83dfaa2c9bcc6bc7f8df19ed0e442554816709b
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The xpath branding of a node which followed a t-field node which was
added by an inheritance view was not correct. E.g.
View 1:
```
<hello>
<world id="1"></world>
<world t-field="a"/>
<world id="2"></world>
<world id="3"></world>
</hello>
```
View 2 inheriting view 1:
```
<xpath expr="/hello/world[3]" position="after">
<world t-field="b"/>
</xpath>
```
So the result is:
```
<hello>
<world id="1"></world>
<world t-field="a"/>
<world id="2"></world>
<world t-field="b"/>
<world id="3"></world>
</hello>
```
Now the xpath branding of world id="2" was /hello[1]/world[3], which
is correct.
But the xpath branding of world id="3" was /hello[1]/world[5] which is
incorrect as it should be /hello[1]/world[4] (as related to the
original view). This was because inherited t-field did not carry any
information they came from inheritance (as "normal" nodes would).
The side effect of this was that the incorrectly marked node was not
possible to edit (and made the editor crash on save).
closesodoo/odoo#60976
X-original-commit: 07cf2b9520fc6c79a9a7ca39929bda0bfbe85e3a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The randint generator generated always `None`
because the `return` was forget in method of `populate.compute`.
- Add a test for the randint tool, and fix the issue.
- Change the documentation of `_populate_factories` to be more
explicit about the custom generator.
closesodoo/odoo#61076
X-original-commit: 09d2ddecaf4fc6474c96acf1f4a12de4789caef8
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
On mobile, when tours are run on changing month, the "Register Payment"
step often fails with the following error:
AssertionError: The test code "odoo.startTour('main_flow_tour')" failed
Tour main_flow_tour failed at step Register Payment (trigger:
.o_statusbar_buttons button:enabled:contains('Register Payment'))
Please note before going further:
* The main flow is a tour. The tour manager waits for the trigger and
the extra trigger to be reachable before executing the step.
* On mobile the status bar buttons are wrapped in a dropdown.
So the stepUtils.statusbarButtonsSteps is composed by two actions:
1 - Open the dropdown if present.
2 - Click on the button.
Before this commit, the extra trigger doesn't look like the best one:
when this tour is executed during month change, the account
module has to perform some heavier (and longer) processes.
When the "Validate" call button is made (previous step), a lot of RPC
are made and, usually, the previous extra trigger works fine.
But for some reasons, the _renderStatusbarButtons is called
between the two steps in the statusbarButtonsSteps.
So this is the flow:
- Running the tour until...
- Click "Validate" button (this generates a bunch of RPC).
- Open the dropdown.
- Some RPC respond, which refresh the "state" and call _renderStatusbarButtons
(dropdown is not open anymore).
- Try to click on "Register Payment" => BUG
(button is present but not visible, so unreachable).
After this commit, the extra trigger is changed to force waiting for
the RPC that change the "state" and call _renderStatusbarButtons
before executing the "Register Payment" step.
closesodoo/odoo#61085
X-original-commit: dacc1703c486c8affb44df679ab5e8e2ba724867
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
The res company and res partner company forms are very similar, if not
for a few field placed differently.
This will make them both more similar by moving around a few fields in
the res company form view.
task id #2352554closesodoo/odoo#59950
Related: odoo/upgrade#1884
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In the odoorc file, set a `logfile` path, but disable it via the command
line with `--logfile=`. The logs are output to the logfile configured in
the config file instead of stdout.
Parsing `--logile=` yield an empty string which was interpreted as
argument not set and skipped.
Closes#3852closesodoo/odoo#60992
X-original-commit: bae0d99b8d654283be4d265e3b40a83247a2299c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
In order to ease the usage of lazy translation, add the possibility to
add the _lt objects together and with strings.
Adding two _lt objects together or to a string will execute their
translation, so these operations still must be done once the user's
language has been defined.
For example, this is now possible:
MESSAGES = {
1: _lt("Hello, world!"),
2: _lt("Lorem ipsum"),
}
def get_text(code):
return _("Text is: ") + MESSAGES[code]
closesodoo/odoo#60844
X-original-commit: c4596664e5514018c565eaf14b93e000d972bd30
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
In current Debian version (0.19) ofxparse gives the following warning:
ofxparse/ofxparse.py:40: DeprecationWarning: Using or importing the ABCs from 'collections'
instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
return isinstance(candidate, collections.Iterable)
Since we can't do anything about it, we filter it for now.
ofxparse already fixed it https://github.com/jseutter/ofxparse/issues/155
A Debian bug report has been opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973055closesodoo/odoo#60880
X-original-commit: 00497c03db080914fed81dc3fc66fa5d45f65a4e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Thomas Dieuzeide <tdi-odoo@users.noreply.github.com>
The custom vat index name matched the name that the system uses for automatic
indexes (when a field has `index=True`).
But the `vat` field was created with `index=False`, and this means that the
ORM would execute a `DROP INDEX IF EXISTS res_partner_vat_index` when updating
any addon that touches the `res.partner` model. Since this model is so
ubiquitous, this resulted in a ton of unnecessary `DROP INDEX` + `CREATE INDEX`
queries when updating any database.
What's even worse is that dropping or creating an index needs a complete
semaphore lock of the whole table, so if you're updating a high-traffic HA
production instance while it is running, you have a very high rate of concurrency
failures, because almost everybody is going to be using the `res.partner` model
in some way almost all the time.
A deeper investigation reveals that the index itself was useless. It was added in
a6e1eb9 and apparently meant to be used for optimizing name_search(). But even
though a6e1eb9 modified name_search(), it did the substitution in Python[1], so
in practice the database had no way to recognize the pattern and never used the
index. The specificity of that index makes it useless for other cases too, so it
can simply be dropped to save space.
Further, considering that the `vat` field is a common search criterion, it
actually makes sense to enable a normal index on that field, by setting
`index=True`. Neither dropping the index nor creating the default one has any
impact on existing databases, so it's safe in a stable series. A new
installation or a forced update will be necessary to benefit from the changes.
~~Finally, because the bad custom index had the same name as the regular one, an
upgrade script is foreseen to drop the old one before letting the ORM re-create
it properly.~~
Fwd-port note: the upgrade script and version bump were reverted as a
consequence of the unforeseen consequences in #60771.
1: https://github.com/odoo/odoo/blob/a6e1eb9f0ad285fac7d0ca0b9f89f046d78ec9c7/odoo/addons/base/models/res_partner.py#L710
@Tecnativa TT26303
Closes#60346
See also: #60771closesodoo/odoo#60862
X-original-commit: 2f4a7de3d25cec36ac3b85e3f33122728346c206
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this patch, adding a field on a custom model discards all
automated actions on that model. The explanation is relatively simple.
When models are set up in the registry, the classes of custom models are
dropped then recreated. Given that automated actions are implemented as
monkey-patches on model classes, the setup of models simply loses those
monkey-patches, which explains why they stop working on custom models.
The fix introduces an `_unregister_hook()` method, that is expected to
clean up what has been done in `_register_hook()`. When the registry is
ready (i.e., not being loaded), the setup of models first invokes
`_unregister_hook()` on models, proceeds with the setup, and finally
invokes `_register_hook()` to reinstall the hooks.
OPW 2362308
closesodoo/odoo#60833
X-original-commit: 67152bf82da2674179297d32e4cec9dd534fa0c9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Zip cannot be required if not in format address.
It will break ecommerce, because the customer cannot
validate the adress because zip code is not displayed but required.
Fix case in JS where field is not display to avoid traceback.
This commit closes#58950closesodoo/odoo#60704
X-original-commit: 2d31892081a48c521357cef974ea23fc9228a39e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Using or importing the ABCs from 'collections' instead of from 'collections.abc'
is deprecated since Python 3.3, and in 3.9 it will stop working.
closesodoo/odoo#60728
X-original-commit: b6907f8fad3b27400a4c2e4a046ed0f02869f863
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Thomas Dieuzeide <tdi-odoo@users.noreply.github.com>
Cron holds a lastcall field and context key allowing to compute an accessible
range of processable records based on last execution. This lastcall value is
updated when cron runs automatically. Manual call currently does not update.
It makes sense to do the same update in manual call than with automated calls.
Moreover lastcall context key is also updated. It is used notably in calendar.
Otherwise only mails linked to "today" are taken into account, leading to
reminder issues.
Task ID-2331999
closesodoo/odoo#60559
X-original-commit: 9d1909f228aef664669152c16091a188377ee8bd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Change country to Mexico
- Install 'CRM'
- Install 'l10n_mx_edi'
- Try to open any lead in 'CRM'
The same error is present in l10n_pe
Cause
'l10n_mx_edi' and 'l10n_pe' use 'res.partner' in 'ir.ui.view'
Solution
Adding a condition to prevent '_fields_view_get_address' in 'format.address.mixin'
from rewritting the model and let ir.ui.view determine it
opw-2361875
closesodoo/odoo#60463
X-original-commit: 3229239c2a738cc99820dba0fce1bd1c2a3536ea
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
The feature was actually not working as expected. It has been fixed,
and a test now ensures it does work as expected. This commit also fixes
some invalid parameters, hopefully nothing critical.
closesodoo/odoo#60429
X-original-commit: 231bdca3f26d96f578503694e5aec062de2317ed
Related: odoo/enterprise#14285
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Current behavior:
call to _file_read() within "for attach in self:" loop references self
rather than attach
Expected behavior:
execute _file_read() individually for every record in self (via "for
attach in self:" loop)
This is not an issue in standard where _file_read is an api.model
method but in case of overwrite (e.g. issue reported at
odoo/odoo#60016 has implemented an AWS integration) it makes sense
closesodoo/odoo#60342
X-original-commit: 160043a4f6aa76010aa77ead7cace9a688c17ae8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this change the rollback hooks were never called since rollback() was never explicitely called by the framework. At the end of a transaction, if no error occurs the famework call commit() on the odoo cursor. In all cases, the transaction ends with a call to close(). Into the implementation of _close() rollback() is called on the underlying connection to ensure that not committed changes are rollbacked. That's the reason why despite the fact that rollback() was not called on the Odoo cursor, changes are not committed into the db in case of exception. To keep the same behaviour and avoid to have to explicitely call rollback() on the odoo cursor to trigger the execution of registered rollback hooks, these hooks are now processed in _close(). Since the list of registered hooks is emptied if commit() is called, we are sure that rollback hooks are only executed in case of rollback.
OPW #2294911closesodoo/odoo#60339
X-original-commit: dce9a05f3a5d37fab711c8ca3c5444941f98e814
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Create a Server Action with the following code: `raise Warning("")`,
when the SA is executed it opens the crash manager with a traceback
instead of the user error modal.
The `odooExceptionTitleMap` data structure lists all Odoo exceptions
that descend from UserError, this structure is used within the
`rpc_error` function to filter pure Python exceptions from custom Odoo
ones.
opw-2365689
closesodoo/odoo#60275
X-original-commit: 7058e338a980268df1c502b8b2860bdd8be9f727
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to reproduce the bug:
- Install web_studio, contacts
- Activate language English (UK)
- Switch all users' language to UK
- Deactivate language English (US)
- Via Studio, add a related field to a contact: Self > Language
Bug:
Traceback: contacts still have en_US as language and it's deactivated.
opw:2350362
closesodoo/odoo#60279
X-original-commit: 47ec3585f50f030025b39031807be50a9299bcd6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Use case: website_event_track(_online)
======================================
On sponsor model, image_128 field is defined in website_event_track module as
computed stored Image field. It means that when this binary field is set, an
attachment is created in ir.attachment model -> attachment is set to True.
In website_event_track_online module this field is modified. It is set as
a related (resized) version of image_512 and not stored anymore.
However attachments still exist in ir.attachment table for sponsor records.
This is not an issue when trying to access the image_128 field using the ORM
as the compute (or related) is correctly called. However '/web/image' does
checks if the field has an attachment and loads it. In our case old attachments
still in database are therefore displayed instead of the new related image.
Fix
===
When checking for an existing attachment in _binary_record_content we also
check that the field is not a related. This fixes the current issue. It also
makes _binary_record_content work as the ORM, aka using the computed value
and not any stored information.
DB Cleaning
===========
In 14.0 a script will be added to clean existing attachments for sponsor
model. Indeed there is no need to keep unused attachments. Especially in
14 website_event_track_online has been merged in website_event_track, meaning
only existing db have to be cleaned. New DBs will never have this attachment
issue as the field is always computed.
Task ID: 2341108
closesodoo/odoo#60259
X-original-commit: ada1eab338c6cffb526b03377ec01962f9c26c4c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
With this commit, pylint will now point out when the same
function/class/method is defined more than once in the same scope which
is a recurring mistake.
closesodoo/odoo#60044
Related: odoo/enterprise#14090
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
This commit adapts the business code in which
class/module/function/method redefinition took place so that it no
longer happens and the pylint test passes.
Model `ir.mail_server` already have `active` field but It was not
present on View which makes it impossible to Archive record.
Now, we add option to archive record through an action or toggle
button.
closesodoo/odoo#60167
X-original-commit: 9ad1f0d43d3ab0d6262c4fb6d1ceb9f58763b2c1
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Behavior before the fix:
- When uploading an office 2007 attachment (.xlsx / .docx) as a regular
(non admin) user, the preview shows it as text, and the download option
by default saves it as a text document (in certain browsers, at least).
This stems from an over-aggressive check on mime type (anything that
contains 'xml' **anywhere** in the mime type is taken to be XML, but the
mime type for an Office document is
`application/vnd.openxmlformats-officedocument.wordprocessingml.document`
so it falls in the XML case.
Behavior after the fix:
- The mime type is preserved
- Mime type for XML-like documents (including HTML and SVG) continues to
be validated
opw-2352712
closesodoo/odoo#60164
X-original-commit: 2820ec7d5763a5856274709a4d2024267313106b
Related: odoo/enterprise#14168
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
Issue
- Install 'Accounting'
- Go to 'Settings/Accounting'
- Try to create new currency
Cause
The empty tuple of ids raise sql syntax error.
Solution
Init the currency rate to 0.0 when there are not ids
opw-2359632
closesodoo/odoo#60159
X-original-commit: 24ab21811ef71f75a24fdeb441c299435789e8fb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
'flags' is not a field in ir.actions.act_window, but it's used to pass
parameters to generate the action window. For example,
{'flag': {'withControlPanel': False}} can be used to hide the control
panel.
in _get_readable_fields, 'flags' is not included. This makes the
configuration passed by 'flags' not work. We add 'flags' to fix the
issue.
To reproduce, go to workorder and enter the tablet view by starting
the workorder. The control panel will be shown, even though
{'flags': {'withControlPanel': False}} is passed in the returned action.
closesodoo/odoo#60150
X-original-commit: b4eaf7cebf3be577ab8eb49530fb92129faa2892
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
By default, PdfFileReader will monkeypatch the `warnings` module even
if it has no reason whatsoever to do so and suppress the
`captureWarnings` behavior.
This means as soon as we've loaded a PDF file, `warnings.warn` don't
trigger `logging` warnings anymore, and become invisible.
This can lead to non-deterministic behaviors depending as warnings may
or may not be suppressed depending when they occur relative to loading
a PDF e.g. load a module which runs a test which loads a PDF before a
module triggering a warning and the warning won't be visible, other
way around it will.
Except ofc while we have an override to PdfFileReader it's not
used *everywhere*, so need to monkeypatch the init.
closesodoo/odoo#60132
X-original-commit: 6b04dbcd4204a75d6bd68fc0b3010a2297779b32
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Performance issue arise when the recordset is very large due to the union operator which apply at worst `len(self)` times.
By storing the ids then browse on them we avoid the union operation execution.
PySpy: https://drive.google.com/file/d/1jnxuSWGf2WmqeRz7zQOpBpmeRE5YnTwS/view?usp=sharing
filtered_domain (odoo/models.py:5398) take 65.6% of the graph (55.7% of the 85% of button_confirm)
To confirm a RFQ with 10 000 of the same product:
Before this commit: ~42s
After this commit: ~10s
OPW-2347525
closesodoo/odoo#60131
X-original-commit: 8b0eeb5076ed5387ca7132d79182800e10c6895e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
`registry._init_modules` is a set so its iteration order is
non-deterministic (it's randomised on interpreter initialisation
unless PYTHONHASHSEED is provide through the environment). This can
lead to annoying non-deterministic behavior: while the non-determinism
is only at the module level, it's easy enough for modules to have
python-level side-effects (e.g. patch methods, update globals, ...),
which may only be surfaced by an other module executing after them,
but not if said module executes before.
By sorting the modules we should make this much more reliable one way
or another.
closesodoo/odoo#60028
X-original-commit: f9169a468a2328a691ec4f32233ba3bad3622282
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fix the "Unsupported M2M command 1" raised `Form` helper.
The `onchange()` method will in fact emit UPDATE command for many2many
fields when the value submitted an the one in database has changed
(this is the case for example for nested m2m in form views)
OPW-2044631
closesodoo/odoo#59943
X-original-commit: 76bd8208a416cefab6becff9f2d7204c7d196201
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Xavier ALT <xavieralt@users.noreply.github.com>
Revert commit
"[FIX] base: clearer message in case of conflict for no_gap sequences"
This commit changed the error returned in case of SQL conflict for no_gap
sequences, wrongly disabling the automatic retry (service/model.py) in case
of such errors.
Also adds a comment in the dedicated test to ensure the behavior is explained
and the automatic retry isn't broken once again by the same kind of change.
closesodoo/odoo#59928
X-original-commit: 811cd40fe427c28f9eb244f78ae23c4d3fb42cc8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The assignment of a binary field on a new record with origin did
actually modify the attachment storing the value of the field on the
origin record! The fix is simply to avoid messing up with attachments
when updating new records.
closesodoo/odoo#59919
X-original-commit: 6778c4c10fa68c46bde6fae176f547f905e9c02f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Upon onchange, the web client sends unchanged image fields on one2many
lines as "bin size" values, while changed image fields are sent as their
full value. As the value is not base64-encoded, the assignment of that
value crashes.
Fix it by making assignment on new records not crash when decoding the
image: the value is simply not assigned to the field. In the situation
described above, the record being assigned is a new record with a real
record as origin. Because the field is actually not assigned, its value
is implicitly the value of the field on the origin record, which is
consistent with the fact that the field was not modified in the form.
X-original-commit: 4442d6f0f29a2bf6e992515cd535c88215855a36
Issue
- Install `Manufacture` and `Purchase`
- Go to `Manufacture`
- Enable Studio
- Create new rules
- Select `Purchase Order` model
- Try to select autocomplete proposition with `Deliver to` field
Traceback raised.
Cause
The _search function does not return indexable value.
Solution
Cast _search to a list.
PS: search can be used (instead of _search) to get iterable value.
opw-2357391
closesodoo/odoo#59832
X-original-commit: 8af2dbb06723213163ee3ad617e5c9309099b4bc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Hardik Prajapati