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>
Since this component is imported and used in many places, it is more
convenient to move this component a core component instead of a
component made exclusively for the Many2ManyTagsField component.
This change makes the usage of TagsList possible by SelectMenu, which
would create issues as the fields folder should not be imported in
other modules.
Part-of: odoo/odoo#115799
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>
This update contains the following commits:
[IMP] implement .alike suffix on props
[IMP] release: add version number on App
[IMP] app: add name as a config option
[FIX] runtime, compiler: fix refs getting set or unset incorrectly
[FIX] compiler: call translate function with correct string
[FIX] compiler: properly handle readonly attribute/readOnly property
[REF] blockdom,compiler: implement properties
[REF] tests: move properties tests in own file
[FIX] compiler: dynamic value on inputs doesn't turn 0 into empty string
[FIX] components: do not crash when binding anonymous function
More details at: https://github.com/odoo/owl/releases/tag/v2.0.9
Note that this owl update required a few adaptations in Odoo code. The
main problem was that some code would access references after the
component was unmounted. However, Owl is now stricter and properly
remove the reference.
closesodoo/odoo#115991
X-original-commit: a2952026f23858a8d34dcdab4ec8b467f7fc9bcf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@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>
Now the promise waiting for all async no longer relies on a setInterval.
It was a hack that can be better solved by listening to the data sources
event.
closesodoo/odoo#114348
X-original-commit: de1f42f98410bc796dfdbfd237b1e20be4496166
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Earlier, receiving data was size of the file which is not what we
want. And we are trying to decode that as they are in binary form. Which
can not working properly.
So refactor code accordingly.
Task - 3162824
closesodoo/odoo#113953
Related: odoo/enterprise#37650
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The orderByToString function has been duplicated in spreadsheet. We will
replace it with the one defined in web.
closesodoo/odoo#113873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Insert a list view in a spreadsheet
- Cut & Paste the entire list to a new sheet
- On the first sheet, insert a formula, `=SUM()` which sum many records of the list
- Click on `Clear history` in the file menu (to force a snapshot and a reload)
=> There are one RPC by number of records in the SUM function, with the
limit increased by 1 each time.
The record limit (the bigger record index) is computed during the
evaluation. With a normal case, the evaluation goes through all the
cells of the viewport, collect the biggest record index, and trigger the
rpc after that.
However, in our usecase, the evaluation is not passed on the second sheet
(the one which contains the list view), so the limit is not computed.
When we evaluate the arguments of the `SUM` function, we evaluate each
argument one by one. So we evaluate a `ODOO.LIST` formula, the limit is
lower than the previous limit, so the function returns an error.
But when evaluating the arguments of a function, we stop the evaluation
as soon as we find an error. So the evaluation of the `SUM` function is
stopped, and the limit is not entirely computed.
So the first RPC will have a limit 1, then the evaluation is re-run, a
second RPC is triggered with a limit 2, and so on.
This commit fixes the issue by preloading the limit during the import of
the data and during an UPDATE_CELL.
opw-3165458
closesodoo/odoo#113789
X-original-commit: 1c5a05198542b3a40c97443b2a9ecf5fb32eb5f2
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Set the user timezone to Australia/Sydney (GMT+11)
Set your computer's timezone is US/Arizona (GMT-7)
Insert a pivot view grouped by a datetime field (e.g. create_date),
The dates are messed up.
The server returns midnight in Sydney, as UTC as always in odoo
2023-01-01 00:00:00 in Sydney is 2022-12-31 13:00:00 in UTC
Since midnight in Sydney is still the previous day in UTC, we
have to convert the datetime to the original timezone to get back the
local date (2023-01-01).
If the user timezone and the computer timezone are different, using
the computer timezone is wrong because it will yield the time in
Arizona.
When it's midnight in Sydney (2023-01-01 00:00:00) it's 2022-12-31 06:00:00
in Arizona.
This is not the same day!
opw-3170077
closesodoo/odoo#113740
X-original-commit: b2f760cae74201d1622e56a0027dae67dcff9e33
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
With this revision, the label of the field of the first row groupby is
inserted as the row title.
Task-id 2901960
closesodoo/odoo#107220
Related: odoo/enterprise#37395
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The filter can be assigned in the history directly with its
"id". No need to copy the object
closesodoo/odoo#112309
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Date fields are changing format if you type it in instead of using the
date selector calendar popup
Steps to reproduce:
1. Install Time Off
2. Open the current language and change the date format to `%d.%m.%Y`
3. Go to Time Off > Approvals > Allocations
4. Create a new allocation
5. Change the validity period to 10.03.2023 (by typing it in, not using
the datepicker) and click out of the field
6. The date displayed is changed to 2010/03/20 or 20.03.2010 (if the
datepicker was opened)
Solution:
Add dot and comma as a possible character for static format
Also deduplicated function isValidStaticFormat so we have a single
definition
Problem:
Formats using dots were not considered as valid static format so the
value entered was parsed with the format `yyyy/MM/dd` instead
opw-3081268
closesodoo/odoo#112218
X-original-commit: 18d6944510b55a4de21be050b8fef327f00e71d5
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Rmi Rahir (rar)