Before this commit, the default update_path even if the field was
readonly, it weas returned. So, if you try to create an automated
action on the stock.move.line model and try to add an action, the
button return a traceback because the field is readonly.
After this commit, the method that get the default update_path will
also check if the field is not readonly.
Bugfix Task-Id: 3624328
closesodoo/odoo#146166
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit the clean_assetbundle could unlink invalid
attachment, mostly when generating a no website assetbundle with
a different version than a website one, the website assetbundle will be
deleted.
Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439)
Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440)
Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.min.css) because it was replaced with /web/assets/%-3723971/%%%
The issue is that %-%/ will match 439-b4c80c3/1/ and not only
439-b4c80c3/
Note that it looks like this issue existed for a while but was invisible
because before 16.4 clean_attachment was invalidating the ormcache,
hiding the fact that a still valid asset was deleted and regenerated.
The proposed fix replaces the domain with %-_______/. The unique is
always 7 character long. Note that this change was already made in 17.0
when removing the id from the asset url so this doesn't need to be
completely forward-ported.
opw-3558552
closesodoo/odoo#145452
X-original-commit: 2ac466547e01bfd65415a53ae1efc9d45d9299fb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In a Safari or with GNOME web browser:
- Run a Odoo server without the password policy app
- Go to Settings->User->Select an user
- Click on the action menu and "Change Password"
Current Behaviour
-----------------
The "New password" column have a width of 0.
Expected Behaviour
------------------
The "New password" column is shown.
This commit sets a min width to the new password column to avoid this
weird shenanigan from Safari of setting the width to 0. After some
reverse engineering of understanding why Safari does that I was not able
to find why.
closesodoo/odoo#145930
Task-id: 3573558
X-original-commit: 0dbb0938a90ee0155684bd5bdc7f50f0a9434b9d
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
Currently there is the following issue with cached conversion rates
from the "from currency" to the "to currency".
When the rate of the res_currency_rate of the "to currency" changes the cache is not invalidated.
Thus the cached value may be used wrongly (leading to wrong results).
This commit simply invalidates all the cached rates in case we update or
create a res_currency_rate.
closesodoo/odoo#143847
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
- install the e-commerce module
- in General settings, add and switch French -or any- language
- Go to website
- Under e-commerce > product in the menu bar
- click on any product
- click on go to website smart button
- click on edit button to edit the website page
- choose any block to insert, You can notice the message (DROP BUILDING BLOCKS HERE TO MAKE THEM AVAILABLE ACROSS ALL PRODUCTS) stays in English
Investigation
- The message is not add to website_sale.pot file, as the message string passed to an attribute not an actual string inside a tag.
opw-3573881
closesodoo/odoo#145755
X-original-commit: 9a595cd19fba3a68dacd5159d0b04102bc76cadf
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
The issue:
the default currency for Montenegro is LYD (Libyan Dinar) instead of EUR
The fix:
Set it to EUR
opw-3601783
closesodoo/odoo#145668
X-original-commit: 97c57c8dbb0f6ae19619c963552552454f92da93
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Avoid invalidating cache when not needed.
This improves a lot performances.
Closes#143403
Fixes a bug which causes that: self.flush() and self.clear_caches() were called on every property write/update and delete.
Known at least in V14/15/16/17.
closesodoo/odoo#145549
X-original-commit: b444330050a4d98e7ade42a30a6a27522b5cf4c8
Related: odoo/enterprise#52395
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Since the refactoring of the JS relational model (d4fe919d),
the list is not fully re-rendered after field updates,
such that a fixed narrow column width is added at first rendering
if there are no triggers shown on any row, and cannot be updated.
We need to override it by providing a `width`, which was already
a supported attribute but not declared in rng.
Task-3512604
closesodoo/odoo#135895
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
__Current behavior before commit:__
The logic to regenerate assets bundles is located in the frontend (i.e.
the JS is making the calls to retrieve and unlink them) which is not
very clean.
Furthermore, when doing so, the old assets might still be included on
cached views that called them with `t-call-assets`.
Therefore, regenerating assets bundles can break the CSS or the JS as
long as the view cache is not cleared.
__Description of the fix:__
A new backend method is implemented for regenerating asset bundles.
This provides a dedicated and maintainable approach. Additionally, the
cache is explicitly cleared during the regeneration process.
__Example of steps to reproduce the issue on runbot:__
1. Check `Disable cache` in chrome dev tools.
1. Little bug icon > Regenerate Assets Bundles
closesodoo/odoo#145279
X-original-commit: b8e1f9f880e4723ddbe595043d22b565ad735832
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Issue:
A few internal developers (check related task) used file operations on
IrAsset instead of IrAttachment.
Analyze:
Nothing is done in order to prevent this and it should be clearer for
everyone.
Fix:
Assert that the instance is an IrAttachment in order to avoid a bad
practice.
Related task:
task-3594813
closesodoo/odoo#145337
X-original-commit: afdc094aa3a5eb3cbbe0c482164032b2befa168f
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
At Odoo, we want custom models and fields to start with `x_`.
However, other developers and companies might want to customize
that behavior and be able to change the rule.
This revision targets to factorize the rule `startswith('x_')`
in a dedicated method on `ir.model` and `ir.model.fields`
so they can be overridden to allow the customization
of custom model and fields name in custom modules.
closesodoo/odoo#145270
X-original-commit: edf979c7fddbf05b915393923ed57680b9ba5399
Related: odoo/enterprise#52263
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Steps:
- Create a ticket with a customer ( it will the email)
- Answer to the mail with Outlook Desktop( a multiple lines break)
- Look at the response in the discuss frame.
Issue:
In the frame there is much more lines break than in the original mail
Cause:
The format of outlook desktop mail before sanitizing looks like this
```
<div class="WordSection1">
<p class="MsoNormal">Test<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Two break lines<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
```
So when parsing it transforms the ``<o:p></o:p>`` in ``<p></p>``
which adds more lines break when displayed.
Solution:
Remove empty ``<o:...>`` and ``</o:...>`` tags which are specific to outlook desktop before.
opw-3089550
closesodoo/odoo#144931
X-original-commit: a3e9db87277771c9801f24a5f52aa73b98a0d879
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce :
- install field service module
- install industry_fsm_report bridge module
- click on configuration
- click on worksheet template
- try to delete more than one record
Issue:
- error while deleting more than one record
Cause:
- because ,this issue is from base while deleting the model id's
Solution:
- if we write condition for filtering manual models and calling prepare_update()
method and then non manual models ,then the issue will be solved
task-3607053
closesodoo/odoo#144761
X-original-commit: 0d9d7e5fd944e3ef6e1c53d63a6aec61da51cbf5
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
The clean attachement was invalidation the cache before 16.4,
mainly because if an attachement is in cache of another worker and
deleted, this will cause a 404 when this worker serves a page needing
this attachment.
This was changed because an attachment should be unlink through
clean_attachments in two cases:
- the code source change on the server and a cold worker generates a
bundle
- an ir_asset was modified
In the first case, we consider that the server restarted (normally) and
all caches should be emptied.
In the second case, a specific invalidation is made.
But when something goes wrong, it is hard to debug, especially because
there is no information on when the new attachment was created, and the
previous one deleted.
This should solve the issue by helping to identify the cause of the
deletion.
closesodoo/odoo#143962
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Current behavior before PR:
When you send an email at the receivers end you will see ' ' shown before you open the mail and it disappears once you open the email
Desired behavior after PR is merged:
Corrected and now the ' ' character doesn't appear where I replace it in the HTML template with its equivalent character
Test changes:
The test case that was there was comparing static strings with the HTML entities where my solution is removing those entities so I change the strings to be after escaping those HTML
opw-3481781
closesodoo/odoo#144648
X-original-commit: 1fcd45f19c2d6900ad5d1848a988ab0ae5f287a8
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
With this improvmenet now user can select the currency Chinese Yuan Offshore and use it.
opw-3599124
closesodoo/odoo#144472
X-original-commit: 0e431aded4a7d6ff8dd8ac03860859a19518e254
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Because the class was imported in this file, unittest was discovering
it again and was running the TestHttpStatic cases twice: once because
of its inclusion in the test_static.py file, once more because of its
inclusion in the test_web_server.py file.
Changing the import solved the problem, since it is a python module
object that is now exposed and not test case classes, unittest doesn't
discover the classes.
closesodoo/odoo#143840
X-original-commit: 8067d3bf3d9f73b95595a16100096aafff5c2075
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The test added in 09a4762b will fail randomly, because of the nondeterministic
os.walk access. This commit removes this nondeterminism in the pot.
closesodoo/odoo#143918
Signed-off-by: Raphael Collet <rco@odoo.com>
'field' is the name of a variable and shouldn't be translated
closesodoo/odoo#143441
X-original-commit: 52ce28f8c2e7998e247d3291e57ddd1ca3d604b9
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
* = test_read_group
Currently, a search with the following domain `[('m2m_field', '=',
False)]` will return only the records for which the m2m field is actually
empty and not take access rights into account. This means that, for a
given user and depending on access rules, `record.m2m_field` can give an
empty recordset while a search using the previous domain won't return
this record.
This behavior is problematic when such a domain is returned by the
read_group. Indeed, when using read_group to group on a m2m field,
records for which this m2m field appears empty for the current user will
be counted in the column 'False'. However, the domain associated to this
column is not always valid, as this m2m field can appear empty for the
current user but still have records in it that the current user does not
have access to. Such records won't be returned by a search performed
using the domain returned by the read_group for the False column.
closesodoo/odoo#143233
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
- Enable the merge on account.account in data cleaning APP (in debug)
- Create an invoice with a receivable account = A
- Define a lock date after the invoice date
- Go to chart of accounts
- Select your receivable = A et receivable = B
- Action = Merge accounts where B is the MASTER
Issue:
Upon revisiting the customer invoice: Notice that the journal items have been updated.
Solution:
We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.account` as there other possibilities less dangerous such as multi-edit + archiving
We also prevent the merge of `res.partner` if this one is used in hashed entries
oe:https://github.com/odoo/enterprise/pull/47053
opw-3389157
closesodoo/odoo#142937
X-original-commit: bc66f698e2c4edf2cedce4637dfb7aafaf119251
Related: odoo/enterprise#51170
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
A custom script is modifying the output of
load_information_from_description_file to disable the
auto-install of modules during local testing. It was naively adapted for
v16.0 by replacing the corresponding methods. Since a lru cache was added
(nice optimization in most cases) this is an issue because running lint
test afterward will get the cached value with an incorrect autoinstall
value. It makes sens to avoid reading the file on the filesystem each
time, but making a deepcopy looks like an acceptable safeguard to avoid
hard to debug behaviors.
closesodoo/odoo#143628
X-original-commit: ad10ff4410ccf7c38f6154480484495bb57c53ff
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When using account.root (through account.account().root_id or
account.move.line().account_root_id) in read_group, we can have
inconsistent results because of how account.root is defined.
account_root is a view with the id field computed out of account codes,
but there can be the same account for several companies, so we can have
several same ID for different rows => this is not expected by the ORM
who expects one record by ID => in result, we get for example the values
in the pivot table of journal items be multiplied by the number of
companies if we group by "Account Root".
With this changeset, we add a small optimisation in ORM so if a group by
is ordered by a many2one, if the order of the many2one is "id" we don't
add a left join for ordering.
note: without the change, the added tests failed:
- in account, with 1000 as balance, and 2 as number of root with id=90090
- in test_read_group with a query containing a left join to o2m table
- in test_new_api with a query containing a left join to o2m table
opw-2282699
opw-2289440
opw-3288390
closesodoo/odoo#143257
X-original-commit: 674bdd1ac2cf9a4a3748b85f71ebbd01137485ce
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Some auto-generated field labels don't make sense for translators. For example
field: needed_terms_dirty label: "Needed Terms Dirty"
After this commit, if the field.export_string_translation is False, we don't
export their labels when export translations.
closesodoo/odoo#142329
Signed-off-by: Raphael Collet <rco@odoo.com>
When recursing on non-stored recursive fields, modified() only considers
the records that have some value in cache. But when fields are context-
dependent, we may miss some records because we look up for cache values
in the wrong context. Instead, consider cache values in all contexts
for that matter.
closesodoo/odoo#143644
X-original-commit: f19732c199e6bb2b8bdd55808658cb82c8cd44b4
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
The following situation happened with module industry_fsm, when trying
to delete a cancelled sales order corresponding to a task. When doing
so, the server crashes with error "Could not find all values of X to
flush them", which means that a dirty field (pending update) has lost
its value from cache.
The issue is related to recursive computed fields. Before deleting a
record, method unlink() invokes modified(), which determines all the
fields that depend on the record to be deleted, and marks them to
recompute. Those fields should be recomputed after the record is
deleted, and not before. We found out that the recursive call to
modified() made for recursive fields can force the recomputation of the
recursive field itself before the record is deleted, which causes
unlink() to crash.
The fix consists in marking the fields for recomputation at the very end
of method modified(), after all the fields to recompute have been
determined. This ensures that the processing of recursive fields always
uses the current value of the field instead of its recomputed value.
X-original-commit: 1f5293bc63ae7b06fd0df8d509dc7fafaa016a22
Part-of: odoo/odoo#143644
This commit removes an unnecessary field validation for HTML field.
closesodoo/odoo#143307
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
During an onchange, fields read from database are validated again. This causes
an infinite loop with HTML fields since Odoo 16 because we're revalidating a
value we're reading from the database, which triggers a sanitisation check,
which fetches the original value, etc etc.
Even if the functional bug only appears in 16.0 and above, the root cause is
also present in 15.0 so this commit targets 15.0
steps to reproduce (in 16 or next versions):
- Change Marc Demos's access rights Website = Restricted Editor
- Bypass HTML Field Sanitize = Off
- Inventory / Products / Product Variants
- Studio on the Sales tab and add website_description under Website Sequence
- Go to product [E-COM07] Large Cabinet and fill in the newly added website description
- Log out and log in as marc demo
- Navigate back to [E-COM07] Large Cabinet product variant and try to re-order the vendors on the purchase tab
- Error
before this commit:
Error (infinite loop) during onchange
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 6489, in onchange
record[parent_name]._update_cache({name: record[name]})
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5310, in _update_cache
value = field.convert_to_cache(value, self, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5897, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1198, in __get__
value = self.convert_to_cache(record._origin[self.name], record)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
return self._convert(value, record, validate)
File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
original_value = record[self.name]
...
after this commit:
no error
opw-3575865
X-original-commit: 24d804e
Part-of: odoo/odoo#143307
The language was added at dccc8f39d0
419.png as odoo thinks it's a country...
closesodoo/odoo#143439
X-original-commit: 3bb58958c8f5f98da21bdac411bd226d03e1591b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
To reproduce
============
having a special character in url like `à` (it's possible)
try to print an invoice, a weird character is printed next to currency symbol
Problem
=======
Apparently the method responsible of converting from string to html
analyzes the few first characters to determine the encoding,
so having the base url in the beginning with its special character
leads to wrong encoding.
Solution
========
convert using html parser with unicode encoding
opw-3415418
closesodoo/odoo#143462
X-original-commit: b1cf2a209230b4ace817ff51ab5f55f19b586b11
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
When Odoo is installed with the latest version of the PostgreSQL client (postgres-client or postgres-client-16) and running in Docker (possibly other environments as well but not reproduced so far), executing `pg_dump` via `exec_pg_command` fails with
Database backup error: Postgres subprocess ('/usr/bin/pg_dump', '--no-owner', '--file=/tmp/tmpmnqiktog/dump.sql', '15TEST') error 1
This seems to be because `os.devnull` is being opened in *read* mode which is incorrect (as it's written to). It's not entirely clear if older `pg_dump` simply ignored the non-writable stdout or if docker adds some restrictions which cause the failure.
Either way this can be solved by either opening `os.devnull` in write mode or switching to the `DEVNULL` constant. While the function is deprecated in 16.0 (7f14631fe8) and removed in master (ae3056f3f4fca82c6aee69bf201532e14829c45e) the latter is not a huge change and it a touch cleaner.
fixes#139687closesodoo/odoo#143198
Forward-port-of: odoo/odoo#142987
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Suppose a user who imports a new picking thanks to this:
```csv
location_id,location_dest_id,picking_type_id
WH/Stock,Partners/Customers,YourCompany: Delivery Orders
```
Then, on the inferface, for one of the fields, he sets the value as
"Database ID" (for instance "Destination Location/Database ID").
When trying to import the file, an error is raised, which could make
sense since the provided value is not a DB identifier, but the error
is actually incorrect:
> Odoo Server Error. Current transaction is aborted, commands ignored
> until end of transaction block
When looking for the destination location in the database, it will
raise a legit error since the domain does not make sense:
`[('id', '=', tentative_id)]`
Hence this:
> ERROR: invalid input syntax for type integer: "Partners/Customers"
The good point is that everything in the code already handles this:
we catch the error and add some detailed explanations in the import
error report, but... The SQL transaction is now broken. So, as soon
as another SQL request is executed, it will trigger an
`InFailedSqlTransaction` error, we will not catch it and this error
will be returned to the frontend (we lose the import report).
sentry-3969379125
closesodoo/odoo#143010
X-original-commit: b0e86e5c6d4b54134b91dbde3a145b551158b76d
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Description:
Since 54857ec409 , the results of the
expensive recursive CTE on `res.partner` were never used. So the query
doesn't do anything at all, besides slowing down the whole process
for minutes on databases with a large volume of `res.partner` entries.
Fix:
Removing the dead code
Reference:
task-3601394
closesodoo/odoo#142914
X-original-commit: 29223533f625d579e424bdc133d0cfc472946b6b
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Just like for `assertQueryCount`, we should not take into account
queries that are not run after a warmup, for consistency.
This allows to easily interchange both context managers for debugging
purpose for instance.
closesodoo/odoo#142450
X-original-commit: aaa1d287085c8b2fe20b6591ca9f1b5bbe65d3db
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Remove quotes when name of a formatted email is also an email, as indicated
in tests. We still get two emails being sent for a given outgoing email
when the name part is an email but that would be difficult to avoid.
Task-3566542
closesodoo/odoo#141856
X-original-commit: odoo/odoo@d3cdaa6c18
Related: odoo/enterprise#50892
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add test cases related to an issue found during mail gateway testing. When
an email_to is formatted like '"robert@notgmail.com" <robert@notgmail.com>'
the tool finds two emails. As it is used in IrMailServer it sends two emails
insted of one. This may happen notably when partners are automatically created
based on an email only in which case it is put in both name and email.
Task-3566542
X-original-commit: odoo/odoo@312323e0d9
Part-of: odoo/odoo#141856
When 'getadresses' fails at parsing some input and give us a result like
'gmail.com' (see previous commit adding test cases) we fallback on using
'email_re' which is better at finding email addresses in a global string.
We use it only in this specific case as fallback mechanism to rely on
'getadresses' when possible.
Task-3572208
X-original-commit: odoo/odoo@8e61a3b690
Part-of: odoo/odoo#141856
Add test cases related to issues found in various leads management. All those
email inputs lead to an email found being '@gmail.com' (or equivalent) which
is not a valid email.
A consequence of that behavior is that 'email_normalized' for several leads
is the same ('@gmail.com') and they are considered as being the same email
identity. They could be included in a pack of leads to merge (see 'crm').
Task-3572208
X-original-commit: odoo/odoo@7498b9a0a1
Part-of: odoo/odoo#141856
Be logged in multiple companies (A and B).
Be on a form view of some record which is visible only on company B via ir.rules.
With the company switcher, unlog from company B.
Before this commit, the user received an AccessError and arrived on a blank webclient.
To say the least, it was rather inelegant.
After this commit, the user ends up on the multi-record view of that model, provided that it is available for use.
Task-3029616
closesodoo/odoo#141796
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The "reset password" feature does not take into account
multi-website.
steps to reproduce:
- create a website A
- uncheck 'Shared Customer Accounts' on website A
- create a portal user user@example.com on website A
- create a website B
- uncheck 'Shared Customer Accounts' on website B
- create a portal user user@example.com on website B
- reset password for user@example.com on any website
before this commit:
An error is raised "No account found for this login"
(which is false, actually 2 accounts are found)
after this commit:
Only the user linked to the current website is properly
selected
opw-3551540
closesodoo/odoo#142110
X-original-commit: a2196253d6cf90dca3042a777703e0679f74f542
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the commit afdcf9a5d5cd0d25b2ba61167d3ae6726a97d554, the mobile main flow tour
fail sometimes. This is due to the fact that the tour try to edit the record
before the new record is displayed.
The solution is to wait for the new record to be displayed before trying to edit it.
closesodoo/odoo#142124
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
For a compute store field with new records (e.g. during an 'onchange'),
the compute method can be called multiple times on the same records
without changing the dependencies. Moreover, it can lead to have N² / 2
complexity for a trivial compute on N records.
With partial (where we don't always change the value) compute method:
```
@api.depends('reward')
def _compute_has_been_rewarded(self):
for rec in self:
if rec.reward:
rec.has_been_rewarded = 'Yes'
```
If every `reward` of `self` (N records) is `False`, when the ORM needs
to recompute `has_been_rewarded` of `self`: the compute will be batched,
but only the first record in the batch will be set (to `False`) each
time (due to the current fallback - "fallback to null value if compute
gives nothing"). This means that we will call the compute method N
times, and the compute itself will loop on an average of N/2 records
(the prefetch set decreasing at each step).
Fix this quadratic behavior by setting the cache to `False` for every
record not set during the compute method (instead of just the current
record).
closesodoo/odoo#142162
X-original-commit: 1604ee983aadc0cbee0cd50cbea2b09572905b04
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
