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>
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>
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>
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 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
- 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>
A date filter with an empty value would still create a domain filtered
on the current year instead of being bypassed.
closesodoo/odoo#148984
Task: 3668916
X-original-commit: 763f88e2d45cb7ba107db135eecd0365ba2b8c8b
Related: odoo/enterprise#54095
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
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>
This commit modifies the functioning of `ODOO.PIVOT.TABLE` formula when the
boolean `includeTotal` is set to 'false'.
Earlier, total values of both row and column were not displayed in this case.
But now, if a groupby is not applied on any of the two dimensions, it displays
total values of the dimension on which groupby has been applied.
Otherwise the formula serves no purpose since it doesn't display any
data.
For example, one row groupby and zero column groupbys are applied on pivot:
The formula `=ODOO.PIVOT.TABLE(1,,false)` would display all cells of pivot
(including the row totals), except the last row (i.e. the column total).
Task ID : 3580623
closesodoo/odoo#140970
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce:
- Insert a list/pivot in a blank spreadsheet from a module (say Sales).
- Apply a global filter on it.
- Insert an odoo chart in the same sheet but from a different module (eg. CRM)
This works just fine when chart is inserted from the same model because it matches
the existing filter (from the pivot/list), and directly returns that field matching
without check the field matching from charts.
However in case of different model, the issue is that when there are no charts in the
sheet, the existing code of `getOdooChartIds` retrieves the incorrect chart ids
(`getChartIds` getter returns all chart ids, including the id of chart being inserted).
This leads to a traceback as the code tries to fetch fieldMatchings for a non-existent
chart within the sheet.
This commit resolves the issue by modifying the `getOdooChartIds` method to now utilize
`this.charts` instead of `getChartIds` getter, which correctly provides the ids of
charts already present in the sheet.
Task ID: 3573402
closesodoo/odoo#140700
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
In order to identify an ODOO.PIVOT.TABLE formula cell, we set the
display name of the pivot as the evaluated value of the cell containing
the formula.
closesodoo/odoo#140674
Task: 3580153
Related: odoo/enterprise#50003
Signed-off-by: Rémi Rahir (rar) <rar@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>
If a chart was linked to an odoo menu, but the odoo menu didn't have
an action, the user would get a traceback when clicking on the chart.
This commit:
- Improves dashboard validation. Now we test that the menu is linked
to an action, in addition to testing that the menu exists
- Send a "danger" notification when the user clicks on a chart with
a menu without an action linked to it, rather than a traceback
closesodoo/odoo#139324
Task: 3563450
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
In the goal of simplify assets loading, in this commit we create a new
assets bundle for chartJS and its luxon adapter.
With this, we can now use loadBundle instead of load these two libraries
with loadJS.
task-3562357
closesodoo/odoo#139544
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Adds in date type global filters a new category
"From / To" allowing to define a domain between
two dates.
closesodoo/odoo#138507
Task: 3516362
Related: odoo/enterprise#48855
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Most tests that need the user id simply use `uid=7`, which will fail
if the default user id ever change in the tests. This commit replaces
it by `sessuin.user_context.uid`.
closesodoo/odoo#138733
Task: 3553122
Related: odoo/enterprise#48965
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
When importing a pivot with a date field in week format, the date was
formatted as "W2023 40" instead of "W40 2023".
closesodoo/odoo#137682
Task: 3539629
Signed-off-by: Lucas Lefèvre (lul) <lul@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
This commit introduces a new pivot function:
ODOO.PIVOT.TABLE(<pivot_id>, [row_count], [include_total], [include_column_headers])
Purpose
-------
It answers several current limitations:
- The pivot in spreadsheet not being "dynamic" (growing as new groups/records
are created) is a *very* frequent feedback
- sorted pivots are very cumbersome (# syntax) and takes a lot of cells
- cannot easily compute arbitrary aggregates (max, avg). You only get the
total. ... as soon as new groups appears that are not reflected in the
spreadsheet, you can't guess data is missing and that it's not taken into
account.
Specification
-------------
Add a single and simple function =ODOO.PIVOT.TABLE(<pivot_id>) that would
display the entire table (dynamic, as more groups and records are added).
We can achieve almost everything we want:
- by combining with other functions (INDEX, CHOOSECOLS, CHOOSEROWS, XLOOKUP,
...) if we want to target a specific row or column.
- by using infinite ranges (e.g. =MAX(B2:B)) to account for a growing table
- we could remove all the positional PIVOT version of the function
(=ODOO.PIVOT.HEADER(7,"#country_id",1)). The implementation is a mess
(lots of ifs everywhere to account for the #). Just replace it by a single
function SORT(ODOO.PIVOT.TABLE(1), 1) (or with NSORT, or sorted from the
pivot view directly)
For some situations though, there would be the "Totals" in the way:
if you want =MAX(ODOO.PIVOT.TABLE(1)), you don't want to have totals in the
way (with infinite ranges). We add an optional parameter 'include_total'
(default to true)
For dashboards, we want to have custom header names, we don't want to use
the headers from the pivot. To only have data and not the headers:
new parameter 'include_column_headers' (default to true)
All in all: here is what it looks like:
ODOO.PIVOT.TABLE(<pivot_id>, [row_count], [include_total], [include_column_headers])
Task: 3318865
Part-of: odoo/odoo#138594
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
This commit removes the default exports from the spreadsheet module.
They don't bring anything except confusion when importing a mix of
default and named exports.
closesodoo/odoo#139071
Task: 3559536
Related: odoo/enterprise#49129
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Fixed cumulative attribute not passing from odoo and also added a checkbox to
the odooLineChart side panel, enabling users to easily switch between cumulative
and non-cumulative display modes.
the chart shows cumulative data, offering a comprehensive view of data progression.
Deselection displays regular non-cumulative data.
Task-3420844
closesodoo/odoo#138708
X-original-commit: 90eeb7318a6ac1b0d1a4a41715f3a895f3d5d8b6
Related: odoo/enterprise#48954
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
When the side panel of a pivot is opened while the side panel of
another pivot is already open, the datasource of the first pivot is
used instead of the datasource of the second pivot. This can lead to
tracebacks, or to wrong data being displayed.
closesodoo/odoo#138338
Task: 3463289
X-original-commit: b6df2d807f7ffe0f0f89d894307e31d779f138e2
Related: odoo/enterprise#48775
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Adrien Minne (adrm) <adrm@odoo.com>
This commit allows to reorder global filters via drag and drop. The
fact that global filters have a concept of order means that the
structure of the global filters in the core plugin need to change from
an Object<string, GlobalFilter> to an Array<GlobalFilter>.
closesodoo/odoo#135869
Task: 3502684
Related: odoo/enterprise#47583
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The commands `ADD_GLOBAL_FILTER` and `EDIT_GLOBAL_FILTER` had the filter id
once in cmd.id, and once in cmd.filter.id. This made it possible to send
a command with 2 different ids, which can have arbitrary behaviour depending
on the implementation details of the command.
Changed it so we only use cmd.filter.id, and removed the cmd.id field. Also
simplified the commands helpers for the tests.
Task: 3502684
Part-of: odoo/odoo#135869
Task Description:
This PR aims to add the possibility to edit the evaluation domain of
an Odoo chart, the same way it can currently be done for other
datasources like `List` or `Pivot`. This revision ensures that the chart
datasources are properly reloaded their domain update.
closesodoo/odoo#135242
Task: 3384872
Related: odoo/enterprise#47336
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Previously, when users selected the month or quarter filter and saved
it, the filter would only return data from the current year. This issue
has been fixed in this commit.
Merge the month and quarter data filters into a single month/quarter
filter. This will allow users to select a year which behave as year filter.
If a user only selects a month or quarter, the filter will work accordingly.
The year filter will be removed, as the month/quarter filter can now
be used to filter data by year.
In addition, a checkbox will be added to the relation filter that will
allow users to automatically select the current user. This checkbox
will only be displayed if the model is res.users.
closesodoo/odoo#126935
Task: 3370627
Related: odoo/enterprise#43426
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
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>
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>
- When a new pivot is added, and if the user has already defined
field matching in a previous pivot, the new pivot will inherit the
field matching from the previous pivot as default values.
- If multiple pivots are added from different models, will check the
model of the new pivot against previous pivots. If the model matches,
the field matching from the matching previous pivot will be used. If
no matching model is found, the field matching will be left empty.
- Same will also done in case of list and odoo chart.
closesodoo/odoo#135841
Taskid: 3373163
Related: odoo/enterprise#47570
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>
Change version of Chart.js from V2.9.3 to V4.3.0
You can find changelog on
https://www.chartjs.org/docs/latest/migration/v4-migration.html
Version 4.3.0 of chart.js no longer uses moment.js. This task is a
prerequisite to completely remove the use of moment.js (task 3391739)
Why add aspectRatio : 2 ? => Canvas aspect ratio (i.e. width / height,
a value of 1 representing a square canvas). Note that this option
is ignored if the height is explicitly defined either as attribute
or via the style. The default value varies by chart type; Radial charts
(doughnut, pie, polarArea, radar) default to 1 and others default to 2.
Why no more Chart.animationService.advance(); ?
There is no longer an equivalent in this version.
However, we have verified that the problem is no longer present in this
version.
Why use now getElementsAtEventForMode ?
It's clearly noted in the changelog. follow the link above.
task-3392075
Part-of: odoo/odoo#127259
This commit introduces models related to sharing dashboard, and
implements the sharing from dashboard view.
The basic idea is the same as sharing normal spreadsheet. The major
difference is that sharing a dashboard will direct to the dashboard view
instead of read-only spreadsheet view. A button and a side panel which
shows the global filters show up only in the dashboard view.
task 3378150
closesodoo/odoo#127370
Related: odoo/enterprise#43664
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Lucas Lefèvre <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>
This commit add a small indicator in the spreadsheet's control panel
to indicate if the user's locale is different from the spreadsheet's.
closesodoo/odoo#129857
Task: 3389491
X-original-commit: 5c776994f7bd230816369be3899989e7ab780906
Related: odoo/enterprise#44665
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
luxon and moment are both used in the solution, but
these two libraries facilitate the manipulation of dates.
It was decided to replace all uses of moment with
luxon so we can then remove moment.js from the
code and lighten the assets.
task-3391739
closesodoo/odoo#127406
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
The menus added in the server data which are used in mockServer did not
reflect a realistic menu configuration. This was brought to light when
trying to fix the addition of links to ir.ui.menu inside a spreadsheet.
See task 2821480
Related ENT pr: https://github.com/odoo/enterprise/pull/42885closesodoo/odoo#126497
X-original-commit: 128475e8c29f8493b01710342179a5c468897c61
Related: odoo/enterprise#43209
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Task Description
When autofilling a pivot/list cell from another pivot/list cell,
the format of the target wasn't overwritten. This can lead to some
strange behaviour where the user set the desired format to a cell
then autofill the remaning cell of the column/row to apply the same
format once and nothing happen.
We now propagate the set format with the pivot/list autofill, but
we still don't propagate the style and border definition, as it
could break the currently defined pivot/list style.
Related Task
task-3252442
closesodoo/odoo#124984
X-original-commit: 8678b716a9fe2b38e9ed5d399d89df2343ee239c
Related: odoo/enterprise#42542
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
We make the class DisplayNameRepository use the name service instead of
BatchEndpoint. This makes the code simpler and allow to avoid a lot of
rpcs (in some occasions) when fetching display names.
closesodoo/odoo#124090
Related: odoo/enterprise#42124
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@odoo.com>
Lucas Lefèvre (lul)