This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.
How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice
Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.
closesodoo/odoo#115444
Task: 2852452
X-original-commit: 09cb57446d99a48651cbfeeb5405029bc2d77226
Related: odoo/enterprise#38255
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When a company is created during the odoo installation, depending on the installation parameters, importing "res_company_data.xml" before "res_currency_data.xml" can prevent the activation of the company currency.
E.g. a fresh odoo install with account_accountant and no demo data will have 0 active currencies.
X-original-commit: f9247a276b71e9d09bb03c85dc93b36c53703e60
Part-of: odoo/odoo#115444
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
When upgrading a database with `l10n_multilang` installed, the
translations kept were not the right ones.
Here is the process that was executed during the upgrade:
* `base` is loaded: registry is loaded with `translate=True`, which
calls `convert_column_translatable`. This has the effect of setting
the value of the field to `{'en_US': name}`, with only that language
installed.
* `l10n_multilang` is loaded: the function `lang_install` is extended to
copy the translations of the templates on the instanciated records.
* `l10n_*` is loaded: the translation values are loaded from the `.po`
files. `lang_install` is called after the loading on the templates,
copying the value on the records. The value on the records is now
something like `{'en_US': name, 'fr_BE': nom, 'nl_BE': naam}`.
* `base/end-migrate` is executed: it copies the values coming from
`ir_translation`, without overriding the values that are already on
the record because of the order of the `||` operator.
This means that any value inputed by the user[^1] will be overriden by
the value in the `.po` files.
opw-3175383
closesodoo/odoo#115254
X-original-commit: 5d46cdee878d752b9a61a74762a8710be0890e9d
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: HydrionBurst <cwg@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
With the special support for postmortem debugging removed, the
likelihood of needing / wanting the werkzeug remote debugger seems
even more remote (as it works in strictly less situations, only for
frontend non-json requests).
So remove that as well.
closesodoo/odoo#115176
X-original-commit: a2022783b652299155c460294c00dbced9b619ac
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It's done nothing since #78857 and it doesn't seem like anyone has
cared (found no issues or tickets).
Rather than restore the feature, just remove the leftover bits.
X-original-commit: 4a7cfc8844eb9b754f16f9d013452d5bde8770b5
Part-of: odoo/odoo#115176
Chrome 111 enabled checking of websocket origin: if the WS connection
sends an Origin head which is not whitelisted with the new
`--remote-allow-origins` switch it is rejected.
Turns out websocket-client (amongst others) *does* send an `Origin`,
which trips the check, and means tours immediately break when trying
to run them as Odoo's test harness is unable to connect to (and
control) the devtools.
Suppress sending `Origin` to fix the issue.
To make the watch mode work, set `--remote-allow-origins`: since we
specifically only bind the devtools to the loopback
address (127.0.0.1) whatever issues this plugs are unlikely to affect
us. We might eventually want to change the behaviour of the watch
feature for UX reasons and remove this in the future though, either by
working through the non-ws remote inspection (`chrome://inspect`) or
by having the `watch` mode run in a normal browser directly instead of
having a browser connect to a headless browser.
Chrome 111 changeset: https://chromiumdash.appspot.com/commit/0154caeefc74530d5cb57ce71608beb1b77bca39
Chrome tracker issue: https://crbug.com/1422444closesodoo/odoo#115067
X-original-commit: 47a02b3924c3e4d1690e336fdd764383393ee378
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This could prevent the user deletion if linked to a record of this
type, like a auth_totp.device which inherits from this model.
Part-of: odoo/odoo#114656
Purpose
=======
Improve the portal user deletion by preventing timeouts and
avoiding several rollbacks causes.
Specifications
==============
- Move the portal users deletions from autovacuum to its own cron.
On big databases such as odoo.com, deleting a res.users takes
more than 1 minute. Move the whole process into its own scheduled
tasks.
- Commit the deletion at each user. As said previously the deletion
can be expensive, so commit what has been done to avoid having to
delete the same user again in case of rollbacks or timeout.
- Delete the user and the partner separately. If the partner is used
in a sales order for instance, the unlink is possible for the user
and not the parner. It allows to unlink the user and keep the
partner in case it cannot be deleted.
- Re-call the cron into another transaction in case there are too many
users to delete, instead of waiting next call, that is supposed
to occur the day after.
Taskid: 3222941
Part-of: odoo/odoo#114656
When computing flag_image_url field on res.lang model an invalid url is generated due to the peculiar format for serbian lang code sr@latin which has "@" sign instead of expected "_" sign and thus the unexisting url is computed, so we are forced to populate binary field flag_image instead.
X-original-commit: 85db3773ba475a143a99126c6c24b404bdd39d0b
Part-of: odoo/odoo#114565
During revision 415525cecc
the code comparing the connections without password has been
dropped, for an unknown reason.
Because of the above, and the fact psycopg2 alter the password
with 'xxx' for security reasons, the connections recycling was
no longer working as expected, and was recycling less connections.
closesodoo/odoo#37005
Signed-off-by: Rémy Voet <ryv@odoo.com>
Issue: when use t-if to display text and use mutli line, the white-space
are removed.
```
<div>
<t t-out="nb"/>
<t t-if="nb == 0 or nb == 1">product</t>
<t t-else="">products</t>
</div>
```
is rendered:
```
<div>
3products
</div>
```
closesodoo/odoo#114986
X-original-commit: 3150a3769ff4d762c0e52dab31a70b59292c1bcc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
When we create a new record X and its values contains an one2many field
with either a recordset Y or a Command.set(ids), the ORM generates extra
SQL queries to search and remove the existing lines of the new record.
The call chain is as follows:
Model._create
-> _RelationalMulti.create
-> _RelationalMulti.write_batch
-> One2many.write_real
But because record X is brand new, it has no lines to begin with. The
fix consists in skipping the search and removal in that case.
Also remove any nondeterministic behavior of method write_real() using
an OrderedSet instead of a builtin set.
closesodoo/odoo#114726
X-original-commit: 428827e5213ee002a5b50d864f8ce1f24d1842b3
Signed-off-by: Raphael Collet <rco@odoo.com>
Before commit:
There was no mobile field in the optional fields of tree view in res.partner.
After commit:
Added the mobile field as optional field.
Task-3184771
closesodoo/odoo#113243
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The TriggerTree class does not have a specific __repr__(). It thus
falls back on dict's __repr__(), which does not show the root of the
tree. This makes debugging hard and confusing.
closesodoo/odoo#113521
Signed-off-by: Raphael Collet <rco@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Because Werkzeug supports ipv6 natively (and has since ~2010
pallets/werkzeug@13a76262a4), running
Odoo in threaded mode allows binding to an ipv6 address.
However the prefork server is part of Odoo, and only creates
AF_INET (ipv4) sockets. Thus switching from threaded to worker mode
breaks the bind.
Add a family switch on the `http-interface`, so binding to ipv6
addresses also works in ipv6. Gevent already does that switching
internally, so the evented worker works out of the box, it was only
the prefork / workers which did not.
Looking at both the Werkzeug and Gevent implementations:
- https://github.com/pallets/werkzeug/blob/f9906fa6d83dd668f9214acef458419756bbc062/src/werkzeug/serving.py#L607-L614
- https://github.com/gevent/gevent/blob/1e412d35526183b26c1abf2eb658cbef661f5f70/src/gevent/baseserver.py#L415-L433
Both primarily check whether the host contains `:`. Werkzeug also
checks if `socket.AF_INET6` exists, however gevent doesn't bother with
that. Looking at the
source (https://github.com/python/cpython/blob/7d801f245e2021d19daff105ce722f22aa844391/Modules/socketmodule.c#L7419-L7421),
it is indeed possible for `AF_INET6` to be missing, however that
requires specifically compiling Python in an environment which doesn't
support IPv6.
Meanwhile it's also possible to disable ipv6 at runtime, in which case
I'd assume the `socket.AF_INET6` constant is present, and creating the
socket fails, which nobody guards against. Therefore just ignore the
entire thing, it doesn't seem worth the hassle (or the questioning) to
check whether the constant is present, especially since this is only a
concern when the user specifically requires an IPv6 address.
Fixes#35782closesodoo/odoo#114666
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Consider a form view with a one2many field, which has no form subview.
Also the form view of the comodel (the one2many field's lines) contains
the inverse many2one field of the one2many field. When adding a new
line on some existing record, the form view shows the many2one field as
empty, instead of being the main record.
Explanation: the form view of the line invokes onchange() with the main
record's values (dict) as the value of the many2one field. Inside
onchange(), the field is actually set to a new record corresponding to
the main record. Alas, when that value is sent back to the form, the
new record is serialized as False.
Solution: let onchange() serialize the new record as its origin record
instead.
closesodoo/odoo#114648
X-original-commit: d137ea4915da8d46909fcb082b5a88fd347874a4
Signed-off-by: Raphael Collet <rco@odoo.com>
In order to ease the process of setting vats for some users, it was
decided to allow to use a vat number of a single character ('/' for
example) without checking it. This allows to differentiate between
partners for which we did not set VAT yet, and partners exempted from
VAT/without a number.
The VAT check was recently adapted to handle this use case, but the
"same vat" warning was forgotten in the process.
This additional change will disable the "same vat" warning that appears
when two partners share the same VAT number if that vat number is
only a single character, aligning the behavior of the warning to the
changes done in the vat check itself.
closesodoo/odoo#114640
X-original-commit: 4d80d30d0db6993a2fbbab59b935abe07080074b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
In some cases, wkhtmltopdf might exit with an error (e.g.: a memory
limit). In such cases, we want to show to the user the error returned by
wkhtmltopdf. Previously, this message was only displayed in binary
format (displayed as "Message: b'My error\n'") which is not user-friendly.
We want this message to be decoded so that it is a bare string
(displayed as "Message: My error").
closesodoo/odoo#114609
X-original-commit: 5fc49f8bb24a328e7b735847795bd8e78229cbfb
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
document_ftp, website_instantclick, pad, pad_project, note_pad, pos_cache is not currently existing in the addons, removing the non existing modules from the BLACKLIST dictionary.
closesodoo/odoo#107213
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce:
Edit documents layout in general setting to add logo and background
select multiple documents (more than 5) e.g. Inventory> delivery slips
print all documents.
Bug:
background and logo missing on the last documents because the pages
were printed before the browser had time to render them
Fix:
wkhtml2pdf has a default delay of 200 ms (--javascript-delay)
increasing the value will allow large document to load
opw-2951594
closesodoo/odoo#114512
X-original-commit: ac2df93eb3f08696189d010bdfa4187e02a94576
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- Install `Contacts` module
- Create 3 contacts with the same name
- Archive one of the contacts
- Go to list view
- Edit search filter to display archived and non archived contacts
- Select the 3 created contacts
- Open `Action` menu and click on `Merge`
Issues:
- Archived partner is set by default as destination partner.
- Archived partner is not displayed in the list of partners to merge.
Cause:
- The default destination partner set is the last record of the record
set returned by `_get_ordered_partner` (where `Archived` partners
are the last ones in the record set).
- The field `partner_ids` does not allow archived records.
Solution:
- Sort the partners to have the archived ones on top (since we took
the last one).
- Set `active_test` to False in the context of the partner_ids field.
opw-3205577
closesodoo/odoo#114508
X-original-commit: 8d0cec6844b248d3787bd7d6b8868d930d25e38c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Odoo does not have much in terms of payment protection; you can create
payments to any account you want without many checks.
This changes it by requiring users with the right groups to trust an
account before allowing it to be used for payment methods requiring.
Also adds some warnings on the bank account view, and checks at the time
of creating a payment.
Task id # 3210415
closesodoo/odoo#114278
Related: odoo/enterprise#37789
Related: odoo/documentation#3737
Related: odoo/upgrade#4397
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This field has been introduced in
https://github.com/odoo/odoo/commit/c68600cc5397700df4f40095c27723a2b1f90a22
The reason why is not really clear, given the commit message.
But, it looks completely unused nowadays.
We can therefore safely remove it.
In addition, this will save a lot of transferred data to the web client,
as currently all the fields of an action are read when the web client
loads an action,
including this one, which contains a long xml content.
For instance, with just base and the contacts modules installed,
to load the action of the Contacts menu,
it goes from 5.51kB to 1.05kB.
closesodoo/odoo#114041
Related: odoo/upgrade#4390
Signed-off-by: Rémy Voet <ryv@odoo.com>
Purpose
=======
Add the properties fields in the search bar and allow to search
properties fields values.
Technical
=========
If the "active_id" is in the context, show only the properties
of the given definition record. Otherwise, show all properties
of all definition records.
Because fetching the properties definitions cost a SQL query and a RPC
call, the properties definition are fetched only if we unfold the
properties field (so it has no performance impact until we ask
explicitly to search a property).
Task-2980121
Part-of: odoo/odoo#101901
Co-authored-by: Polymorphe57 <dam@odoo.com>
Purpose
=======
Allow to search properties fields.
For now, the properties fields are meant to be used with the frontend
top bar filter on views in a later commit, and so everything as been
kept as simple as possible for that particular use case.
Technical
=========
Relational properties
---------------------
We can not search on relational properties using the rec name, or
using one of their fields.
The following domains do not work
```
[('properties.partner_id', 'ilike', 'alice')]
[('properties.partner_ids', 'ilike', 'alice')]
[('properties.user_id.name', 'ilike', 'bob')]
[('properties.user_ids.name', 'ilike', 'bob')]
```
Instead, we should give the ids
```
[('properties.partner_id', '=', 55)]
[('properties.partner_ids', 'in', 55)]
```
IN operator
-----------
The "in" operator is used to either search specific tags / many2many
values, either doing a "OR like" condition on "non-array" value.
It can be used if the left or the right side is not an array
```
[('properties.my_char', 'in', ['a', 'b'])]
[('properties.my_tags', 'in', 'a')]
```
But it can't be used if both side of the condition are array, because
it will require to check type in SQL (which is technically possible,
but add extra complexity, so for now we keep the feature as simple as
possible).
So the following domain is not supported.
```
[('properties.my_tags', 'in', ['a', 'b'])]
```
Instead we should use the "OR" operator
```
['|', ('properties.my_tags', 'in', 'a'), ('properties.my_tags', 'in', 'b')]
```
Tags / many2many - "=" operator
-------------------------------
Tags and many2many have to be searched using the "in" operator.
So the following domain will return unexpected results and raise a warning.
```
[('attributes.mytags', '=', ['a', 'b'])]
```
The reason is that we don't want to dynamically check the type in SQL,
and so we need the "in" domain operator to know what to do in SQL.
Task-2980121
Part-of: odoo/odoo#101901
Purpose
=======
Do not modify the cache in order to improve the performance when we
read in batch. Instead we create a new batched method "convert_to_read"
that check existence in batch, and generate a dict with the result.
Now, all the properties field checks (many2one existence, selection option
still exists, tag value stiff exist, etc) and done in "convert_to_read".
It means that doing `record.properties` won't do all those checks.
Having the batched field fetch at the convert_to_record required too
many changes for the scope of this task, so "record.properties" having
the cache values unchecked is an acceptable tradeoff currently, hence
we batch convert_to_read.
Task-2980121
Part-of: odoo/odoo#101901
Make ir.attachment._search() consistent with method check() for access
checks. Also make it generate less queries by combining the extra query
with the main query of _search().
Part-of: odoo/odoo#112126
Issue: checking access rules fetches some data in cache. Sometimes,
accessing a forbidden record does not crash because of the data left in
cache. This is the case when accessing a field on a record, like in the
field accessor method:
try:
records._fetch_field(f) # (1)
except AccessError:
record._fetch_field(f) # (2)
The field f is included in the data fetched to check access rules in the
prefetch set of record (1). Therefore, when trying to fetch the same
field in (2), there is nothing to fetch and no access error occurs.
Part-of: odoo/odoo#112126
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Goal: make _search() always return a Query object, in order to make
search_read() in a single query when possible
Adapt the overrides of _search() towards the given goal.
Part-of: odoo/odoo#112126
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
The goal is to be able to use Query objects for both subqueries and
known ids tuples. This provides a single API for injecting either a
subquery or its resulting ids into another query.
Part-of: odoo/odoo#112126
jbw