Go to Project -> Reporting -> Timesheets and Planning Analysis and
select other measures in the pivot view via the "Measures" menu.
After that create a new favorite.
Result: the favorite is saved with the correct measures but the
pivot view will never use those measures. This is due to the presence
of the key "pivot_measures" in the action context.
(Note that the same problems occurs with other keys and other views)
We fix that problem by giving less precedence to keys in action contexts
with respect to those found in the search item contexts as it was
originaly the case in legacy views (cfr. __get method in action_model.js).
opw-2945969
closesodoo/odoo#99631
X-original-commit: 4528f562923cd0524f257f3a9c1ecd0002fd49b7
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Name of the test
"utils > dates > parse smart date input"
- Before this commit
The test makes a comparison between the result of parse utils,
which yields luxon's DateTime objects in the user's local TZ
(patched by default to UTC+1 in the testing env), and locally
created DateTime objects in UTC.
This has no sense to compare a date in UTC with another in UTC+1.
The test was thus failing when ran between 11pm and 0am.
- After this commit
The test has been refactored.
Also, even if it has no impact on the parsing result, the local function
parseSmartDateInput now use a DateTime object in local TZ.
This has been done in order to avoid future confusion.
If you're wondering why it has no impact, it is because this function is
used in parseDate(Time), which always sets the local TZ at the end:
```
const a = {
foo: luxon.DateTime.local(),
bar: luxon.DateTime.utc(),
};
a.foo.equals(a.bar.setZone("default")); // true
```
closesodoo/odoo#99616
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the "+" icon was displayed in kanban columns
even if the attribute "quick_create" was set to false in the arch.
With this commit, we correctly takes that attribute into account.
closesodoo/odoo#99626
Signed-off-by: Samuel Degueldre <sad@odoo.com>
In kanban arch, one can set the attribute "on_create" on the root
node to an action xmlid. In this case, when the user clicks on
"Create", the action is executed. When this action is in target
new, it opens a dialog (typically to create a record...). Before
this commit, we didn't reload the kanban after closing the dialog.
As a consequence, the newly created record wasn't displayed. For
instance, it was the case in the Recruitement dashboard.
closesodoo/odoo#99589
Signed-off-by: Géry Debongnie <ged@odoo.com>
Go to a (OWL) list view with sample data, click "Create" to open a (OWL)
form view and go back to the list view using the breacrumbs: the sample
data has disappeared.
This is due to the fact that the form view set useSampleModel=false in
the globalState when it is left while it does not use at all sample data
mode.
Here we make it simply pass the value that it received initially.
closesodoo/odoo#99587
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
One can edit the color of a tag in a Many2ManyTags field only in form view.
This commit refactors that field so that the standard field Component doesn't allow for it,
and conversely implements a specialization of the field that can, and should be
selected by the form view.
closesodoo/odoo#99499
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the StateSelection field, which
displayed the wrong value on hover. In legacy, the title
attribute was set to display that value. Now, it has been
replaced by a tooltip, since it can be used with touch
and is more convenient to use. A test has been modified
to assert the presence of the data-tooltip attribute.
closesodoo/odoo#99561
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Have a many2one in an editable list view. Type something in the input and click
on "Create and edit".
Confirm the record creation in the modal.
Before this commit, the input of the field disappears.
After this commit, the input stays.
closesodoo/odoo#99480
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This class is added automatically on large screens, to better
style the form view to benefit form the available space. However,
the width of dialogs is limited, so it makes no sense to apply
this classname in this case. If we do, those form views may display
an horizontal scrollbar. For instance: in project with worksheets
enabled, create and edit a worksheet many2one.
Part-of: odoo/odoo#99503
Part of the overall v16 SCSS optimization/restyle, task-2704984
- Converts dropdown into "nav ul li" structure.
- Removing of '.o_burger_menu_user'
- Removing of '.o_burger_menu_app'
- Removing of '.o_menu_sections'
- Removing of '.o_burger_menu_section'
- Some 't-key' not necessary anymore (thx to OWL2)
task-2812594
Part-of: odoo/odoo#88073
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Connect in your browser to a db on runbot with mail installed and wait
until the runbot put to sleep the db. After a while, a new request to
get im_status will be sent and nginx responds to it with an error 404
and an invalid JSON response. A traceback with a particularly bad
message is then shown. Here we improve the traceback message.
closesodoo/odoo#99430
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit converts the report code to the new framework.
Since the module stock still has code that extends the old
"ReportClientAction", the old report code is put inside this module.
It can be then naturally removed once the module is fully converted.
closesodoo/odoo#97390
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a list view (new RelationalModel inside a WOWL list view) that has
a legacy many2many tags field in its arch.
Try to add or remove some records from that many2many.
Before this commit, there was a crash, because the legacy field wrapper
doesn't use the model the right way for that case.
After this commit, there is no crash.
closesodoo/odoo#99431
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, if a text-muted on a setting (a description of the
setting) contains fields or HTML tags, the highlight generated wrong
texts.
Now, we highlight the text in an iterative way, taking care to only
highlight the text.
closesodoo/odoo#99205
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When searching a text of a hidden field (for example, "gate"), the
setting itself will not be shown, but the group title, and the app
Search Header will be shown.
This issue arise because, we use an if condition with all the label of
all the fields (hidden or not) in the group (or app) to decide if the
group title or the app header will be showed.
Now, we modify this to hide (d-none) the group title or the app header
if there is not a settings below them.
Part-of: odoo/odoo#99205
This commit aims to make the BinaryField and PdfViewerField appear and
act the same way as they did before their conversion to Owl.
This mostly consists of a few tweaks in the conditional rendering of
certain elements in the template, and the rest of the changes are meant
to clean and simplify the values the component is working with.
closesodoo/odoo#98251
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit allows the 'editInput' test handler to also handle inputs of
type "file". To do so, the value must be a file (or a list of files),
and the handler has been refactored to accept a certain given value only
if its type allows it.
Part-of: odoo/odoo#98251
This commits fixes the behavior of the confirmation dialog.
When a user dismiss a dialog using the close button or the
ESCAPE key, it should expect to execute the cancel action,
if any had been given to the dialog.
The behavior was missing, and the dialog was simply closed.
Tests have also been added, since this core component didn't
have any test since its introduction.
closesodoo/odoo#99418
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On Chrome, have a field that supports autofill (you have to have set up an adress in Chrome first).
Click on that field, and apply the autofill proposition.
Before this commit, there was multiple crashes, roughly one for every handler of event `keydown`.
This was caused by the fact that the autofill feature triggers keydown events without the field `key`.
(https://bugs.chromium.org/p/chromium/issues/detail?id=581537, I could not find a better ticket).
This seems to be a bug on Chrome's side, since the spec doesn't mention that field may be unset (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key).
After this commit, there is no crash.
closesodoo/odoo#99348
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The purpose of this commit is to prevent saving to a form view
if you have created and edited a new invalid record in an x2many.
How to reproduce
- go to a form view with an x2m
- create a new record with at least one required field empty in the x2m
- edit another field than the required one
- click on the save button
Before this commit:
- The view is switched to readonly mode and the new record is deleted.
After this commit:
- The view stays in edit mode, the new record is not deleted and
a notification indicating invalid fields is displayed.
closesodoo/odoo#99288
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit will make date(time) raw_value an ISO string
instead of a native JS Date.
- Before this commit
In kanban templates:
- the raw_value property of a record's date/datetime field is
a native JS Date object.
The problem with raw_value is that JS Dates toString
method depends on the system locale and timezone.
In the code base, the usage of raw_value for date/datetime fields
usually parse the raw_value into a luxon DateTime object
in order generally to display it in a specific format, or in order
to compare it to another luxon DateTime object (e.g. the now instant).
- After this commit
The raw_value property of a record's date/datetime field
has become an ISO8601 string, instead of native JSDate toString
format (which I recall depends on system's locale and timezone).
The ISO8601 format is easier to work with.
Part-of: odoo/odoo#98980
The goal is to improve the dates utility functions (parse/format) by removing the timezone option, which is difficult to understand and has proven to be error prone.
- Rationale
When manipulating DateTime objects on the JS side, associated timezones
must be always coherent.
Until now, there were several code parts that had to check the DateTime
timezone and handle things differently in a case or another.
This sometimes lead to wrong code.
E.g. there was a bug in the DatePicker component because the DateTime
object it receives in props is in local timezone, but once it updates it
through the parse utility, the new object is in UTC.
- After this commit
The DateTime objects you'll get through deserialization or parsing are
always set in the user's local timezone.
The formatted strings you'll get through formatDate and formatDateTime
utils will always be expressed in the user's local timezone.
The formatted strings you'll get through serialization utils will always
be expressed in UTC.
- serializeDate and serializeDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the server expressed in UTC
- formatDate and formatDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the user, expressed in the user's TZ
- deserializeDate and deserializeDateTime
- expected input: a date(time) string provided by the server, in UTC
- outputs: a DateTime object in user's TZ
- parseDate and parseDateTime
- expected input: a date(time) string provided by the user, in its TZ
- outputs: a DateTime object in user's TZ
- Other changes in this commit
As the timezone option has been removed from parsing/formatting utils,
all their usage had been adapted in the codebase.
The large diff in dates_tests.js is because some tests were reorganized,
others were removed/adapted/joined.
A test has been removed from daterange_field_tests.js, because it has
no sense: it displays a date field as a datetime, but a date field does
not have any time information.
Part-of: odoo/odoo#98980
Co-authored-by: Julien Mougenot <jum@odoo.com>
Reproduction:
1. Install Timesheet, and load demo data
2. Mimic a timezone in browser (Chrome): Right click->Inspect->Sensors,
in the Location-> choose Other…, type “America/Puerto_Rico” in Timezone
ID, refresh the page
3. Go to Timesheets->Timesheets->All timesheets, choose pivot view
4. Add custom filter, Date is between 1st/Aug/2022 and 5th/Aug/2022,
apply
5. The filter result is correct but the tag in the search bar is “Date
is between 31/07/2022 and 04/08/2022”
This also happens to other fields with type Date, but not Datetime. For
example, in Accounting->Reporting->Invoices Analysis->Pivot view, the
same issue happens with Due Date filter. For Datetime field, it doesn’t
have the issue, for example in CRM->Sales->My pipeline, change to pivot
view, the custom filter for Assignment Date doesn’t have the time zone
issue.
Note: reproduction usually works during the daytime in Brussels.
Reason: miswriting when rewrote custom_filter_item from V14 to V15. The
value pushed to descriptionArray should not be changed on time zone.
Fix: in parseField and formatField, use default formatters/parsers options. Add test for the Date filters.
Related PR: odoo-dev@aeb8e49?diff=unified#diff-6d9230cfcd007b087b2851cbf0b4a33b26dc3c91087853da6fe7ce8c2b60e42f
Reference code in V14: https://github.com/odoo/odoo/blob/14.0/addons/web/static/src/js/control_panel/custom_filter_item.js#L170-L173
opw-2941231
Part-of: odoo/odoo#98980
Co-authored-by: Liu Jinjiu <jili@odoo.com>
The FormView can autofocus a `default_field` if it exists, or, the first usable
field.
This commit moves the logic to the FormRenderer, has we need this feature in the KanbanRecordQuickCreate.
Besides, it makes sense for the FormRenderer to have that responsibility.
closesodoo/odoo#99297
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before, when the user dragged a card outside of a column
(e.g. whitespace to the right), the card was moved to the last stage
for which the event handler for the target was registered.
Now, we move the card only when the card drop is done inside a column.
task-2459381
closesodoo/odoo#98897
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before, the destination column while drag&drop was not highlighted.
Therefore it was not obvious for the user in which column the card
would be dropped. e.g. when the column header is not visible because
the user scrolled
Now, the destination column is highlighted when drag&dropping a card.
task-2459381
Part-of: odoo/odoo#98897
Before, it was possible to drag&drop an element from a point to another.
However it can be useful for tests to drag, make actions/tests
and then drop.
Now, the user can use the `drag` function and drop after with the
returned function.
Part-of: odoo/odoo#98897
*: survey
This commit brings back the correct behavior on blur
to the progressbar field. It turns as a text value as
soon as the user has focused out of the input. It
also removes the wrong usage of the max_value option.
The behavior was wrongly adapted from the legacy
progressbar implementation. Tests have been adapted
to assert the correct behavior.
closesodoo/odoo#98902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a date picker component in a dropdown (like in Add Custom Filter),
open the related bootstrap datepicker by clicking on the date picker
input and select a date: the dropdown closes. In this fix, we make the
dropdown stay open in that situation.
closesodoo/odoo#99345
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
In the legacy implementation of FieldMany2ManyTags, we instantiated
a FieldMany2One with the attrs of the many2many field node. As a
consequence, the FieldMany2ManyTags honnored its own options and
all options supported by the FieldMany2One.
In the new implementation, before this commit, we lost the support
of the Many2ManyField's specific options, in particular "no_create"
and "no_create_edit". This commit fixes that issue.
With this commit, the FieldMany2ManyTags also takes into account
the "can_create" attribute that is automatically set to "0" by the
framework if the user hasn't the required access rights.
Note: Many2OneField options is a mess, it would be nice to
refactor and simplify them in the future.
closesodoo/odoo#99283
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the list view crashed when it was grouped if
there was a button column in between two "aggregatable" fields
columns. The reason is that "formatAggragatableValue" makes sense
only on field columns, and it crashes when called on a column of
another type. It was for instance the case in the Stock > Locations
list view.
closesodoo/odoo#99289
Signed-off-by: Georis François (fge) <fge@odoo.com>
Edit a domain in the debug text area of a domain field in debug mode
was possible but the value displayed in the text area was reset to the
value displayed in the part above. For instance, starting with a domain
field value like "[('id', '=', 1)]" then editing it in the text area to
be "[('id', '=', 3)]", the value for the domain field would be correctly
updated but the value displayed in the domain field would be the initial
value "[('id', '=', 1)]". We fix that by making the DomainSelector
component accept an extra prop "debugValue" to be displayed in the debug
area instead of the prop "value" if it is defined.
closesodoo/odoo#99207
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Setting [(1, "=", 1)] as domain in the debug text area would make crash
the DomainSelector component because the sub component ModelFieldSelector
would not accept 1 as a fieldName prop due to its props validation. We
fix that by converting 1 to a string.
Part-of: odoo/odoo#99207
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Before this commit, the required attribute has no effect on the x2many
fields. It will always be valid unless one of its records is invalid.
Problem:
In some cases, we would like to be able to make some x2many fields
required. For example, many2many_tags should be invalid if it contains
no records.
In legacy, if a field is required, then it has the responsibility to
evaluate if its value is valid. To do this, each field contained the
isSet function which returns true if the value is set.
In our new architecture, it is the model that evaluates if the value of
a field is valid based on the field type. It is therefore no longer
possible to customise the evaluation of the validity of a field based
on the FieldComponent.
Solution:
This commit will reintroduce the possibility to customize the evaluation
of the validity of a field based on the FieldComponent.
To do this, we add the possibility to define a static isSet function
on the FieldComponent. If this function is present, it will be used
to evaluate if the field value is set or not.
closesodoo/odoo#98873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a grouped kanban which display a priority field widget.
Quick create a record.
Click on any priority widget to change the priority.
Before this commit, the model was still considered in edition, preventing any change
in other record. Hence, the priorities did not change (at least, there was no write operation)
when clicked on.
After this commit, this flow works as expected.
closesodoo/odoo#99199
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit standardizes the API of orm service functions by adding
a "kwargs" parameter, s.t. one can always use those functions even
if the target model overrides the corresponding method to add the
support of a given kwargs. Furthermore, to simplify those function
API, and to close the gap between the js and python APIs, we moved
the "context" argument inside the kwargs.
closesodoo/odoo#99018
Related: odoo/enterprise#30830
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit changes the API of the "create" function of the orm
service to better reflect the API of the corresponding method in
models.py, which takes a list of record values in argument.
Before this commit, a call to "create" only allowed to create a
single record.
Part-of: odoo/odoo#99018
Before this commit, the "read" function of the ORM service didn't
allow to pass any kwargs. As a consequence, it wasn't possible to
call the "read" method of a model with "load" kwargs specified.
This commit fixes the issue, and adapts existing calls accordingly.
Part-of: odoo/odoo#99018
Before this commit, when dropping a record on a folded column in a
kanban view, the column would not load its records and display a "load
more" button instead.
Now, dropping a record on a folded column loads it entirely before
unfolding it, displaying its records normally (including the newly
dropped one).
closesodoo/odoo#98922
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When a field in readonly view can be modified, it should write to the
backend immediately. (No changes are stored to be comited later)
For some reason, a bit of code was preventing this if the field was
required and had a falsy value. Furthermore, the code seemed incorrect
or at least misplaced. Removing these lines didn't affect the test.
The fix simply remove this extra check.
There was a condition in the update code for required field in readonly
views that prevented the correct flow to be executed. Since no test are
broken removing this check but it fixes the problem, it is removed.
closesodoo/odoo#98978
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adds two new props in `form_controller` in order to call a function from
the parent `Component` just after the form view is saved/discarded.
closesodoo/odoo#97314
Related: odoo/enterprise#30045
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if a touchstart event is performed on a row in an
x2many, then a crash is displayed.
We also use this commit to rename the hasSelector props to allowSelector.
allowSelector is true if checkboxes can be present.
How to reproduce:
- go to a form view in mobile mode with an x2many field
- touch a row in the x2many (trigger an event touchstart)
Before this commit:
An error is displayed
After this commit:
Nothing happens.
closesodoo/odoo#98893
Related: odoo/enterprise#30773
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, it was impossible to empty a many2one in a list view.
How to reproduce:
- go into a list view with a many2one
- empty a many2one containing a value
- click outside the line
Before this commit:
The record goes into readonly mode and its many2one returns to
its original value.
After this commit:
The record is saved and its many2one is empty.
closesodoo/odoo#99140
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the style of the field, which was
pretty broken since the Owl conversion.
It also bring back the tooltip (as in legacy) when
the button is clicked.
The button now only shows the tooltip if the text
has been copied successfully to the clipboard, and
not appear when it is not allowed or not available
in the browser.
Tests have been added to assert those behaviors.
Enterprise PR to adapt a selector in tests:
https://github.com/odoo/enterprise/pull/30832closesodoo/odoo#98340
Related: odoo/enterprise#30832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds a generic `action="action_some_method"` attribute to
the list view to allow for a custom action when clicking on a (record)
row. This feature mirrors the existing Kanban "action" attribute.
Note that in cases where the action method does not return a valid
action then the default action `act_window_close` will be called
instead (same behavior as the kanban view and buttons in general).
Supports "magic link" part of Task: 2882539
Part-of: odoo/odoo#97109
Purpose
=======
Allow non administrators to use relational properties.
Standard internal users can not read ir.model. Because of that we
created a component that simulate the behavior of a many2one, but
that call custom public method that check which model the user can
access.
Task-2852259
Part-of: odoo/odoo#95184
Mathieu Duckerts-Antoine