In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
This commit changes the behavior of the "Search More..." option in
Many2XAutocomplete and analytic distribution by making it available
as long as there's at least one record in the search results and by
renaming it to "View all".
task-3258625
closesodoo/odoo#126041
Related: odoo/enterprise#43660
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
*: account, base_import, board, website
This PR enhances the "cog menu" by fixing several UX flaws.
Notable improvements include:
- Reordering entries in a more logical manner, enhancing user intuitiveness.
- Assigning icons to common actions for quick comprehension.
- Grouping both print actions and module-specific actions for better organization.
Enterprise:
- https://github.com/odoo/enterprise/pull/41851
task-3337951
task-3355224 (milk post-merge fixes)
part of task-3326263
closesodoo/odoo#124413
X-original-commit: 596772885a87016d29f002cd4e41b5a973965e40
Related: odoo/enterprise#42212
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
=== ISSUE ===
If you go to PLM > click on a primary button > click on the cog >
import records, the buttons have a `.m-1` which is added on top
of a `.gap-1`.This result in a double margin, which is not consistent
with other CP's behavior and affects the whole CP layout.
=== AFTER ===
We remove these unnecessary `.m-1`, making sure that no matter how many
buttons are shown they have a correct spacing.
task-3355375
part of task-3326263
closesodoo/odoo#124337
X-original-commit: 40666bfe89ff5bc9013fbb20928c18001b66c6ad
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When user tries to add non ascii characters in image field column in a file and
then when he tries to import it the error will occur.
Steps to reproduce:
1. Install contacts
2. export a contact and keep image field in fields to export.
3. Now in that file change the image data and add non ASCII characters
(for example: 'ô').
4. Now try to import this file in contacts.
5. The error will occur.
Applying this commit will fix this issue.
Currently, a ValueError is raised when we give non-ascii characters as input.
So I have reported an issue in python in which I have mentioned to edit the
documentation to note that it may raise ValueError for non-ascii content, or
to fix '_bytes_from_decode_data' function to raise binascii.Error instead of
ValueError.
To track the issue - https://github.com/python/cpython/issues/105193
sentry-4029823200
closesodoo/odoo#123572
X-original-commit: ceb67160e1747f0a886efb8ca0a60499e2b080d1
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
This commit brings the ControlPanel into a single line with 3 main
sections:
- buttons & breadcrumb
- layout related actions (ie. the SearchBar in multirecord view or
ButtonBox in formView)
- navigation (pager, switch view...)
Add new search bar menu, this is a merge of the following components
into one big component display in column:
* comparison_menu
* favorite_menu
* filter_menu
* group_by_menu
Also adapt navigation hook.
Part-of: odoo/odoo#116641
This commit improves the suggestions displayed to the user when editing
the date or datetime options in the sidebar of the Import action.
A tooltip is also displayed next to each label, to let the user know how
to format properly the date if he wants to write a custom one to match
his own needs.
Since commit [1], a legacy utils was imported to convert a moment format
to strftime. Since this file was legacy, it was needed to remove its import
from the import action and replace it with a newer utility function. Because
this function was not imported elsewhere, it could be removed completely.
In dates.js, a new function allow a user to write a date format in a
human readable format, while converting it to a valid Python strftime
format, to send back to the server the right date.
A test has been added for this improvement.
[1]: 2361f021c3
task-3248787
closesodoo/odoo#117750
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When we try to import bank statement CSV file with all required columns and
set the encoding format as koir8_r we get (ValueError: Unsupported file format
text/csv, import only supports CSV, ODS, XLS and XLSX) this error.
steps to reproduce:
1. Go to accounting and then import bank statement.
2. Select a csv file to import with all required columns.
3. Set Encoding format as koir8_r and then click on 'TEST' or 'IMPORT'.
4. The error will occur.
see this traceback: https://tinyurl.com/24bxk7bt
Applying this commit will fix this issue.
sentry-4049996747
closesodoo/odoo#120054
X-original-commit: 7270bbf589a9d3d794e399b3cf3ad18acf7a2ed6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With commit (1), the clear button is only displayed when a selected
value is found from the available choices. But since we used
shallowEqual to find the corresponding choice, we couldn't use objects
containing objects in its values, since a simple comparison was made
in the utility function. This was a wrong usage of the SelectMenu and
we don't want to support objects and arrays as values. The value
attribute should only be a string, and it's the parent responsability
to handle any object related to this string.
The test using an object and an array as values has been removed since
it had no purpose after the removal of this partial and wrong support.
With this fix, an assertion for the presence of the clear button has
been added instead for the import action.
(1): d760b81271closesodoo/odoo#119298
Related: odoo/enterprise#40177
Signed-off-by: Géry Debongnie <ged@odoo.com>
When importing documents that have a `date` or a `datetime` field
a conversion is done on the format string in case it was still in the
old moment format (e.g. YYYYMMDD).
The problem is that this conversion was done regardless if the format
string was valid or not. This was producing botched format strings that
would prevent any import having a date or datetime field with proper
format string.
closesodoo/odoo#119340
X-original-commit: 20f4102e9aef42c557c6f7e0b5b5e591a18b1b4f
Signed-off-by: Luca Vitali <luvi@odoo.com>
Add support for converting moment.js date formats
to strftime format in BaseImportModel
Steps:
- Try to import csv with date_format "YYYYMMDD"
- ImportValidationError:
-> "Column date_format contains incorrect values"
error is raised because the date format is not
converted before being send to the python import
method.
opw-3247615
closesodoo/odoo#118308
X-original-commit: ee940fc6911656263fb56f9ce63a564f45cdc16b
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
To reproduce
============
- on any app try to import a record that has subfields
- subfields are not matched and not even found on the list
Problem
=======
comparing to 16 **Allowing subfields matching** is disabled here in 16.1,
because of this condition that is checking the list of fields on a variable `fields`,
but this variable is not set before importing the file, so the condition is always true.
Solution
========
apply the condition on `res.fields` instead
opw-3209365
closesodoo/odoo#115639
X-original-commit: 284fab64e33ca398a0ebf69d3d6d59685480156d
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this commit:
=====================
KeyError 'selection_values' that occur in base_import/_handle_fallback_values()
while importing a data file. If any field(s) is many2one or many2many and we
tried to import the value of that field(s) that is not created in the database.
In that case when we set the 'Prevent Import' option.
It will raise an error like KeyError: 'selection_values'.
After this commit:
=====================
Solved the issue when there is a many2one or many2many field(s) and the import
value of that field(s) which is not available in the database. also, the method
is only for the 'selection' field and 'boolean' field so the code works when
there is a selection field and their selection_values only.
sentry - 3958065223
closesodoo/odoo#115056
X-original-commit: 0ef930cd7598bd15227ff025d2662d4331f8e45b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit fixes a couple of issues linked to relational fields:
- When previewing a file with relational fields/ids, they were not
correctly mapped to their respective fields in the selects, the fields
were also not correctly mapped in the arguments given for the import.
- The select label was also only showing the name of the last sub-field
while it should show the full path ("External ID" vs "Company / External
ID").
- Some errors were not correctly displayed: wrong field name, not in a
column when it should be.
Task ID: 3210337
opw-3203704 + opw-3192403
closesodoo/odoo#114490
X-original-commit: 871690afdc2ce4da2770a144cc4fc5ed038e6f73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
During the conversion to Owl of the base_import action, the fields
mapping for each column was made incorrect.
The fields are now properly sorted between the suggested, additional and
relational categories and the subfields are also correctly handled (no
more duplicates and correct labels).
closesodoo/odoo#109416
Signed-off-by: Luca Vitali <luvi@odoo.com>
In the default import options, some separators had a wrong value by
default. This commit fixes those, which will fix some failing imports.
A test has been added to verify the default options set.
closesodoo/odoo#108710
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
This commit removes the state-machine.js library. It can be remove as
this library was mainly used to handle the import action process, and
that it has been rewritten without the need of the library.
Copyright mentions to the library have also been removed, since it is no
longer necessary.
closesodoo/odoo#106265
Related: odoo/enterprise#34249
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit reimplements the import action view to fully use Owl instead
of its legacy implementation. Different components have been created to
separate the UI in smaller blocks, and a model file contains the main
aspects of the import logic.
The SelectMenu component is now used instead of the jquery select2, and some
other web components and hooks have been used or modified to bring this
action to a better state. A custom ImportBlockUI component is used, to
support custom messages and the use of components. It was required to
reimplement the loading progress and indicator used by the view.
The set_file route in the base_import controller has been adapted to remove
the usage of jsonp type of code for this situation since it is no longer
needed nowadays.
On top of the rewrite, js tests have been added to make sure the feature
behaves correctly, and to assert the intended specs.
Finally, legacy files have been removed, since they are no longer required.
Enterprise PR: https://github.com/odoo/enterprise/pull/34249
task-3092474
Part-of: odoo/odoo#106265
Co-authored-by: Bastien Fafchamps <bafa@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This commit is three-fold:
1) we now honnor attributes `create` and `import` which can be
set to a falsy value in archs (and in these cases, we disable
the import feature)
2) we converted the base_import test suite to use the owl views
3) we whitelisted the base_import addon for the lint/prettier
script
closesodoo/odoo#100026
Signed-off-by: Géry Debongnie <ged@odoo.com>
- Remove FEC from res.config.settings - everything is now linked in the import guide (in enterprise)
- Compute debit and credit from opening_balance
- Update import templates for account.account, account.move, res.partner
- Small UI changes in base_import: add an action title and improve the template button design
task-2888243
closesodoo/odoo#96291
Related: odoo/enterprise#29627
Related: odoo/upgrade#3794
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
action act_window can have a "flags" field which contains tweaking parameter for the views.
A little inventory:
- ation_buttons: if true displays on List and Kanban the buttons that trigger action
in the control-panel bottom left area. It is true by default in JS.
- withControlPanel: whether to display the ControlPanel as a whole. True by default.
- search_view: not used or dealt with.
- mode ("readonly"|"edit") whether to initiate a form view in that mode.
(used and practical -- but will be outdated when the edit mode by default is implemented)
This commit removes the occurences of those flags keys that are useless
closesodoo/odoo#94078
Related: odoo/enterprise#28620
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Problem: open any (multi record) view, open the "favorites" menu and
select the import action. The import client action now opens, but no
button is visible in the control panel.
Since a recent owl update, the import client action did not display its
control panel buttons (upload file, cancel, ...). This is caused by an
unfortunate situation: the control panel buttons are rendered, but after
the control panel was rendered, so owl does not add them in the DOM. It
worked by chance before: the props were completely reactive, and the
code actually modifies in place some object received in props. So, a
render was forced on the controlpanel, which means that it properly
picked up the buttons.
Now, this render was accidental, so the new owl code is actually
correct. This commit fixes the issue by simply rendering the buttons
before the controlpanel is even rendered, so it now works as expected.
closesodoo/odoo#92810
X-original-commit: f185f543452abf65b9948e907aeb45e918cf3bed
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
How to reproduce the bug ?
- install the inventory app
- open the app and try to import a file where at least one cell has a
wrong value
What is the bug ?
When you try to import a file in the inventory app where at least one
cell has a wrong value, the file won't be imported. In addition to that,
you will get an error saying that one python module is missing while
this might not be the case.
opw-2715625
closesodoo/odoo#91482
X-original-commit: cafd8699ff8ec8eb93aa283a4cac57317ce40708
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
The basic idea of this functionality is for users
to be able to put limits on Partners that would
trigger non-blocking warnings when trying to confirm new:
- Sales Orders
- Invoices
when that partner has too many open invoices.
task-2722165
Part-of: odoo/odoo#83205
This commit replaces Component by LegacyComponent when the component
uses removed features from owl 1 like getting its `el` or `trigger` an event.
It also adds `useService("rpc")` when component needs it.
closesodoo/odoo#85389
Related: odoo/enterprise#24745
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to follow:
- Go to the Accounting Dashboard
- Click on Bank > Import statements
- Follow the flow to import a file
- Once redirected to the reconciliation, go back to the import from
the breadcrumbs
- Load a new file
Cause of the issue
The state machine used to handle events didn't allow going from
imported to filed_loaded
opw-2706505
closesodoo/odoo#83219
X-original-commit: a19a0bdca369c9038a7a34363a1d9b7ee06f899d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit simply adds a small test for the import multi-mapping feature that
allows the end-user to map multiple columns of his import file to the same
field.
The values in the files are merged together, meaning concatenated for Char/Text
fields and accumulated for Many2many fields.
This commit is done as a preliminary step before fixing an issue related
to this feature in v15.
Task-2687407
closesodoo/odoo#79913
X-original-commit: ac832586e68e0873d69c0b10a3f8cc8b08ea506e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Since v15, the time to import records in Odoo is much slower than in
v14. With a profiling, we know that the cause is `fields_get`. Indeed,
this method is heavy and call many times (#rows * #columns * ~#batches).
So the import time (in seconds) for ~1000 leads in CRM is;
Batch size | v14 | v15 | v15 fix
--------------------------------
2000 | 7 | 20 | 14
200 | 11 | 48 | 15
20 | 17 | 423 | 23
We can see that just by calling `._fields.get` instead of `fields_get`
we gain a lot of time. The reason for that is `fields_get` just read in
a python dictionary (which is really really fast), while `fields_get`
checks the access right, get the description of each fields (which
might make SQL queries to retrieve translation, etc).
Task-2687407
X-original-commit: 96e72a8b1657df00d5ed7ca6db7bd99e352d7096
Part-of: odoo/odoo#79913
Michael (mcm)