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>
This commit add and test the support for string format with %d. this
is because python will fail if a string is passed to a %d, and
therefore we can consider it safe.
closesodoo/odoo#141993
X-original-commit: 37157cfa5df1201ffd51520969a3fb6b8a9dfdb1
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Succeeds #140464
Misunderstood `had_failure` and should not have reused it, its goal is
to avoid eagerly aborting some JS tests -- specifically the unit test
suites -- while still logging errors normally (useful when watching
interactively, or for the runbot's own reporting).
So the *checks* added on `had_failure` should in fact be checks on
`_result.exception()`, and as it turns out on `_result.done()`: if a
tour is already marked as successful we can't fail it either.
So we should not, we should log an error (to notify the caller /
runbot) and then bail. While #140464 did improve some things, we could
still lose legit errors and get pages of unhelpful `InvalidStateError`
if a tour would succeed *then* failures would occur, as the guard only
checked that the tour had already failed.
closesodoo/odoo#141815
X-original-commit: 87fcf66203dcbd281470285d648365d33d0e2fca
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When there are multiple broken XML files in an assets bundle. During the
bundle processing, a template containing the parsing error message is
returned for each XML file that is broken.
Before this commit, each of the returned templates had the same name,
raising another error ("Template already exists in module").
Now, all the returned templates has unique names.
closesodoo/odoo#141568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since [1], when an error exists in an asset, the assets raise a not
found exception. The issue, is that, there is no feedback for the
developer to find the error.
Now, a new console log with the error details is shown.
[1] : bf3b6b0b8bclosesodoo/odoo#141705
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Setting a default value for an integer that is greater than that allowed
by a 32-bit integer raises an error when we save a new record so it
isn't clear that the issue comes from the default value
Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts and open any contact
3. Toggle Studio and add an integer field in the view
4. In the Studio sidebar, set the default value to 3 000 000 000
5. Save and close Studio
6. Create a new contact, give it a name and try to save the record
7. An error is thrown
Solution:
Raise an error if we set an integer field's default value out of the
bounds of a 32-bit integer
opw-3360160
closesodoo/odoo#141339
X-original-commit: 85978e4c6fb1199f5e6ec4dce5c45b9f09be9b77
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
in #124402
`update_field_translations` will call `write` to trigger all override logics.
But for ir.model.fields, write will call init_model which may remove all
translations. This commit fix the issue by adding a bypass for translate_only
`write`.
(this commit is the merge of #141126 and #140695)
opw-3575512
closesodoo/odoo#141472
X-original-commit: 33f08c40c92429ada6c5b0387f36d32d4825fcb6
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Complement of the previous complement e2752a04ff (#137099)
Those opcodes were added in Python 3.11 and we missed them.
Fixes#140588closesodoo/odoo#141015
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With normal module, the icon is always loaded from the filesystem but
when importing a module that contains a module icon (by default in
static/description/icon.png) it crash with a `FileNotFound` exceptions
because the image is not available on the filesystem but as an
ir.attachment.
This ensure that for imported module we load the icon from the
corresponding imported attachment
closesodoo/odoo#141133
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
As of https://github.com/odoo/odoo/pull/114024, `display_name` is
implicit in every form view (see the use of addFieldDependencies in the
Form controller). Therefore, when you create a new record for this
model, it calls the first `onchange`, which will compute display_name
for a new record (id without origin). Some `_compute_display_name` don't
handle new records correctly and raise a traceback. These models are
sometimes directly accessible:
- Accounting > Account Group > New => Traceback
- Contact > Contact Tags > New => Traceback
Other models are inaccessible by default (no view to access or create a
new record), but if someone creates a view for them with studio (or
modifies an existing one to allow creation):
- `crm.iap.lead.role`
- `crm.iap.lead.seniority`
- `chatbot.script.answer`
- `payment.token`
Change the code of `_compute_display_name` on these models to be more
defensive and avoid (potential) tracebacks. Similarly, change the
`convert_to_display_name` of `fields.Datetime` to take into account
`None` value.
closesodoo/odoo#139592
Related: odoo/enterprise#49721
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch company with a name coming before it's parent's in alphabetical order, if they had the same sequence (which is the default), would always be returned before it by this function.
This behavior caused some issues, as it was assumed the order of the element it returned would be the same as in the company selector ; respecting the hierarchy of branches, with parent companies coming first.
This was spotted in Accounting, with the following setup:
- A company named "main", with one branch called "branch".
- "branch" has one sub-branch called "branch branch".
- Enable "main" and all its sub branches in the selector ; "main" is the active company.
Here are the issues that were found in Accounting:
1) Click on the "new" button in the Customer Invoices' tree view. Don't change anything in the form that opens, and check the value in the company_id field of the invoice being created. It should be "main", but it's "branch" instead.
2) (when applying the fix commit on the enterprise branch related to this one)
When printing an accounting report, the route called to generate the file restores the active companies from the options' multi_company key https://github.com/odoo/enterprise/blob/16.0/account_reports/controllers/main.py#L21 . Because of that, if the report does not support multicompany, but only branches of the active company (see corresponding enterprise commit for details), if the first company in this list is one of the branches instead of the main company, the companies computed for the report will be different.
In our example, "branch" will be first in the list, so the options for the file export will be computed with "branch" as main company, enabling only its branches that are selected in self.env.companies ; so only "branch" and "branch branch" will be in the report ; which is wrong, as we also want "main".
X-original-commit: b0d716a0e618ddc78d6ca80b5bc7b796ed27905a
Part-of: odoo/odoo#141033
Chong Wang (cwg)