The formatting of very big numbers (like
1.0045e+22) was not handled adequately by
the function 'human_number' in web.utils.
For those numbers, it seems more appropriate
to use the scientific format. The only
difference introduced here is the following.
Beyond a magnitude of e+21, we represent the
numbers by themselves but we keep the
number of decimals provided as parameter
(or zero by default) and we remove useless
zero decimals like in the other cases.
For instance, 1.0045e+22 is replaced by 1e+22
instead of 1.00e+22 if ask 2 decimals of
precision (and by 1.005e+22 for 3 decimals).
We have also fixed a small bug occuring in the
previous version of the function: the symbol
'E' was never used. So by the past the above
number would have be represented as
10045000P and, even worse, 1.01e+45 by
1.012e+28P.
closesodoo/odoo#31140
The commit 6d3ada1
aimed to solve problems occuring whith (single or
double) quotes when creating new custom filters.
Unfortunately, the point was missed and bugs were
still present. The present commit solves the
orginial problem satisfactorily.
There was also a problem in the management of
backslashes. Type '\\' in the search bar would
lead to a domain like
[('...', 'ilike', '\\\\\\\\\\\\\\\\')].
This has also been fixed. Note that it is
necessary to input "\\" if one is looking for a
backslash in db (as before).
A remark on the _formatAST function (py_utils.js):
We deescape only the chars `'`, `"`, and `\`
because it does not seem possible to produce a
string in the search view that would intend a
search for a line return or a tab for example.
A general remark:
Domains should always be in normalized form.
In that way they could be manipulated and combined
together without a tokenization/parsing!
closesodoo/odoo#31025
On a view, define a timerange for fetching data
Save as favorite
Before this commit, the time range description were not transmitted as
strings for the creation of the filter
So, when loading the filter back, there was no description for column headers
resulting in displaying "Object [Object]" as their title
After this commit, we save in the context of the filter the description of the title
OPW 1930582
closesodoo/odoo#30992
`.value` is always bin size. By using `.raw_value` we allow the condition to be
true when actually using binary data.
This solves an issue when trying to display the image for a model being created
since at that time the URL does not work yet since the model does not exist.
Eg. website_sale extra images on product.
This also prevents (potentially a lot of) unnecessary GET to fetch images for
which we already have the binary data downloaded.
Part of task 34045
PR: #30881
Before this rev., the context specified on an x2many fields (in the
arch) wasn't fully propagated to the subrecords. This means that it
couldn't be used, e.g., in the template of the sub kanban view (see
parent commit).
PR: #30881
Before the control panel refactoring, whenever a user pressed ENTER in
the search bar (with no text), the current view was reloaded. This
untested behaviour was changed (not on purpose) with that refactoring:
instead of reloading, the search view add a useless filter in the list
of facets.
We restore the previous behaviour in this commit.
closesodoo/odoo#30503
Improve the mobile kanban when it's embedded in another view like
the Dashboard app
- Improve swipe: Allow to swipe on empty space
- When it's embedded :
- The Kanban column height now is fit to the content
- A empty space is now display if the Kanban column is empty
Task Id: 1904747
When using the datepicker with norwegian locales, the dates are
correctly formatted using the norwegian locale but the name of
the months are shown in english. This cause a date validation
error and thus it is not possible to change the date.
tempusdominus.js uses moment.js to deal with dates, it sometimes
copies/creates some and set their option according to the ones
given at instantiation time and fallbacks on default options for
that are not set.
opw-1922437
closesodoo/odoo#30276
Before this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb do not preserve translation
warning.
After this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb preserves translation warning.
Technical note: alertFields is now an object and an attribute
of the form renderer
that stores translation alerts per record. The translation
alerts
created for a given record are maintained unless
they are closed manually or the renderer is destroyed.
Issue-ID: 1877480
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#29377
Before this commit, when opening the calendar view with a specific locale
in the "week" view
the days were translated but the date format was wrong and fell back to english
This was because the translated terms were passed explicitly, but the locale did not
get passed
After this commit, we do what it takes to pass the locale to fullcalendar
and the dates are formatted with the right pattern
Also, there may be a bug in fullcalendar, because just passing the locale in the options
won't work, it should be instanciated first in fullcalendar's "locales cache"
OPW 1922092
closesodoo/odoo#30530
Create record A on form view, on which a dynamic domain is added by an onchange.
Switch to kanban view. Quick create a record B. Click edit.
This sends you to the complete form view to edit the record.
The dynamic domain of A is still applied.
When discarding the changes, the _domains attribute was not reset.
Example of a model on which this flow can be reproduced is helpdesk.ticket,
with _onchange_partner_project providing the new _domain.
test courtesy of @aab-odoo
opw 1920874
closesodoo/odoo#30308
Open a pivot view with default filters automatically activating
Disable those filters
Change the groupBys on the rows and cols of the pivot
Save your result as a favorite filter
Before this commit, the filter did not contain the context information for columns groupby
Also, the search view did not exploit the context of the new filter as it should be
After this commit, the flow works as expected
OPW 1913732
closesodoo/odoo#29415
Before this rev., a crash might occur when the user quickly
switched twice between pages (e.g. go to page 2, then page 3) on a
slow network.
In the given example, when data of page 2 returned, the list was
re-rendered. Unfortunately, the offset of that list' datapoint was
already changed due to the switch to page 3, meaning that the view
tried to render a page that wasn't loaded yet, leading to a crash
if there were modifiers to evaluate, or to empty records being
displayed.
This rev. ensures that the view is rendered with the data of the
page it expects.
closesodoo/odoo#30150
Start on the modal obtained by a "search more". The offset is never reset.
So suppose you are on page 2, looking at record 81-160.
Do a research that gives less than 80 records.
The result of the search is nothing, since is has been done with a 80 offset.
It should be reset to 0 when we do a new search.
opw 1920826
closesodoo/odoo#30109
Most operations on X2Many widget possibly propagates a field context
(name_create, name_search, ...) but the original read or read on an
onchange does not.
With this changeset, the field context is also used in these instances.
The assertions added in the added test failed with:
expected: ["world"], result: [undefined]
expected: ["world","world"], result: [undefined,undefined]
fixes#29203
opw-1914466
closes#29866
Before this rev., there was a race condition when the user did
some changes on a form view (triggering an onchange), saved and
clicked on the breadcrumbs to leave the form view (before the
onchange returned). As a consequence, the dialog telling the user
that there are pending changes was displayed. This mostly occured
on the main_flow_tour since the removal of an unnecessary check,
and could be reproduced manually on a slow network.
Basically, the check if there were pending changes was done too
early (before the view was actually saved).
This rev. fixes a concurrency issue in the kanban view spotted by
the Project tour and the removal of the delay in the tour system.
Let's assume the following scenario in a kanban view grouped by a
many2one field with at least one column and with the quick create
feature enabled:
- quick create a new column
- before the column is actually created, click on CREATE in the
control panel to create a new record
Before this rev., the record quick create widget was opened
directly, but as soon as the column was created, the view was
re-rendered, and the quick create widget was lost.
This rev. forces the column to be created (and the view to be
re-rendered) before opening the record quick create.
Before this commit, if a user tries to group a kanban view by a date or
a datetime interval, then tries to drag and drop a record from one column to
another, then the web client crashes. This is actually an invalid
operation, and is supposed to be disallowed. There is already some code
that properly handle the situation. However, the field attribute was
not properly read in the case of fields of type date/datetime.
Related to Issue: #1911975
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#30029
When a percentage if formatted, the decimal separator used is always
`.`, while it should be the decimal separator of the language.
opw-1908220
closesodoo/odoo#30030
Fine-tuning of commit e7fab23420
In a one2many with more than one page with a limit of k records, add a line l.
It increments the list limit to k+1. Remove a line above (of index <= k).
It will try to load a line l' to replace it, that it will find on page 2.
However when deciding if it should read missing fields on that record, it will
scan at most u records, skipping virtual ids.
Here u is the min between the current number of lines and the list limit
without the temporary increase due to the added record.
Since there are at least two pages, u = k.
However since l is in the list at index k, then l' won't be read, and since it
was on page 2 its data hasn't been loaded.
Therefore the js would traceback when trying to evaluate it.
opw 1913361
closesodoo/odoo#29338
Use case: a x2m (ex: attribute values) displayed in a x2m (ex: attributes on
product) using different fields in different views (ex: tags in product form view
and list in product attribute form view). When opening the x2m record (in a
wizard) then going back on the form view, the tags are empty because the
`display_name` value has been lost when fetching x2m for the second time.
In this case, the list `fieldsInfo` needs to be updated with the existing
(default for tags) one so all the fields will be correctly loaded.
Task 1916891
closesodoo/odoo#29598
The week_start has been added as an option since commit 27b30daea5.
This stores as a database parameter the day starting the week, [1.. 7] starting
on Monday, while the calendar options expect to get Sunday as 7 % 7 = 0.
As a result the week number would be shifted.
Commit c72403d2ba solved the issue,
this commit adds tests for it.
opw 1916666
closesodoo/odoo#29838
This commit removes the attachment button from the sidebar.
Reason:
following the introduction of the attachment button in the chatter (7f97c9fc05)
and the partial removal of this feature (1dbb555aab) in V12.0,
it has been decided that the chatter button will completely replace this feature.
closesodoo/odoo#29468
Since the control panel refactoring, the `context` key on a `<field>` in the
search view was ignored (like <field name='pricelist' context="{'pricelist': self}".
The previous behaviour has been reintroduced and modified a little bit.
For way too long, an ugly hack was used to get a numerical value in self. This
ugly hack was still present but wasn't working since 8.0 (at least for the
numerical value). A counter hack (see odoo/odoo@4a81e8a) was then applied to
avoid really using a `selection` widget. To get even more confused, `self` was
replaced by the *last* user-specified value.
Well, it's time to clean this mess.
Now, the `self` key is replaced by an array of user-specified values (by value,
we mean the field value i.e. the `id` for a many2one, or the `key` for a
selection field).
Task 1902826
closesodoo/odoo#30368
Original commit breaking kanban view: 4cd379cf6e
Commit reverted: 287136b85e
Two fixes were added independently to fix this bug but only one is needed.
odoo/enterprise@c8fe86fa22 best fix
287136b85e other fix (now reverted)
Reverting this commit fix the following bugs:
- Swipe on kanban : Not able to swipe on empty column. it only works on cards
- Popup activity on kanban card is unusable
- On kanban separation, "Undefined" cards are before the kanban separation
closesodoo/odoo#30177
Before this rev. a traceback occured when trying to export all records in a list
view.
An old reference to `searchView` was still present in the list controller, which
is not used anymore since the control panel refactoring (see odoo/odoo#29106).
Task 1917628
closesodoo/odoo#30073
The 'Actions' menu displayed in the control panel (aka sidebar, or
toolbar), wasn't displayed anymore since the control panel
refactoring of 4cd379cf6e. Rev. c1752b834 correctly made it appear
again in list and form views. However, there was another issue as
the additional model-related items (like Print, or custom actions)
weren't fetched anymore. Thus, the sidebar only contained the
default 'Export' and 'Delete' actions. This rev. fixes the second
issue.
fixes#29546closesodoo/odoo#29633
Before this rev. a crash occurred when pressing backspace in the control panel
view searchbar input if there was no facet to remove.
The use case is now correctly handled and nothing happens.
Task 1902826
closesodoo/odoo#29602
The `context` key wasn't correctly taken into account when computing the search
query for `filter``tags.
It is now correctly handled.
Task 1917628
closesodoo/odoo#29529
Mathieu Duckerts-Antoine