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>
`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>
Some props like className were declared as optional in TagsList while
they are not used by the component. We remove them from the props
declaration.
Part-of: odoo/odoo#126350
During the Milk revamp, the dropdown items in the Dashboard's header
lost their horizontal margins. These have been put back by setting a gap
property to the parent.
When in the dashboard view under Sales > Product, the dropdowns had an
awkward spacing between them despite the fix. Another fix was to set
`w-100` to the `.o_field_tags` element. And finally a `.gap-1` is also
added to the latter to give its children some space when multiple tags
are selected.
It was noticed that some CSS, specifically the `.o-filter-value` class,
was not targeting anything. This has been fixed by moving the selector
into its correct parent element.
task-3326566
part of task-3326263
closesodoo/odoo#127010
X-original-commit: bd456bc89f896de6b3d8c040706dc02ab3799e6e
Signed-off-by: Lucas Lefèvre (lul) <lul@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>
This commit:
- adds a "delay" parameter to the `draggable_hook_builder`, waiting for
that delay on pointer down events before triggering the drag sequence
(making it possible to use "long mousedown" events);
- changes the event detection in `draggable_hook_builder` to listen
for pointer events instead of mouse events, effectively supporting the
drag and drop feature on touch devices;
- adapts the test helpers (with some refactors to `triggerEvent` and
other utility functions) to make them use pointer events instead for
drags and drops;
- adapts the tour utils to use a tone-downed version of the refactored
test utils `dragAndDrop` function;
- also changes events in list view which does not yet uses the draggable
hook, but should still work with the same helpers in tests.
Part-of: odoo/odoo#116005
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>
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>
This commit removes 'Try Odoo' ad from the spreadsheet template which is
visible when spreadsheet is shared with public.
Task-3347908
closesodoo/odoo#124779
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Open a spreadsheet, add a data filter, filter some values,
File > Download
=> the filtered values are not exported.
Previously, we gave the exported data to the action_download_spreadsheet
action, and we created a new model based on the data. This was a problem
for data that was only exported for the xlsx in UI plugins, because this
wasn't in the exported data.
Fixed by giving the xlsx data to the action_download_spreadsheet action instead
of the data.
Odoo task 3231170
closesodoo/odoo#124617
X-original-commit: 8a7e2ecf60993c6862c8980b70e847c0e5aa2a50
Related: odoo/enterprise#42355
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Minne Adrien (adrm) <adrm@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>
The method getDisplayNameAsync being no more called, DisplayNameRepository
has no need to manage deferreds. We simplify it.
Part-of: odoo/odoo#124090
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@odoo.com>
The test added in #120818 was relying on a model that does not depend on
module `spreadsheet, rather the opposite. This information was probably
lost during the forwardport process.
Since the fix concerns `spreadsheet.mixin` and not just
`spreadsheet.dashboard`, it makes sense to test it globally, in a
dedicated test module.
Fixes runbot build errors 20966 and 20968
closesodoo/odoo#123947
X-original-commit: 7205e3b26eb3de3f53d6984cd07ec3e4b3fbcfdd
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@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>
The json fields are not supported in lists at the moment because they
require additional RPC to fetch the display value as long as its
formatting.
closesodoo/odoo#122074
Task: 3324679
X-original-commit: 9e6d598e6a96434c68634149ecf1acf3e714ca03
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
In this commit we add the makeServerError utility which allows you
to easily create a valid RPCError in the tests.
We have added this utility to prevent the use of invalid or incomplete
errors. We will give default values for all the parameters needed for
a valid RPCError.
For example, in some tests, we only check the presence of an error
dialog and not the expected one. So there was a set of tests that were
green because the failure was in the RPCError handling. So we had an
error dialog but it was not the right one. In general, the crash occurred
because the RPCError contained no data.
closesodoo/odoo#121932
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit implements the functionality of using backspace key to
delete values in relation filter.
task 3324738
closesodoo/odoo#121513
Signed-off-by: Lucas Lefèvre (lul) <lul@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>
Task Description
This PR aims to add two new icons in the context menu of the spreadsheet, for
the see records/see properties and the set as filter actions
closesodoo/odoo#120543
Related: odoo/enterprise#40713
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, the chart's dataSources were managed by the core plugin
`OdooChartCorePlugin`. 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)
Moved the dataSources management to the UI plugin `OdooChartUIPlugin` and moved
the relevant getters inside this plugin. Changed the ids of the dataSources
to be the same as the chart's id + a prefix, to avoid having to maintain a
mapping `chartId` <=> `dataSourceId` .
closesodoo/odoo#120136
Task: 3293491
Related: odoo/enterprise#40546
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
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
This commit introduces a date picker OWL component meant to handle the
following use-cases:
- date picker
- date & time picker
- date range picker
- date & time range picker
Basically, this component is the union of the two previous third-party
libraries handling these cases: TempusDominus and DateRangePicker.
New components introduced:
* The main addition of this commit is the `DateTimePicker` itself which
handles the display and interactions of the calendar and time pickers.
> see @web/core/datetime/datetime_picker
* The picker can then be coupled to an input using the
`useDateTimePicker` hook. The purpose of this hook is to handle events
on a given input element and syncronize its value to a date picker it
will spawn in a popover.
> see @web/core/datetime/datetime_hook
* Lastly, a simple `DateTimeInput` component will render an input and
call the hook mentioned above to handle it. This component is
effectively replacing the previous DatePicker and DateTimePicker
components (note that it does not handle range values).
> see @web/core/datetime/datetime_input
Another noticeable change of this commit is the definition of daterange
fields in views:
- Previously, the arch would have to define both fields
and bind them via their options, while also adding an arrow between
inputs or other forms of connection.
- In the new implementation, only the start date field must be declared,
and a date range can be spawned by providing an `end_date_field` in its
options.
Example:
```xml
<field
name="start_datetime"
widget="daterange"
options="{'end_date_field': 'end_datetime'}"
/>
```
warning Added limitations:
- this new way of declaring date ranges means that templates have been
revised to declare one field tag instead of two. This means that list
views using date ranges have lost the ability to be sorted on their end
date fields.
> Justification: the current use cases have been reviewed and it has
been decided that it was not needed to sort on the end date on the
affected list views.
> Workaround: drop the date range and declare both fields as simple date
pickers (i.e. without the end_date_field option).
- all modifiers applied to a field using a date range will be copied and
applied to the end date field. There is no way to define modifiers
specific to one field or the other.
> Justification: there was no use case where one of the two fields
needed specific modifiers.
> Workaround: same as the previous point: split the range into 2 simple
date picker fields.
Additional notes:
- the widget="daterange" is not mandatory in form views, but is required
in list views because only fields with explicit widgets will not be
rendered as simple <span> elements. The date range feature will be
available as soon as an end_date_field is specified.
- as the end date field is not explicitly defined in the view anymore,
any modifier depending on it need to have it defined as invisible
somewhere in the arch.
Task ID: 3121497
Part-of: odoo/odoo#112171
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Pierre Pulinckx <pipu@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>
This commit makes the `dependencies` param of
`odoo.define` mandatory. It was optional and when
omitted, a regexp read the function to find the
dependencies. We can simplify it now almost all js
modules have been converted to esm.
The transpiler already adds the param for the es
modules except if the module has an alias.
task id: 3271352
closesodoo/odoo#119145
Related: odoo/enterprise#40040
Signed-off-by: Mathieu Duckerts-Antoine <dam@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>
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>
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>
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>
Pierre Pulinckx (pipu)