Now the promise waiting for all async no longer relies on a setInterval.
It was a hack that can be better solved by listening to the data sources
event.
closesodoo/odoo#114348
X-original-commit: de1f42f98410bc796dfdbfd237b1e20be4496166
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Earlier, receiving data was size of the file which is not what we
want. And we are trying to decode that as they are in binary form. Which
can not working properly.
So refactor code accordingly.
Task - 3162824
closesodoo/odoo#113953
Related: odoo/enterprise#37650
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The orderByToString function has been duplicated in spreadsheet. We will
replace it with the one defined in web.
closesodoo/odoo#113873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Insert a list view in a spreadsheet
- Cut & Paste the entire list to a new sheet
- On the first sheet, insert a formula, `=SUM()` which sum many records of the list
- Click on `Clear history` in the file menu (to force a snapshot and a reload)
=> There are one RPC by number of records in the SUM function, with the
limit increased by 1 each time.
The record limit (the bigger record index) is computed during the
evaluation. With a normal case, the evaluation goes through all the
cells of the viewport, collect the biggest record index, and trigger the
rpc after that.
However, in our usecase, the evaluation is not passed on the second sheet
(the one which contains the list view), so the limit is not computed.
When we evaluate the arguments of the `SUM` function, we evaluate each
argument one by one. So we evaluate a `ODOO.LIST` formula, the limit is
lower than the previous limit, so the function returns an error.
But when evaluating the arguments of a function, we stop the evaluation
as soon as we find an error. So the evaluation of the `SUM` function is
stopped, and the limit is not entirely computed.
So the first RPC will have a limit 1, then the evaluation is re-run, a
second RPC is triggered with a limit 2, and so on.
This commit fixes the issue by preloading the limit during the import of
the data and during an UPDATE_CELL.
opw-3165458
closesodoo/odoo#113789
X-original-commit: 1c5a05198542b3a40c97443b2a9ecf5fb32eb5f2
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Set the user timezone to Australia/Sydney (GMT+11)
Set your computer's timezone is US/Arizona (GMT-7)
Insert a pivot view grouped by a datetime field (e.g. create_date),
The dates are messed up.
The server returns midnight in Sydney, as UTC as always in odoo
2023-01-01 00:00:00 in Sydney is 2022-12-31 13:00:00 in UTC
Since midnight in Sydney is still the previous day in UTC, we
have to convert the datetime to the original timezone to get back the
local date (2023-01-01).
If the user timezone and the computer timezone are different, using
the computer timezone is wrong because it will yield the time in
Arizona.
When it's midnight in Sydney (2023-01-01 00:00:00) it's 2022-12-31 06:00:00
in Arizona.
This is not the same day!
opw-3170077
closesodoo/odoo#113740
X-original-commit: b2f760cae74201d1622e56a0027dae67dcff9e33
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
With this revision, the label of the field of the first row groupby is
inserted as the row title.
Task-id 2901960
closesodoo/odoo#107220
Related: odoo/enterprise#37395
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The filter can be assigned in the history directly with its
"id". No need to copy the object
closesodoo/odoo#112309
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Date fields are changing format if you type it in instead of using the
date selector calendar popup
Steps to reproduce:
1. Install Time Off
2. Open the current language and change the date format to `%d.%m.%Y`
3. Go to Time Off > Approvals > Allocations
4. Create a new allocation
5. Change the validity period to 10.03.2023 (by typing it in, not using
the datepicker) and click out of the field
6. The date displayed is changed to 2010/03/20 or 20.03.2010 (if the
datepicker was opened)
Solution:
Add dot and comma as a possible character for static format
Also deduplicated function isValidStaticFormat so we have a single
definition
Problem:
Formats using dots were not considered as valid static format so the
value entered was parsed with the format `yyyy/MM/dd` instead
opw-3081268
closesodoo/odoo#112218
X-original-commit: 18d6944510b55a4de21be050b8fef327f00e71d5
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Up until now, the collaborative expected a field named `raw` containing
the serialized json data. This is historic and appeared because the field
containing the existing field `raw` on `document.document` contained this
data.
The name `raw` is meaningless. Now the collaborative expects a field
named `spreadsheet_data`.
I chose a field over a custom method because fields are more broadly
supported everywhere (web client services, web client mocks)
closesodoo/odoo#104167
Related: odoo/upgrade#4005
Related: odoo/enterprise#33246
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When the data takes longer to load, the UI is blocked with the loading
overlay.
Now the data is loaded in the background and we can still navigate
in the spreadsheet.
Note: I moved the `.silent` upper in the call chain. Lower level structures
such as ServerData, DataSources, MetadataRepository don't need to know.
closesodoo/odoo#110387
X-original-commit: 8b09c7347ebeffa7059ed0ccc63f73e3559b7712
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce:
- Edit CRM -> Leads dashboard
- Edit filter "Period"
=> There is no period offset for the pivot 2, 4 and 6, despite the
fact that these pivots have a period offset defined in the json
data
This is because the field matching migration was not correct. It did
not take "offset" field into account.
Task-id 3138590
closesodoo/odoo#110221
X-original-commit: 2217c10ba771ece4a4d0d0485ce2f24b13754244
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
We were trying to evaluate the domain of a date filter when no chain was
provided in the field matching instead of returning an undefined domain
like for the other types of filters.
Task 3114332
closesodoo/odoo#110131
X-original-commit: 6eddb4b684d5c233b650f86fd8b26dcb8af4ca2d
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Currently, a user opening a spreadsheet containing pivots/lists/graphs
that they don't have the rights to access (be it because of the parent
model or the domain applied) will end up in an infinite loop.
While starting the datasources, the fetch step will throw, potentially
spamming the user with access errors.
Manual forward port of https://github.com/odoo/enterprise/pull/35146
Task 3107650
closesodoo/odoo#110113
X-original-commit: 1555e79be0b52c30df43e8de50f5db56fbbda630
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Since d6a1aa63702132ffc59d2412c2a009912eba797a, a name get saved from the result of a pivot was
stored with an incorrect `deferred`. The value stored was not the
deferred, but the result of `new Deferred().resolve`, which is
undefined.
This revision fixes this issue by storing the correct deferred.
closesodoo/odoo#109472
X-original-commit: b3ad5ee64865dc7a3b84cae18cd37002f6d69a91
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
1. Insert a pivot in a spreadsheet
2. Create a global filter on a field of the pivot
3. With a slow network, change the value of the global filter quickly
twice.
Two concurrent requests are sent to the server.
When the first one resolves, it marks the data source as loaded.
However, at this point, the model (`this._model`) is no longer the one
created by the first request. It's the one created by the second request
which is still loading and has no data.
We end up with a data source which is marked as loaded but has no data.
Task 3120203
closesodoo/odoo#109118
X-original-commit: 7cf02cedac189729af732faae02ec6195af26e5c
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Rendering the clickable cells is not a negligeable operation.
And it happens at every rendering (every scroll operation).
Especially, detecting which functions the cell contains.
The slow operation is parsing formula.
On the "CRM Leads" dashboard, depending on the visible cells:
closesodoo/odoo#109085
Before: 10+ms (almost the full 16ms allowed to reach 60fps)
After: ~2-3ms
X-original-commit: f132145c941ca79960aa697d6e98e4ee5193150d
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce the issue
-Go to Document and create a spreadsheet document SD (for example Sales Commission)
-Display SD and notice that there is some data in it
-Add lang Czech and set it on your profile
-Display SD
Bug:
There is no data in SD
The issue arise because `read_group` values are already translated to
the user's language.
e.g. let's we group by `create_date:month`, in Czech, we get
`"create_date:month": "září 2022"` (september 2022).
The previous strategy to map the `read_group` result to the PIVOT functions[1]
was to let momentJS parse the result, then format it to the PIVOT function format.
However, we can't realistically assume momentJS can parse any date in any language.
About the adapted tests:
The tests were actually wrong because the mock server is also wrong.
The mock implementation of `read_group` returns days formatted as "2022-09-08" ("yyyy-MM-dd")
instead of "08 Sept 2022". Because the business code didn't expect this format,
it resulted with wrong values.
See odoo/odoo#105546
[1] PIVOT function argument is "09/2022" for september 2022
opw-3052858
closesodoo/odoo#109026
X-original-commit: efb59010e3029ff4d5c77c0b2402093c8df4c44e
Related: odoo/enterprise#35395
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, the test "field matching is removed when filter is
deleted" failed on 2022 to 2033 year's transition.
Now a patch date is added to avoid the test to be time dependent.
closesodoo/odoo#108947
X-original-commit: 9d08a20d4c84c45799f766529d054b7df8fe0d66
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Breaking on 2022->2033 transition
Those tests should be adapted to work without hardcoded dates.
closesodoo/odoo#108884
X-original-commit: 6945966b49a58ce3c0976dce37e324b37af8367a
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit allows to download a spreadsheet with active filters
without any crash.
Commit https://github.com/odoo/odoo/commit/509bda2202df9f0f582fd020d96e8e1310b9abc7
was a first attempt to fix the issue.
But the commit was wrong because an empty sheet for excel is not the
same as an empty regular sheet. The `charts` property is missing and
the excel would crash when trying to read it.
Task 3102330
closesodoo/odoo#108603
X-original-commit: 0db14f258c31366ab53728735b4d31b4576c5269
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Before this revision, the pivot table was not autoresized when group bys
contains a many2one or a many2many field as it required an extra
request to get the name_get of the values.
With this revision, the values of the relational fields are extracted
from the pivot model in order to save an extra request.
Note: this fix is not ideal as it introduce a dependency between the
pivot model and the server data source. However, it is the best
solution in a stable version.
Task-id 2928601
closesodoo/odoo#108527
X-original-commit: d6a1aa63702132ffc59d2412c2a009912eba797a
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this revision, the callback passed to the constructor of
BatchEndpoint which should be called when there is an error when
fetching data was not called.
Part of task-id 2928601
X-original-commit: 6b4d5e4274c7644f9fda40c96f6b08a6bfd9ff37
Part-of: odoo/odoo#108527
Currently, a user could create a date filter without selecting a field
for a datasource but still select an offset. Notwithstanding the
traceback that ensues, this does not make sense from a a functional POV.
This commit adds a command check to prevent the creation/update of
filters with such payload.
How to reproduce:
From a sheet with a pivot:
- create a date filter
- do not set field
- set offset to any (non null) value
- Save the filter
=> trackback
Task 3002282
closesodoo/odoo#107485
X-original-commit: 0412186a675960a8f4a83398cf95c628203aa3fa
Related: odoo/enterprise#34799
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this revision, the currency fields of monetary fields of a list
were not preloaded when the list was loaded. This was causing a double
rpc, a first one to get the list data, and a second one to get the
currency data.
With this revision, we preload the currency fields of monetary fields
of a list.
task-id 3095937
closesodoo/odoo#107591
X-original-commit: a2d5fc517d460ccf5c17611de023a219dfadf7ad
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
auto_install is Falsy by default
author is Odoo SA by default
summary & description are empty strings by default
application is False by default
test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content.
closesodoo/odoo#106686
Related: odoo/enterprise#34462
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The style was using hardcoded css values for its button. unfortunately,
since it was not based on global varialbes, the colors are now outdated.
Task 3047620
closesodoo/odoo#105889
X-original-commit: 777a831cd7e3096de9421c224e192ef7c718c77f
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Task Description :
When right-clicking on a cell in a pivot with no matching records
and a positional argument, we get the following exception :
TypeError: Cannot convert a Symbol value to a string
This is coming from the fact we try the get the nth records
associated to the positional argument, but in a case where
there is no associated records.
Reproducibility:
This issue can be reproduced with the following steps :
1. Open a pivot
2. Change some cell to add a positional argument
3. Set a filter so that no related records can be found
4. Right-click on the previously changed cell
Related Task:
task-3009982
closesodoo/odoo#105733
X-original-commit: 4595bed9493b0b4b9a3c5f5ff14a71a9cd59ad95
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Since the revamp of the pivot datasource (Odoo task 2779455),
The data stored in the pivot table did not match the format of the
pivots formula arguments. I.E.
A formula mays contain arguments under stringified version or not
```
=PIVOT("1","field","false", "m2m_id", "42")
```
or
```
=PIVOT(1, "field", "false", "m2m_id", 42)
```
but they are stored in their non-stringified version in the table.
Going from stringified to the original value is not possible, we
therefore now store the stringified values in pivotTable and
stringify the formula arguments when required.
Task 2946479
closesodoo/odoo#105732
X-original-commit: ad0b24cb7b80c22c57091254d4161326fbc07adf
Related: odoo/enterprise#33934
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Lucas Lefèvre