Before this commit, the pivot's dataSources were managed by the core plugin
`PivotCorePlugin`. This didn't make sense since dataSources aren't core data:
- they are neither exported nor imported
- they can be different for each user (their ids were generated via uuidv4
at import)
- managing them required to handle local command in the core plugin
Moved the dataSources management to the UI plugin `PivotUIPlugin` and moved
the relevant getters inside this plugin. Changed the ids of the dataSources
to be the same as the pivot's id + a prefix, to avoid having to maintain a
mapping `pivotId` <=> `dataSourceId` .
This commit also removes the dataSourceId from the `INSERT_PIVOT`
command, which have no place here since this is a core command and the
dataSources are now a pure UI concept.
This is slighly more tricky than for lists, because the datasource need to
be loaded before the `INSERT_PIVOT` command to fetch the table structure.
The component dispatching the command need to make sure it creates a
dataSource with the id given by the getter `getPivotDataSourceId`,
or else the dataSource will be loaded twice.
Task: 3293491
Part-of: odoo/odoo#120136
Before this commit, the list's dataSources were managed by the core plugin
`ListCorePlugin`. This didn't make sense since dataSources aren't core data:
- they are neither exported nor imported
- they can be different for each user (their ids were generated via uuidv4
at import)
- managing them required to handle local command in the core plugin
Moved the dataSources management to the UI plugin `ListUIPlugin` and moved
the relevant getters inside this plugin. Changed the ids of the dataSources
to be the same as the list's id + a prefix, to avoid having to maintain a
mapping `listId` <=> `dataSourceId` .
This commit also removes the dataSourceId from the INSERT_ODOO_LIST
command, which have no place here since this is a core command and the
dataSources are now a pure UI concept.
Task: 3293491
Part-of: odoo/odoo#120136
Steps to reproduce the issue:
1. Project> select Project > Task> List view
2. Studio list view > Add existing properties field
3. Go back to list view > Favorites > add to spreadsheet
4. New Spreadsheet > Will receive error
opw-3284273
closesodoo/odoo#120473
X-original-commit: 5eb80e34db2e54b56164ea4b98bea3cebb09312b
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
This commit adds YTD (year to date) filter to global period filters in
dashboard.
YTD filter gets the data from Jan 1st of the current year to
today (included). The unit of its offset is year.
task 3215947
closesodoo/odoo#118466
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
This commit includes the ongoing day in the current period filters.
Now the start date (time) of each period filter is the start of next day,
and the end date (time) is the end of today.
task 3267525
closesodoo/odoo#118326
Related: odoo/enterprise#39641
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Before this revision, a date/datetime field was displayed in UTC instead
of in the user timezone.
This revision fixes this issue.
opw 3127742
closesodoo/odoo#117623
X-original-commit: c07b450594f7e3e1f093d0b5a5a083f915f75310
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This commit fixes the problem of invisible borders when pivots and lists are
inserted. Now around headers and the total row, black borders are added.
task 3103403
closesodoo/odoo#117493
Related: odoo/enterprise#39218
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Using o-spreadsheet features and functions is done using
the same import module as if it was installed from npm.
Additionaly, by adding the library as dev dependency in package.json[1], IDEs can
now leverage Typescript types for autocomplete and type checking.
The "alpha" release tag is always the lastest master version.
[1] enable web tooling `addons/web/tooling/enable.sh` ;)
closesodoo/odoo#115972
Related: odoo/enterprise#38471
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
This commit refactors the current model structure of spreadsheet-related
module. Data fields are integrated into an abstract model
`spreadsheet.mixin` and all sub-models are inherited from it. This way
we can group all decode/encode logics into one place.
task 3222572
closesodoo/odoo#116498
Related: odoo/upgrade#4473
Related: odoo/enterprise#38692
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The last view in the odoo codebase has just been converted to owl,
meaning that we no longer have legacy views. This allows us to
remove a lot of legacy view related code: the abstract elements on
which the legacy views were built, the compatibility layers that
allowed to deal with both owl and legacy views uniformly, legacy
widgets that were only used in those legacy views...
closesodoo/odoo#114893
Related: odoo/upgrade#4420
Related: odoo/enterprise#38005
Signed-off-by: Géry Debongnie <ged@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>
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>
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>
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>
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>
The domain of the datasources was not recomputed on the deletion of a
filter that impacted it. Furthermore, the issue was also present when a
client would UNDO/REDO some revisions.
Task 3002004
closesodoo/odoo#104630
X-original-commit: 3b63d8d592482b655a4273bf9d5d98de3992d26a
Related: odoo/enterprise#33468
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
removeContextUserInfo was a Spreadsheet asset, which is not a dependency of
Knowledge.
In order to make this feature available for all modules, it is moved in web as
an object util, that needs to be used alongside the user service in order to
dynamically remove user context information (no hardcoding).
Task-3017349
closesodoo/odoo#104304
X-original-commit: fd88fc1bbad4c0cdb44cf634b6a5621eb7597e0d
Related: odoo/enterprise#33322
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
For the date filters with a default value set to "Automatically fitler
on the current period", the clear button don't work. It does not clear
the filter but revert it back to the default value.
The bug happens in the global filters side panel as well as in the
dashboards.
Odoo task 2989909
closesodoo/odoo#103270
X-original-commit: 27e58050aacf0ae525f1e1b6fec7b69133781312
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Minne Adrien (adrm) <adrm@odoo.com>
Field `measure` in `PIVOT.HEADER` functions are not actual res.model
fields but are used to display the fieldName of the measured field.
closesodoo/odoo#102979
X-original-commit: 6de4b2c4c058babb4e3ee0b60212aa4a9ccec119
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The global filters had to be aware of every type of datasources that it
affected (i.e. pivots, lists and charts). This commit introduces the
possibility for any datasource to register its type in an object handled
by the filters, making the latter agnostic of the different possible
kinds.
Task 2992752
closesodoo/odoo#102688
X-original-commit: b7dda98dfd2ee6973e2ca09b8c8ee7e8c43032a8
Related: odoo/enterprise#32526
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
After this revision, the core and ui plugins are clearly identified.
X-original-commit: c2aea83092cda1c95ebbef423ce265451f67babe
Part-of: odoo/odoo#102688
Before this revision, the fields of `partner` were not searchable, which
was not correct.
This revision fixes that.
Part of task-id 2987871
X-original-commit: 2c180660e412bd0f52da920bdf8f96b200fc3aa2
Part-of: odoo/odoo#102688
Allow users to use stacked line charts. The chart.js configuration
is mimicking the one inside Odoo community.
task 2888350
closesodoo/odoo#102312
X-original-commit: 1ccb2cd685c60eecd767eb15967d4b4c25262ded
Related: odoo/enterprise#32345
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Task Description
In some case, when trying to display the context menu on a
pivot cell (doesn't seem to impact PIVOT.HEADER), we get a
traceback caused by the arguments of the formula take into
account in the ´getFiltersMatchingPivot`, called by the
"isVisible" property evaluation of the "set as filter" action.
These errors only rise when using a pivot with "__count" as
measure and a positional argument.
Moreover, when trying to open the context menu with a filter
defined without any field, we get another traceback.
Reproducibility
The first issue can be reproduced with the following steps:
1. Go to the CRM app
2. Create a pivot view
3. Group the row by Country
4. "Ungroup" the columns (keep only the total)
5. Set "__count" as measure
6. Insert the pivot on a new spreadsheet
7. Edit the pivot formulas to use positional argument for country_id
8. Insert a new filter on the country field
9. Right click on a pivot cell
The second issue can be reproduced with the following steps:
1. Open a spreadsheet with a pivot
2. Add a filter related to the pivot but without any field matching
3. Right-click on a pivot cell
Fix Description
The first issue is coming from the fact we try to get the value related
to a field in the pivot formula using the 2nd and 3rd argument instead
of using the last two arguments of the formula. This is fixed by passing
to getPivotHeaderValue only the last two arguments of the pivot formula.
For the second issue, we simply check that the pivot field is defined
before looking at its name.
Related Task
task-2999181
closesodoo/odoo#102204
X-original-commit: 15e0c8aba57d4e0a8c58f288a4e96f0bc884736c
Related: odoo/enterprise#32303
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Odoo charts have a specific need of dataSources for their runtime data
(in oppostion to standard graphs). In order to link the chart with its
datasource, we injected the chart id inside its definition in order to
be able to fetch the corresponding datasource. Unfortunately, this
approach require that we can access the chartId from anywhere which is
unfortunately not the case when we copy/cut/paste a chart. The current
implementation would copy the chart while keeping a reference to the
same datasource, thereby keeping the same data and be submitted to the
same filters as the original chart dataSource.
Note that a chart should not be aware of its own id; that is, its place
in the mapping of a plugin.
This commit changes the approach to set the dataSource inside the chart
directly through a method only available on OdooChart instances.
This problem would also arise on sheet duplication but was due to a
problem in the library itself.
task 2998207
closesodoo/odoo#101660
X-original-commit: 47f7cc08bec749301001c6c4567cafbcea8bd552
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Copying an odoo chart gave a traceback since the method `copyInSheetId` wasn't implemented in Odoo Charts.
Odoo task 2987656
closesodoo/odoo#100748
X-original-commit: c26b8ee12857253c90b62b14c0a86c60457af4c2
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Minne Adrien (adrm) <adrm@odoo.com>
If you insert an odoo chart, match a filter with one of the
chart field, then delete the chart
=> the field matching is not removed and is still exported
The same goes for pivot and list matching when they are removed
closesodoo/odoo#100390
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Adrien Minne (adrm)