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>
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 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>
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>
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>
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>
If records are grouped by date, the avg aggregation
makes a more meanignful value
closesodoo/odoo#59577
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
After commit 06a8c5264eb6e87c29ad1d23a14e12dd45aa281c it is no longer
possible to pass bare modules to `safe_eval`'s context, however during
the aforementioned commit only the wrapped datetime and dateutil modules
were updated in ir_model's SAFE_EVAL_BASE context, thus the bare `time`
module was still being passed (and this triggered a traceback whenever a
custom computed field that used the time module was computed).
The fix is simple: pass the wrapped time module to the `safe_eval`
context instead of the bare one.
This commit also introduces a regression test to verify that the passed
modules actually work in custom fields.
opw-2347711
closesodoo/odoo#59560
X-original-commit: 02e816877ec12471a1446ba894b5cfca309979da
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Some graph view attributes are no longer supported.
We clean the graph_view.rng file and adapt few xml files.
closesodoo/odoo#59513
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit improves the notification displayed when we configure
the mail server and click 'Test Connection' button. It removes the
title of the notification, improves the message string and changes
the notification type to 'success' instead of default 'warning'.
Task Id : 2321763
PR #56213
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Consider a one2many field with a corresponding many2one field that is
computed. After modifying the many2one field's dependencies, the cached
value of the one2many field is inconsistent until the many2one field has
been recomputed. Therefore, one has to force the computation of the
many2one field before accessing the cached value of the one2many field.
closesodoo/odoo#59034
X-original-commit: b9201ebdd65eaabab9257cf97c58410681783fa6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Luce Pasquini