Steps to reproduce:
- create an empty spreadsheet
- type in a cell '=ODOO.BALANCE("qsdfqsf", "02/2024")'
=> #ERROR
There's no account that match the given code.
The account.move.line domain ends up having a clause
`('account_id', 'in', [])`
The ORM detects the domain won't match anything and
early returns an empty list []
Our code expects a query object and not a list => boom
opw-3872445
closesodoo/odoo#163444
X-original-commit: 95de1332196fde7bfa5d178c6c0b7995cd892acb
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce:
- in A1, type '02/2024'
- in A2, type '=ODOO.BALANCE("100", A1)'
=> the result you get come from account lines
for the day 2024/02/1 instead of the full
february month.
The value of A1 is detected as a number (first of february 2024)
When that number is given as the argument of ODOO.BALANCE,
the number falls back as being interpreted as a single day,
instead of a month period.
opw-3872445
closesodoo/odoo#163156
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This commit actually refactors the code of the accounting functions
to use `computeValueAndFormat` instead of `compute` which doesn't
receive the arguments format.
The goal is to make the actual fix in the next commit easier
to review/understant with minimal noise.
opw-3872445
Part-of: odoo/odoo#163156
Steps to reproduce:
- in A1, type '02/2024'
- in A2, type '=ODOO.BALANCE("100", A1)'
- right click on A2
- click the menu item "See record"
=> you end up with wrong records in the list view
The value of A1 is detected as a number (first of february 2024)
When that number is given as the argument of ODOO.BALANCE,
the number falls back as being interpreted as a single day,
instead of a month period.
opw-3872445
Part-of: odoo/odoo#163156
Steps to reproduce:
- wrap a pivot function inside a IFERROR e.g. =IFERROR(PIVOT("1", "probability"), 42)
- reload the spreadsheet
- before the pivot is loaded (throttle the network in the dev tools): right click the cell
- click on "See records" menu item
=> boom
closesodoo/odoo#162759
Task: 3847477
X-original-commit: aeadd065e869a5cd6b971d6d458ba9d8e1edcc1c
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
When the aggregated value is 0 (9000 + -9000 = 0), it displays an empty cell
in spreadsheet, instead of zero.
closesodoo/odoo#159148
Task: 3827502
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Get to a list view where there's a monetary field AND the related currency
field in the same list.
Then insert the list in a spreadsheet.
=> Either the currency format is not fetched or the currency name, depending
on the order in the list.
Bug introduced by 8777973e
opw-3770057
closesodoo/odoo#157623
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Replace the hardcoded date "09-15-2022" in the list domain by
`context_today().strftime(\"%Y-%m-%d\")`
The domain is now stringified since it contains a dynamic value
which is not valid in a json file.
closesodoo/odoo#156550
Task: 3756934
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps to reproduce:
- create a relational filter, let's say on `res.company`
- add a default value
- reference the filter in a cell with `=ODOO.FILTER.VALUE("my filter")`
=> every `ODOO.FILTER.VALUE` triggers an evaluation
With this commit, the re-evaluation after the data is fetched uses the
data source mechanism which only re-evaluates when all the data promises
are resolved, instead of evaluating after every resolved promise.
With this commit, the number of evaluations required when loading the
Timesheet report on our prod goes from 5 evaluations to only 3 (each evaluation
is 2-3s) because `ODOO.FILTER.VALUE("Company")` is present two times.
One issue this commit doesn't fix: there one RPC per `ODOO.FILTER.VALUE`
(can be fixed in master very easily because we refactored data fetching)
closesodoo/odoo#156495
Task: 3787125
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Turn your odoo user's language to "French (BE) / Français (BE)".
Now, let's say you have a pivot function returning an amount in the one million
(e.g. 1 230 000). It's formatted to "1.230.000,00"
Reference that cell with `FORMAT.LARGE.NUMBER`. The result is "1.230k"
Now hit the share button and open the share link in an incognito tab.
=> the cell is now "123m"
That's because the string "1.230.000,00" is wrongly parsed to 123000000
(to fix in o-spreadsheet).
Besides that, the formatted value may not necessarily be parsable.
With this commit, we export the raw value, stringified.
opw 3720586
closesodoo/odoo#154712
X-original-commit: 7f8d705b216b392ce1249793a0b44dcec0ac536c
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
With this commit, list data is loaded using `web_search_read`
instead of `search_read`.
The goal is to fetch the currency (symbol, decimal places, etc.) of monetary
fields in a single request, instead of 2 RPCs.
Pros:
- less code
- one evaluation saved
- one network request saved
- easier future refactoring (see below)
Cons:
- overhead of data transferred over network (from 4.5MB to 6.5MB, unzipped
and from 711kB to 725kB gzipped to fetch a list of 20K crm leads).
Before this commit, here is what it looked like:
1. the list data is fetch (with the currency_field)
2. the cells are evaluated with the new data
3. we realize we want to format a currency amount. We already have the
currency name but not the symbol, etc. So we fetch the currency data
4. evaluate the cells again with the new currency format
Now:
1. fetch the list data with everything we need for the currency
2. evaluate the cells
This commit also serves another goal for a future refactoring: in the hope
of avoiding throwing "loading errors", I'd like to have an easy way to know
if a data source is fully loaded or not (the data and the format).
With this commit, everything is centralized in the list data source with
a single RPC. The goal is therefore achieved with this commit.
closesodoo/odoo#153434
Task: 3730232
Related: odoo/enterprise#56253
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Most (if not all) dashboards have monetary amounts. They are formatted
with the main company currency format.
Before this commit, a RPC was made to fetch the company currency.
With this commit, the dashboard is loaded with the currency.
It saves one network request and a full spreadsheet evaluation (which would
have occured after the request is done)
closesodoo/odoo#151725
Task: 3709466
Related: odoo/enterprise#55415
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Pivot/list monetary fields needs the company currency to display
the value in the said currency format.
Until now, a RPC was made to fetch the currency.
However, since odoo/o-spreadsheet@8710839 and odoo/enterprise@8c0a785
the currency format is already in the model config.
There's no need for the RPC.
This saves one network request and one full spreadsheet evaluation (which
would have occured after the request is done)
Note: see next commit for dashboards.
Part-of: odoo/odoo#151725
- create a from/to date filter with let's say "my filter"
as its title.
- in the spreadsheet, `=ODOO.FILTER.VALUE("my filter")`
=> the function doesn't return anything
closesodoo/odoo#146213
Task: 3584650
Related: odoo/enterprise#52871
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The implementation to generate a sheet with the active filters
is (almost) duplicated for the Excel export and the sharing.
The next commit makes it more complex and in the goal of avoiding
to duplicate the changes, this commit factorizes the implementation
Task: 3584650
Part-of: odoo/odoo#146213
Steps to reproduce:
- insert a global filter with double quotes in its name (e.g. my "special"
filter)
- reference that filter with ODOO.FILTER.VALUE (remember you have to escape
the " in the formula with a backslash \
=ODOO.FILTER.VALUE("my \"special\" filter")
=> the filter is not found
closesodoo/odoo#153337
Task: 3697855
X-original-commit: 83826d3546ff584c5ff22021370f572787d032bc
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
How to reproduce
1. Log in as Mitchel and go to a Subscription dashboard
2. Copy the URL and paste in incognito
3. Log in as Marc (which does have access to the subscription dashboard)
--> Traceback
closesodoo/odoo#153143
Task: 3581647
X-original-commit: 1c4b6b0a491d63d1f1b6c7a21089a42d4bfd64ab
Related: odoo/enterprise#56107
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
When a char field contains a value which represents a number (e.g. "00036"),
the value is inserted as a number in the formula instead of a string.
Because of this, the function value is not found.
actual: =ODOO.PIVOT.HEADER(1,"x_studio_barcode",00003456799)
expected: =ODOO.PIVOT.HEADER(1,"x_studio_barcode","00003456799")
closesodoo/odoo#152018
Opw: 3623662
Task: 3631998
X-original-commit: 9fedd9a5c3daacb71862864ede466d25420749bb
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In a spreadsheet with multiple data sources (2 pivots), each data source
initially loads and triggers a new evaluation upon loading.
This results in two evaluations, even if both data sources resolve in less
than 10ms apart. In such cases, the first re-evaluation becomes redundant,
as a new one is immediately triggered.
The issue is worse when more than 6 RPCs are required, as most browsers limit
network calls to 6 in parallel. Consequently, the 7th RPC will unnecessarily
wait after the evaluation triggered by the first RPC to resolve.
For spreadsheets with many many data sources, the accumulation of these
pointless evaluations significantly impacts performance.
In a real-life scenario with 18 data sources from our production database,
the spreadsheet took approximately ~33s to fully load and become reactive.
With this commit, the loading time is reduced to ~7s (only one evaluation
instead of 18) (tested in 17.0).
Note that this testing was conducted locally, with minimal latency, and with
a limited amount of data.
One consequence of this commit is that cells won't load incrementally as
each data source loads. Instead, all cells will display "Loading..." until
all data sources are loaded. Given the substantial speed improvement, we
consider this trade-off worthwhile.
This fix only impacts loadable datasources (pivot, lists, graphs),
it could also include data sources using individual RPCs (currency,
accounting). Maybe for master.
closesodoo/odoo#150015
X-original-commit: 70877d29cc2368298f8716f64c248a86ed0416ce
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Currently, if you have a pivot grouped by a date field, aggregated by week
month or quarter, sorting all the pivot cells does not work as expected
when sorting based on the date header column.
"April 2023" would end up being before "March 2020" just because "A" is
before "M". Similarly, "W1 2023" is before "W2 2020" and "Q1 2023" is before
"Q2 2020"
With this commit, for months aggregates, the result of
`=ODOO.PIVOT.HEADER(1,"create_date:month","04/2023")` is currently the
string "April 2023".
The result now becomes a real date just like any other date value
in a spreadsheet. It's the number corresponding to the first day of the
month.
For week and quarter aggregates, we could move the year first ("W1 2023"
becomes "2023 W1"). However, we decided not to do it to keep consistency:
- with other places in odoo (pivot views)
- with the way we talk/think (quarter/week comes first)
closesodoo/odoo#139295
Task: 3570281
Related: odoo/enterprise#49300
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This commit fixes 2 very similar issue.
See enterprise commit.
- Group a pivot by any date field, with the day aggregate
- insert it in spreadsheet
- autofill a pivot function
=> the autofill tooltip displays the day number instead
of the day formatted as a date.
- on the same pivot
- click on menu "Data > Insert pivot > insert pivot cell > [you pivot]"
=> in the dialog, numbers appears for the headers.
Task: 3570281
Part-of: odoo/odoo#139295
This commit factorizes how the format is computed for ODOO.PIVOT and
ODOO.PIVOT.HEADER functions. It was essentially duplicated.
Also move the date(time) format responsibilty to each time adapters,
instead of handling the different aggregate cases separatly.
This commit also prepares the next commit which fixes a formatting bug.
Task: 3570281
Part-of: odoo/odoo#139295
For the ODOO.PIVOT.HEADER functions, "special" values such as measure and
total were managed in different places (total management was also duplicated
see enterprise commit).
Now the measure and total are managed in one place, in the high level method.
There's also now a dedicated method to get a measure display name. The method
`getGroupByDisplayLabel` was perverted at that purpose (see enterprise commit)
Task: 3570281
Part-of: odoo/odoo#139295
Method names in the pivot data source/model are not particularly clear
and self-explanatory.
To commit renames some methods (and their argument names) with hopefully
more meaningful names.
I'm also moving `getDisplayedPivotHeaderValue` (now
`computeOdooPivotHeaderValue`) from the model to the data source. It's
a high level function, the implementation can be in the data source.
Task: 3570281
Part-of: odoo/odoo#139295
- define a relational global filter without any default value.
- reference that filter with `ODOO.FILTER.VALUE`
=> when loading the spreadsheet, a `read` RPC is triggered
with an empty list of ids.
This is:
- useless network call
- useless evaluation when the RPC resolves
closesodoo/odoo#149741
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
- Inserting a cumulated graph view inside spreadsheet
(e.g. cumulated subscription MRR breakdown),
- apply a global filter to filter, let's say on the current
month
=> the first data point does not include data from before
the current month (the accumulation starts at 0, even though
there is data before)
You can also check the MRR evolution subscription dashboard,
"MRR over time" chart.
Note: with this fix, we assume all "cumulated" charts are also
"cumulated_start". Which is true in practice (only one cumulated
graph view in the entire codebase)
closesodoo/odoo#149084
Task: 3680601
Related: odoo/enterprise#54146
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The original issue (in saas-16.4) has been fixed in 17.0
by refactorings.
This commit only fw-ports the test
Steps to reproduce:
- Open the Subscription app
- click on the list cog wheel
- Spreadsheet > Insert list in spreadsheet
- Select the blank spreadsheet and insert the list
- right click any cell with a list function
- click on "See list properties"
=> boom `undefined is not iterable (cannot read property Symbol(Symbol.iterator))`
The list domain has the shape `["subscription_state", "not in", ["2_renewal", "5_renewed", false]]`
`false` makes the domain selector crash.
opw 3670344
closesodoo/odoo#148727
X-original-commit: cfdc9c6d62050e3aac4bf18f374e4772ce18a504
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Change your language and open any dashboard.
The table titles (e.g. "Top countries" of the Leads dashboard) are not
translated.
It was lost in commit odoo/o-spreadsheet@9616681
With this commit not all link labels are translated. Only odoo links.
I don't think other (regular) links should be translated.
closesodoo/odoo#146574
X-original-commit: a2e406db138d51e710caf61a2809cfa991ea6cb3
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
This commit is the communitiy counter-part to allow copying a dashboard.
Yet another 'copy' overrride to add the same postfix!
closesodoo/odoo#144091
Task: 3588237
X-original-commit: b39f63b1509e6dc2149b1a09da5a877d45e36be3
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
There's currently no way to move a dashboard from a section to another
You have to start again from a blank dashboard in the other group.
closesodoo/odoo#143505
Task: 3592986
X-original-commit: f7ba25afd5f1332b21a3d1631020ad9cd4b116fc
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Purpose
=======
This task answers two use cases making text filters more useful and easier to
use:
Always using the same few values
--------------------------------
The text filter allows to type any arbitrary text. However, some users will
always use the same few values. They will always again and again type the
same values, every time they want to set or change the filter value. That's
cumbersome. There's also a risk of making a typo while typing.
Parametric dashboards
---------------------
Some dashboards are built to be parametric (our business analysts do that a
lot). e.g. They put the measure field in a cell, then reference that cell in
PIVOT functions. If you want to have the same dashboard, but with another
measure: just update the cell with the new measure and that's it.
In read-only mode however, you can't update that cell :(
But you can mimic a variable parameter with a text filter. Create the text
filter, then get the filter value in a cell with the function
=ODOO.FILTER.VALUE("..."). Now you can update the cell value by setting
different values in the filter input.
However, you need to know exactly what value would be correct/valid for the
parameter. Typing any arbitrary text would lead to errors or unexpected
results. Business analysts can know that kind of technical stuff, but
lambda users don't. The solution is currently to duplicate the dashboard and
change the cell value with the exact parameter value you want.
Specification
=============
In the filter config side panel, allow the user to restrict the set of
possible values to values in a range of cells in the spreadsheet. Let's say
A1, A2, A3 contains Paris, Brussels, Berlin. If the user chooses A1:A3 in the
side panel, the text filter input is no longer a free text input, but becomes
a select with the 3 cities.
If a value from the range is selected, then the cell with this value is
changed to another value: keep the previous selected value selected.
display the values with their cell format but use their raw format for the
logic behind it (using the value as a cell value from ODOO.FILTER.VALUE)
closesodoo/odoo#139191
Task: 3554062
Related: odoo/enterprise#49204
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
In the dashboard action, when switching from dashboard to dashboard, the
size of the control panel flickers. That's because the Share button is not
displays while the dashboard is loading and it takes some place, making
the control panel taller when it's displayed.
With this commit, the Share button is always displayed (disabled when the model
isn't loaded). In addition to fix the size flickering issue, it's also less
things appearing/disappearing from the UI (less sapin de Noël)
closesodoo/odoo#138816
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
There's no need to recompute the table structure
every time. The pivot model is never mutated, we can safely
store the table.
closesodoo/odoo#138594
Related: odoo/enterprise#48910
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Allows to "See records" or "Set matching filter" on ODOO.PIVOT.TABLE
cell results.
(from the context menu in "spreadsheet mode" or by clicking on cells
in dashboard mode)
Task: 3318865
Part-of: odoo/odoo#138594
Everytime `getFirstPivotFunction` is used, the returned
args are evaluated.
This commit adds a getter which factorizes this behavior
that was repeated several times.
This getter is also more robust to EMPTY args AST.
Part-of: odoo/odoo#138594
The en_US default locale in o-spreadsheet is m/d/yyyy but it's mm/dd/yyyy in odoo.
Because of this mismatch, spreadsheets from the source code of odoo (dashboards,
templates) will have a small warning saying the spreadsheet locale and the user
locale mismatch.
That's because existing spreadsheet don't have any locale and the default one is
used.
This commit adds the locale to all o-spreadsheet json files.
Notes:
- we could have completely upgrade the json file format to the latest
o-spreadsheet version (version: 14), but just adding the settings is enough
closesodoo/odoo#139133
X-original-commit: 76f77f0bca6852846079f1fe0de6080554f96ac2
Related: odoo/enterprise#49148
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
`=ODOO.BALANCE("100,200", "2022")` works but
`=ODOO.BALANCE("100, 200", "2022")` does not work (notice the extra space).
With this commit, the account codes are trimmed.
closesodoo/odoo#138850
X-original-commit: 7fd3fd60cc7cd207626f49ba1cf40232ced9d4ff
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Currently, spreadsheet dashboards always display numbers with the en_US
format, no matter the user's lang.
That's because the locale is hardcoded in the spreadsheet source file, in
the source code (or it falls back to the default en_US locale if it's missing).
With this commit, we dynamically change the spreadsheet locale with the user's
locale when he loads a dashboard.
We can change the locale with every user because the dashboard is readonly.
It cannot create a giant mess with dates in various locales.
Limitation
----------
Since hardcoded date formats are not changed when the locale changes, dates
will keep the en_US format. However, most (if not all) dates in dashboards
are coming from ODOO.PIVOT and ODOO.LIST functions, which compute the formats
dynamically based on the current locale.
closesodoo/odoo#135119
Task: 3484002
Related: odoo/enterprise#47284
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
In HBA's demo sheet, `markAsValueUsed` goes from more than 2% of the total
loading time to less than 1%
closesodoo/odoo#138166
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Instanciating an error is very slow.
In HBA's demo spreadsheet, `_assertDataIsLoaded` takes up to 17% of the total
spreadsheet loading time.
With this commit, it's reduced to less than 2%
Part-of: odoo/odoo#138166
`getReportMeasures` is called repeatedly for every pivot function.
In HBA's demo spreadsheet it takes up to 30% of the loading time.
Part-of: odoo/odoo#138166
On HBA's demo spreadsheet, `parseGroupField` takes more than 3% of the total
loading time.
This commit reduces to less than 1.5%
Part-of: odoo/odoo#138166
Purpose
-------
Currently, views with a contextual filter/domain are not well managed: e.g.
Today Activities
=> domain=[('my_activity_date_deadline', '=', context_today().strftime('%Y-%m-%d'))]
My pipeline
=> domain=[('user_id', '=', uid)]
Currently, 'context_today().strftime('%Y-%m-%d')' or 'uid' would be replaced by
their values when the view is inserted into a spreadsheet.
If the view is inserted on the 1st June 2023, the date "01/06/2023" is
hard-coded in the spreadsheet.
Specification
-------------
Preserve the domain dynamic parts when inserted into a spreadsheet.
Implementation note: I force the readable format at export just to be sure it
exported that way, no matter the domain origin.
closesodoo/odoo#131874
Task: 3414027
Related: odoo/enterprise#45748
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The method is no longer used by the web client:
=> it should be private
See enterprise commit
closesodoo/odoo#133500
Task: 3483938
Related: odoo/enterprise#46460
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Previously, the dashboard action needed two RPC calls to be ready:
1. load the dashboard groups (with the dashboards ids in the groups)
2. load the dashboard display names
Now, with the new `web_sear_read` we can load both at the same time,
saving one http request.
closesodoo/odoo#134984
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This commit fixes two issues with the ´date´ argument for
the ODOO.CURRENCY.RATE function.
First, the helper to cast the date is `toJsDate`, not `toJSDate`. Using
the wrong function name obviously crashes.
Second, the date was actually given to the server as a full ISO datetime
string, including timezone (UTC).
For function `ODOO.CURRENCY.RATE("EUR","USD", "12-31-2020 00:00:00")`, we
actually sent to the server "2020-12-30T23:00:00.000Z" (Brussels local time)
Notice that it's the previous day!
The field of `res.currency.date` is a date field, so it doesn't make sense
to send a datetime.
Now, only the date is sent ("2020-12-31")
opw-3498115
closesodoo/odoo#136411
X-original-commit: 6a4b7e7f216dc9a6372f5cc382262ff09cb317f3
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
o-spreadsheet code isn't prepared to handle dark theme. At all.
There are hardcoded colors everywhere.
Until we have a proper way to handle dark theme (use overridable scss
variables, rely on bootstrap), we force light theme for all elements
inside o-spreadsheet.
The white background on the top bar was removed by commit
odoo/o-spreadsheet@4d93a99
Other changes probably from the new milk design
opw-3461191
closesodoo/odoo#132909
X-original-commit: aaa9ea5c6584a8f830d8313d2f26670bf5b34cef
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
See enterprise PR ;)
Property fields are not supported in spreadsheet.
In saas-16.2, it even completely ruins the entire list
if it contains one property field.
With this commit, until we support properly property fields[1],
we ignores property field when the list view is inserted
in spreadsheet
[1] in master, see task 3329490
opw-3284273
opw-3465243
closesodoo/odoo#132138
Task: 3329490
X-original-commit: ada541d6c4a8d0a5b515c4f1f7e9d71c54b992d5
Related: odoo/enterprise#45844
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
This commit improves the way months are recognized in pivot functions.
It also removes the use of `moment.js` which will be removed in the future
(see task 3391739)
Currently, months in a pivot function must follow a very specific
format.
It must be mm/yyyy
`ODOO.PIVOT(1, "amount", "date:month", "01/2020")`
Among other things: "1/2020" does not work, it must be prefixed by a
leading zeros.
Now, any date-like value would work:
month: "1/2020"
first of the month: "1/1/2020"
any day in the month: "1/2/2020"
using the DATE function: DATE(2020, 12, 1)
using NOW()
Future work: `PIVOT.HEADER` should return a the date as a number
when the date is a month. But it's currenctly quite a mess.
because we use the same method for a million things (`getGroupByDisplayLabel`).
Task 3413243
closesodoo/odoo#129782
Related: odoo/enterprise#44684
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Currently, the domain editor dialog doesn't handle domains like
[('foo', '=', uid)] if you don't provide the (user) context in the
component props.
Since this kind of domain is expected to work everywhere, the component
now uses the user context by default to evaluate the domain.
There's no need to provide the context everytime the component is used.
closesodoo/odoo#127565
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The domain component in readonly mode doesn't display dynamic/contextual
values.
For a domain `[('foo', '=', uid)]` the component displays "foo =" instead
of "foo = uid"
Part-of: odoo/odoo#127565
`isMatched` is always true, so it have little/no purpose and we can
remove this attribute.
closesodoo/odoo#127279
Signed-off-by: Adrien Minne (adrm) <adrm@odoo.com>
This commit adds an "Odoo" functions category in the top bar menu
"Insert > Function".
It allows to easily discover existing functions.
closesodoo/odoo#127372
Signed-off-by: Alexis Lacroix (laa) <laa@odoo.com>
Steps to reproduce:
Go to CRM pivot view, group create_date by week, insert into spreadsheet.
=> week numbers are offset by one (W23 instead of W24)
Since 3a177c448, `read_group` returns week aggregates according to the
user's language first day (e.g Sunday for en_US, Monday for fr_FR).
Before the commit, it was always Monday (ISO week start).
This commit changes the moment formats from "W" (Week of Year (ISO)) to
"w" which is the localized week of year*.
Note there can still be some inconsistencies if the browser language is
different than the user's language. This hasn't changed and is a regular
known issue.
* https://momentjscom.readthedocs.io/en/latest/moment/04-displaying/01-format/
opw-3372581
closesodoo/odoo#127089
X-original-commit: c5738479dc1c1879a9ac0169e1ec87eb5098c525
Related: odoo/enterprise#43516
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Followup of #123320
Some things changed in saas-16.2
closesodoo/odoo#125706
X-original-commit: 82f79027deb8caa1e25e0ae8389f513db98cd6cd
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Currenlyt, when using dark theme, spreadsheet is a mess. It's mostly
light theme, with some dark theme elements (mostly coming from odoo
components). There's even inputs where the text is white on a white
background.
o-spreadsheet code isn't prepared to handle dark theme. At all.
There are hardcoded colors everywhere.
Until we have a proper way to handle dark theme (use overridable scss
variables, rely on bootstrap), we force light theme for all elements
inside o-spreadsheet, including odoo components.
The css rules aren't pretty, but at least the spreadsheet is usable.
opw-3329765
closesodoo/odoo#123359
X-original-commit: 37a5f6a5b4b8ecbacf7a8ce4be822c6f348eb5da
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
This commit allows to share spreadsheets to other users (public, portal or
internal without the required access rights)
See Enterprise commit. This commit prepares the ground to sharing
`documents.document` spreadsheets.
(I expect dashboard spreadsheet sharing in the near future which will
use the same generic code)
The challenges of sharing odoo spreadsheets
-------------------------------------------
Odoo spreadsheets can have any data from the database.
ODOO.PIVOT and ODOO.LIST functions specifically can target *any model*
and *any field*.
The values are dynamically loaded with RPC calls when the
spreadsheet is open. Normal access rights apply to load this kind of
"embeded" data.
A user can open a spreadsheet if he can read the `documents.document` record,
but odoo specific functions might result in errors if the user doesn't have
the access rights on the underlying model.
That's obviously not what we want when sharing a spreadsheet to an external
person. We want this person to see the values and not a spreadsheet full
of errors.
Giving access to external user?
---------------------------------
Users must have a very clear understanding what they are "leaking" when
they share a spreadsheet. Sharing a spreadsheet should not open any door
the user wouldn't think of or wouldn't understand.
The best way is to be very strict with the data we are sharing.
That means: only the specific models, specific fields and specific records
visible in the spreadsheet by the user who is sharing (different users can
see different values for the same spreadsheet, depending on their access rights).
We also want to consider the following scenario:
Alice is a newcomer (with very limited access rights) and she shares a
spreadsheet to a customer. A few years later, she is manager and has a
lot more access rights (groups, ir.rules, etc.).
The forgotten spreadsheet shared years ago should not leak more data because
Alice now has access to all company data.
Specification
=============
With all those challenges in mind, here is a first approach of shared
spreadsheet:
Readonly freezed spreadsheet for external users
-----------------------------------------------
When sharing a spreadsheet, we actually copy and freeze the spreadsheet at that
time. Odoo formulas are replaced with their value. This is the easiest and safest
way to deal with access rights to other models: there's no access to other
models at all ^^
The spreadsheet is displayed in readonly since it would only be editing a copy.
If the external person wants data to be updated, he can ask a new sharing link.
Read/Write for internal users
-----------------------------
The situation for internal users is different. We can rely on their actual access
rights.
When an internal user opens a spreadsheet sharing link, he is redirected to the
regular spreadsheet client action. A token is used to read/write the
`documents.document` record (and other linked models such as `spreadsheet.revision`),
but the data for pivots, lists, etc. is loaded with the user's own access rights.
If the user doesn't have the rights to read a model or field, the function results in
an error and that's the expected behavior.
This sharing strategy is perfectly fine for all spreadsheets that doesn't contain
any odoo data (think of all the Google Sheets we receive internally by email to
register to an event or any other stuff).
Future work
-----------
From a functional point of view, the spec is far from perfect.
Users would probably expect the data to "update" itself (not freezed).
People will want write access for external users as well.
Given the complexity of getting it right (from a tecnical, security and functional POV),
this is left for a later work
closesodoo/odoo#114040
Task: 3045808
Related: odoo/enterprise#37687
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The `sale.report `field `is_abandoned_cart` is moved from module
`website_sale_dashboard` to `website_sale`.
This allows to use it in the eCommerce dashboard in the community edition.
Task 3222991
closesodoo/odoo#121165
Related: odoo/enterprise#40979
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Database: Runbot 16
Exact steps (or video) to reproduce the issue (on runbot):
Dashboard
Sales
Select Last seven days
The figures do not include today
Remove the filter
The Order now shows but the Quotations is at zero. In the Top Quotations and Top Sales Orders sections we can see there is one of each, but the quotation
doesn't show
opw-3251869
closesodoo/odoo#120740
X-original-commit: 6ca41c4266f63ae629307330241aad810bbc950f
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
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>
In the Invoicing dashboard, the "Average Invoice" scorecoard displays
the wrong amount of invoices. It displays the number of
"account.invoice.report" lines.
This commit fixes the issue by displaying the count_unique measure
of "move_id"
task 3180524
closesodoo/odoo#120322
X-original-commit: 6232896fe06640de6d461e645811673fe27481aa
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce:
- Open any listview (e.g Sales order listview)
- select records from the listview, go to Favorites, and click on 'Insert list in spreadsheet' option
- Once the spreadsheet is created, Reload your browser.
Current behavior:
- Spreadsheet goes to an infinite loading.
opw-3284058
closesodoo/odoo#119561
X-original-commit: 6993d3e36d2f2540100e1bd248b629cc9e191659
Related: odoo/enterprise#40234
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
In the Dashboard app, expenses KPI amounts are currently expressed in the
currency they were made in, but with the currency symbol of the company
currency. It also means amounts with different currencies are aggregated.
We want the KPI to be expressed in the company currency and not in the
expense currency.
Note that even with this commit, the amounts are still mixing different
currencies if multiple companies are active
Task 3266092
closesodoo/odoo#119264
X-original-commit: e579ec5b3794d545676accdd23428557b75d05fa
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Commit odoo/enterprise@4bbf70f was fixing a timezone issue. Datetimes coming
from lists inserted in a spreadsheet were always displayed in UTC.
However, this commit also changed the formatting behavior.
Before the fix: date/datetimes were dispalyed with the server format
After: they are displayed with the local format (FR if the user lang
is French)
This can lead to issues because spreadsheet only understands a
handfull of date(time) format.
For example, it doesn't understand dd/mm/yyyy format but only
the other way around (mm/dd/yyyy)
This commit restores the previous format (server format), while
preserving the timezone conversion.
opw-3251586
Manual forward-port of odoo/enterprise#39438closesodoo/odoo#118285
X-original-commit: bf84195bce4fbea55d1a4e6a6cd9f17d9be86b73
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
In the Invoicing dashboard, the upper-left most scorecard displays the total
invoiced amount.
The baseline "X unpaid" is wrong. It was displaying the difference between
the key value (total invoiced amount) and the unpaid amount.
That means if not a single invoice was paid (everything unpaid), it would
display "0 unpaid". That obviously not correct.
opw-3248761
closesodoo/odoo#118030
X-original-commit: 2b795ee59ef063b5b7298382008ebd61c51de36e
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Install `l10n_au_keypay` on a fresh database, run the tests:
two tests in `spreadsheet_account` fail.
They wrongly assumed the last fiscal day of the main company is always 31th December.
This is not true with the module mentioned above installed since
https://github.com/odoo/odoo/commit/65dacfc17bec5feba1216354c71ca542c1b762b2
(look at `chart_template.py`)
Runbot build errors: 19796, 19797
closesodoo/odoo#117419
X-original-commit: a8d28ef16318df7d42c93265580a8e5dbc75cb1d
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
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>
Lucas Lefèvre (lul)