The keys from the action context were not available in the context of
a name_search done when a user expand a one2many field in the search
bar. We add them.
closesodoo/odoo#107660
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Currently the label of the lines is not limited to the number of characters. When the user gives a name that is too long, the graph will not be displayed.
- This commit limits the number of labels, if exceeded it will display as ...
closesodoo/odoo#106623
X-original-commit: 54657151957c5be5e885c245db9e1830709833c0
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When a one2many is used as a search default, its label has to be fetch
via a name_get in order to get a correct display of the facet
corresponding to that field in the search bar. It turns out that the
search model did not wait properly the return of the name_gets before to
start to compute the facets.
closesodoo/odoo#106624
X-original-commit: 50f58212410b321c1c4ad3d42a91cd1d23567308
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Take a (py.extras) datetime representing the moment "2022-10-17 00:00:00"
in the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or datetime, so that in
October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103579
X-original-commit: ee1a8d26f241f2f7bea6880afcc946119b0e6bd8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Take a PyDateTime representing the moment "2022-10-17 00:00:00" in
the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or PyDateTime, so that
in October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103561
X-original-commit: a11e1fb5f702400fe51938362fe3f24570977ba9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Now that the module web_dashboard has been removed https://github.com/odoo/enterprise/pull/31641,
some props of the reporting views graph and pivot have become unused.
We remove the code related to those props.
X-original-commit: 7d231d1d37707dab4b0ecdd4e2e7cc4535ba6196
Part-of: odoo/odoo#102761
When a x2many record is opened in a X2ManyFieldDialog, it can happen
that the form renderer displayed in the dialog also contains a x2many
that use a kanban or list renderer. In those cases, the View component
is not used. Consequently, the WithSearch component responsible for
making available a search model in the env is not used either so that
a crash occurs at the setup of the kanban renderer (and sometimes later
on for the list renderer). We fix that problem.
closesodoo/odoo#103349
X-original-commit: 2c284317b6dc3c0f0b4e9e376dcee755d81222da
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, click on the "Search More" option in a list many2one
and then selecting an option in the opened dialog would lead to a crash.
This used to happen because the record is updated with a value of the
form [integer, undefined] (that is with no defined label) and nothing was
done in the list model to fetch that label, making impossible to render
the many2one after the update.
Here we make sure that a label is available after the update.
closesodoo/odoo#103271
X-original-commit: 81abccf729ef5b56a8656961931b7489e4364a1f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Have a kanban view grouped on a many2one and displaying that many2one
with a widget in the record cards. Drag a record from one column to
another: a crash occurs. This happens because the record update is done
with a value of the form [id, undefined] (that is with no defined label)
and nothing is done in the kanban model to fetch that label,
making impossible to render the many2one after the update. We fix that
problem by using the known group display name as label for the dropped
record.
X-original-commit: 2a6fe373d48385485933429fbc1e6e3eabd877b4
Part-of: odoo/odoo#103271
Before this commit the attribute default_order was not taken into
consideration by the kanban view.
closesodoo/odoo#103127
X-original-commit: 0116b590a47c8c12354877498e576ad28e42c1f2
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, a list header with no label and associated with a
first orderBy field would be highlighted (i.e. would have the class
table-active). Since this is visually weird, we remove that class from
such a header.
closesodoo/odoo#103108
X-original-commit: 36fb5a0d170d9f5692485d0b2fc374951794cd69
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The commit https://github.com/odoo/odoo/commit/c877cab866f2c1968f4f9aaf8ceebc02fa014eed
has recently refactored the css of the kanban column progress bar making
the rules for o_legacy_kanban_counter be applied only in legacy kanban
views. This lead the style of the progress bars in activity view to be
broken. Here we fix that style by copying the rules we want in the
file activity_view.scss.
closesodoo/odoo#102520
X-original-commit: 84788c27a6c22a55bb0d7e375ae60b78beeea050
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Going to My profile (user menu item when hr installed), the user name
is not fully displayed in the breadcrumb although there is enough space
to display it. We fix that by removing a rule that has become apparently
useless.
closesodoo/odoo#102492
X-original-commit: 09b5b83b41cd450359993eaca510d2e5b5a429ea
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, it was not possible to edit the path via the
model field selector popover input (visible in debug mode). We fix that.
closesodoo/odoo#102462
X-original-commit: 084af201f1f4f4cb3476ab34d3dcd649a71a4254
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
After the update of the bootstrap lib, the kanban records to be found in
the menu Project Stages of Project > Configuration (after activation of
a setting option) had each two weird borders. Here, we simplify the
kanban-box template in order to get only one border as it is in 15.0.
closesodoo/odoo#102249
X-original-commit: 839bdd0a853f88bfaeb0dd698d60e2168dc54188
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before that commit, it was not possible to select some part only
of a input/textarea input in an editable list view.
closesodoo/odoo#102169
X-original-commit: e572c11ecfb994a474ce800e46895e9233fae64b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Click on the back button in the model field selector popover used to
often remove too many names in the path created via the selector. For
example, starting with "partner_id.name" and clicking on the back button
in the opened popover would give the invalid path "" instead of
"partner_id". We fix that problem.
closesodoo/odoo#102156
X-original-commit: e4a7b63c68a87d7afef987e8d036d7ba9c5b6f96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
In a domain selector, have a selection field and the operator "is set"
selected, then change the operator to be "=". A crash occurs. This
happens because the category of operator change and thus the function
onDidTypeChange of DomainSelectorSelectionField is called with no
parameter. The same problem can happen with DomainSelectorDateTimeField.
We fix that by calling component.onDidTypeChange with the right
parameter in any case.
X-original-commit: a01c2473d93d0d123391ba0131ad505775b3c50b
Part-of: odoo/odoo#102156
Have a list view with more records that can be displayed with the current
limit. Go to next page and group by some field that produces fewer groups
that the current offset. Before this commit, no group is shown because
the offset is kept when the list reload. The same thing can happen when
the domain is changed.
We fix that bug by setting the offset to be zero when the list reload.
closesodoo/odoo#101975
X-original-commit: bda0bd21c8e6772cbfb0680a2b8b497dbbcfd628
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Some overrides of search might allow to sort on non sortable fields like
my_activity_date_deadline on crm_lead. An option allow_order was used
to indicate that to the legacy list view. The new list view introduced
with https://github.com/odoo/odoo/commit/bc0a0cead62edd1e0b299fb9a90cd21792814618
no longer consider that option and consequently the Pipeline list view
of crm can now longer be sorted by my_activity_date_deadline. The same
happens in some other views.
In this commit, we reintroduce the use of that option in the list view
and fix that problem.
closesodoo/odoo#101837
X-original-commit: 52481d55ef857ffc1004d27216cbf6b81a527b14
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, open an act window action asking for a tree view
would cause a crash. We fix that.
closesodoo/odoo#101831
X-original-commit: fa6fd8b079ad3347f3571654f07bf9751834654d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
For now, the graph view completely ignores the order attribute set on
its arch root node if written in the correct way, i.e. with "asc" or
"desc" (lower case). We fix that.
closesodoo/odoo#100302
X-original-commit: 0fb64bef16914937cf4a1d1618fb58ade6d16f14
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Now that web_studio no longer uses the legacy graph and pivot views and
that all their extensions have been converted, we can finally remove
them from the code base.
closesodoo/odoo#99734
Related: odoo/enterprise#31112
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When one tries to quick create a record in a kanban view column and a
rpc error occurs, a form view dialogs open. If the form view to
display in the dialog is a legacy view, save the record displayed in the
dialog make the kanban renderer receive a legacy datapoint with no resId
key, making impossible to add the appropriate record to the column.
We fix that.
closesodoo/odoo#99294
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Go to eLearning > Courses > Contents, group the kanban view by Course,
then quick create a record in a column. A form view dialogs opens. Save
the record: a crash occurs.
Root cause: the kanban view needs some record data that are not found
on the record created by the form view dialog but tries to add that
record directly to the column.
Solution: we create a totally new record with same resId and add that
new record to the column.
Part-of: odoo/odoo#99294
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>
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>
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>
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>
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>
This commit converts the old "slide_category_one2many" field to the new
WOWL field API.
Part-of: odoo/odoo#97984
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Several modules need to display records data in a list table in a way
suitable to possibly different record types. Here we refactor the list
renderer to allows to specify columns (and their colspans) record by
record.
Part-of: odoo/odoo#97984
Several modules need to modify some parts of the templates used by the
list renderer. Those being called recursively (and with parameters
sometimes), it is quite lengthy to do. Now the call to templates are done
dynamically so that it is easier to extend the templates by specifying
some static keys of the ListRenderer.
Part-of: odoo/odoo#97984
The aim of this commit is to provide better API points to be able
to extend the behavior of the X2ManyField in conjunction with the
ListRenderer. More precisely, we make possible to specify record by
record if it should be edited/created inline or in a dialog.
Part-of: odoo/odoo#97984
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
With only the module appointment installed, go to Calendar App,
Online Appointments and click on "Create". In the form view displayed a
stat button "Customer Preview" is visible but is badly styled. This is
due to the fact that "Customer Preview" is no longer wrap by a span since
the rewriting of the form view (see odoo/odoo@48ef812a63).
We fix the problem by making the default slot content of ViewButton be a
span wrapping the prop string (if any).
Part-of: odoo/odoo#98072
The list view has recently been rewritten in OWL (see 48ef812).
During the rewriting, it was forgotten to put the class o_renderer on
list renderers, making a no content helper in a list view be positioned
too much on the left and have its style broken when the list has a search
panel.
Part-of: odoo/odoo#97876
The "name" attributes set on the filter nodes in a search arch are now
kept in the search items created from them. This will allow an easier
manipulation of search items (e.g. toggle a filter with a given name).
closesodoo/odoo#97913
Signed-off-by: Samuel Degueldre <sad@odoo.com>
In SearchModel, the calls to search_panel_select_range and
search_panel_select_multi_range were done without using the global
context (e.g. the action context), contrarily to what is done in the
legacy SearchPanelModelExtension. We fix that.
closesodoo/odoo#96458
Signed-off-by: Géry Debongnie <ged@odoo.com>
The view mode in which to display a legacy x2many field in a new form
view was badly processed. This lead those fields to be not renderered at
all (no list or kanban renderer displayed) or be renderered with the
wrong renderer in mobile mode. We fix that.
Part-of: odoo/odoo#78221
Sometimes a field component might need to know some other fields values
to render itself or for other purposes. In legacy, a mechanism allowing
to load some field values not displayed was available: a field would
declare a fieldDependencies object specifying some field names and
their types and the related values would be loaded along the other data.
Here we introduce the same mechanism for the new views.
Note that in a new view list, the tag widget is not currently supported
so that we have remove some lines in the list arch parser that were
useless.
Part-of: odoo/odoo#78221
Before that commit a zero value for a monetary field would be wrongly
considered invalid. This would block many flows (e.g. a save).
Part-of: odoo/odoo#78221
Problem:
Have a pivot view in some state. Toggle a favorite with a context in
which a key "pivot_row_groupby" is defined. The pivot view should be
grouped (on rows) by that pivot_row_groupby but it is not always the
case. The basic problem is that the key "pivot_row_groupby" is never
considered after the first load (see method load in pivot_model.js).
Solution:
We make the search model used by the pivot view send as groupby for the
favorite its pivot_row_groupby instead of its groupBy (which can be
different). We do something similar for the graph view that presents a
similar problem.
closesodoo/odoo#95688
Opw: 2837428
X-original-commit: ea9f66f99caaa6136912c467e5b80fe605586845
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a grouped kanban view, drag a record to another column can modify the
record validity. In that case, the group changes should not be validated
and the drag and drop canceled.
closesodoo/odoo#95437
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the context parameter "form_view_initial_mode" was
ignored by the form views, so that the form view would not be always
initialized in the appropriate mode.
closesodoo/odoo#95413
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Problem:
Have
- a slow network
- a kanban view grouped
then move a given record from a column to another twice quickly.
An error occurs.
This is due to the way the transaction system in kanban model works:
the first move done in the first transaction being not yet finished,
no other transaction can begin and an error is thrown.
Solution:
Subclass Error and catch the specific transaction error at the
appropriate time to cancel the second order.
Note that the problem does not occur in a not grouped kanban view
because the hook useSortable prevent asking again a resequencing via
a proper management of the class o_record_draggable. That class is also
used in the grouped case but a rendering of the kanban view takes place
possibly before the end of the transaction: the record is moved in any
case to the targeted column and moved back if the overall operation
fails for some reason.
closesodoo/odoo#95235
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Problem:
In a kanban view with progress bars, have
- a record with a false value for the progress bar field
- "muted" be the color of a progress bar field value different from false
a crash occurs.
This happens because no fallback is found for value = false in
findProgressValueFromRecord.
Solution:
Always add a bar for the value false (as it was the case before).
closesodoo/odoo#95215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The search model should always return [] as groupBy if searchMenuTypes
does not contain "groupBy". This allows a kanban view (for instance) to
define easily that it should not never be grouped.
closesodoo/odoo#95179
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some attributes of the elements determining the "ellipsis" dropdown menu
of a kanban card were invalidly reported on the main Dropdown node
created during the compilation. This could cause crashes (during the
props validation) or broke the CSS.
In this commit:
- we fix the above mentioned problem
- we put the class o_drowdown_kanban on all "ellipsis" dropdowns
generated by the kanban compiler in order to get the appropriate CSS
- we make sure that those dropdowns are visible in kanban dashboards
by default
Part-of: odoo/odoo#92475
When on click outside of a quick create record, one wants
- to remove the quick create record if it is not dirty
- not to remove it if it is dirty with some exceptions:
if the click is on a "Create", "Load more" or "+" (quick add) button
This fix makes the external listener of KanbanRecordQuickCreate work as
expected.
Part-of: odoo/odoo#92475
The call to web_read_group done in _loadGroups was incorrect when the first groupby
was of the form date_field:granularity (e.g. "create_date:day"). The groupby was
sent as a mesure and interpreded as such, leading to an error of the form
"Invalid aggregation function ...".
This was not detected before by lack of manual testing: the mock server used in tests
checks the read group parameters in a different way from what is done server side.
So the error was not visible in the testing environment.
In this commit, we remove the error in web_read_group and improve the mock server
(a bit) so as to make such errors be detected.
Part-of: odoo/odoo#92475
The kanban view is not supposed to be grouped by more than one groupby.
In this commit, we make sure that the param groupBy is correctly process at
the first level to only keep the first groupby (if any)
Part-of: odoo/odoo#92475
Before this commit, if there were several facets in the search bar, it
was not possible to navigate correctly between them.
closesodoo/odoo#93547
X-original-commit: d2b6aab509717866ab42a9750adbb884ccec18a4
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
It is now possible to get access to the action context keys when the
search filters are evaluated. This means that a search arch filter like
<filter name="my_filter" domain="[('my_field', '=', context.get("my_value))]"/>
can be safely evaluated if "my_value" is in the action context (or in
the user context or is builtin as before).
closesodoo/odoo#91959
Signed-off-by: Géry Debongnie <ged@odoo.com>
A server action sometimes returns an action with a help key.
That help was not marked up, leading to an incorrect display of that help.
closesodoo/odoo#86170
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The method call_button sometimes returns an action with a help key.
That help was not marked up, leading to an incorrect display of that help.
closesodoo/odoo#84869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Chart.js did badly compute the graph canvas container height (width) by
using clientHeight (resp. clientWidth) that may be rounded up by the
browser. This leads to the appearence of a useless scrollbar in the
graph view and makes it flicker on some update.
closesodoo/odoo#84476
X-original-commit: 6bceae94619da9f4943cbc1e58844fdbe0215802
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We bring two changes to the API of useAutofocus:
- it takes no parameter, the element focused is the one that is the
target of a t-ref="autofocus".
- it returns the element reference instead of a function to call if
one wants to force the focus on a next patch.
Indeed, having access to the element reference makes it easy to focus
that element but also allow to remove an eventual useRef that would
target the same element. This in turn permits the use of t-ref="autofocus"
alone.
closesodoo/odoo#84306
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In 6d13271aac, the API of useAutofocus was chanded but the calls to
useAutofocus in the module point_of_sale were not adapted accordingly.
We adapt them in this commit.
Part-of: odoo/odoo#84306
In preparation for OWL-2, we introduce a new tooltip service that replaces
the hook useTooltip used by the webclient. The main reason for that is
that the implementation of useTooltip had to access el on the components
calling it. Since this won't be possible anymore in OWL-2 (el is ill-defined
in presence of multi root components) we had to find something else.
Another reason is that the useTooltip hook had no reason at all to be a
hook (as attested by the fact that only the webclient needs to call it
to have tooltip on every dom elements).
closesodoo/odoo#84160
Related: odoo/enterprise#24152
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-ref on a tag component. Here we refactor the code in order to remove
two uses of such t-refs.
closesodoo/odoo#81984
Related: odoo/enterprise#23464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-on on a tag component. Here we refactor the code in order to remove
one use of it in the action service.
Part-of: odoo/odoo#81984
Before this commit, in a line chart in comparison mode with one groupby,
if only data comming from the comparison period were displayed, the line
(with red border) would be filled incorrectly with a blue color while it
was not supposed to be filled at all (the blue filling is supposed to be
reserved to data comming from the reference period).
closesodoo/odoo#82577
Forward-port-of: https://github.com/odoo/odoo/commit/6747d982a56af0525cf52732c43351081831d32f
X-original-commit: 519e205a4b34fdecfe6b938ff4a6e93a02c2bda2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the graph view in line mode, fake data are added when there is few
data to center the graph (the points in facts). Now, there
are two problems with the relabelling of the labels created along with the
fake data:
- the relabelling (when it works) gives "Total" instead of "" (nothing)
- the relabelling crashes when the line chart is grouped by a date
field, a comparison is done on that field and no data is received.
We fix the problem by introducing a custom label similar to NO_DATA
(a custom label used to manipulate fake data in the pie charts).
Forward-port-of: https://github.com/odoo/odoo/commit/a30669d1ff258e3ac71dff4d78ca295aa1be2ec8
X-original-commit: 6374618e4d201a53182c6adf2127b0e64b4e48d1
Part-of: odoo/odoo#82577
Since the refactoring of the views aeb8e49972f871b0c9b07c507987ee77cf5e8abbd,
the filters and date filters, the groupbys and date groupbys are now
always separated visually even if no separator/group tag has been
set in the search arch. We restablish the previous behavior that only
seperates them when a separator/group is set.
closesodoo/odoo#82418
X-original-commit: e281bd0850e935ce0d97226366114da4f5406c4d
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, an action group_by like "subscription_id" was accepted
in production mode but would make crash a view that uses the WithSearch
component as soon as the dev mode is activated. Here we fix the
problem by making the acion service process the action group_by in order
to make it pass the validation.
closesodoo/odoo#81306
X-original-commit: ea209f126c57ea2f3e456a9b459dd46fd78fc33a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Load an action with a list view with at least one record and open the
view form for a record. Then reload the page and go back in the breadcrumbs.
In desktop mode, one arrives at a list view again.
Before this commit, the search view was not correctly initialized.
The problem was that the list view reuse a globaState prepared by the
form view that contains a search model state that do not reflect the
search view arch (the form view does not use the search view).
We fix that problem by preventing the form view to install the
ControlPanelModelExtension. In that way, the form view does not export
a search model state in the globalState and the list view correctly
process the search view arch.
Task ID: 2697084
X-original-commit: 40e04695ef0de96df8b850fac3f7d165585d466a
Part-of: odoo/odoo#81306
Before this commit, when comparing a period P of reference to another one,
some rows with only data comming from P would not always be presented
in the table. The problem used to manifest only when loading at least to
level at the same time (starting from Total or any header via expand all).
The reason is the following:
- the data comming from P are processed first: starting from somewhere
in the trees of headers, some nodes linked to the data comming from P
are progressively created with no children at first, then the children
(if any) are added later and so on progressively.
- the data comming from the other period is processed and nodes are
created with no children and so on in the same way, clearing possibly
all the node children comming from P.
For example, with
a row groupby = [field_a, field_b],
a group [v, v1] from P
a group [v, v2] from the other period,
a node corresponding to v would be added, then a node child for v1.
Then the node for v would be recreated with no children, then a node child
for v2 would be created. leading to a tree of row headers of the form
Total > v > v2.
Note that it was not affecting the measure values for the displayed rows
since those measures are stored separately from the tree and are linked
to the nodes via some ids.
We fix the problem by avoiding the recreation of a node if it already
exists.
opw-2635113
closesodoo/odoo#80468
X-original-commit: 364475b5da3d4aaa87db715f0c0bbaa9dd3e05c8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Andrea Grazioso <agr@odoo.com>
The commit 3862d5aae1df72d3585f915e8a2a2626322e74ad has changed the class
set on the root node of the graph renderer but has not adapted a css rule
used in the board app to ensure that the graph views have the correct
height. We fix that situation.
closesodoo/odoo#80047
X-original-commit: b08bc57d5ba2e0da17a452189d584574fb2f9832
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Since 40f1ae87e1436192a70a8a7432eb72d379cfa6dc, a view added to the board application would not
have the correct domain:
- the action domain was not kept in the saved domain
- the saved domain was kept dynamic, leading to possible crashes
e.g. a condition like ("user_id", "=", uid) in the saved domain
would make crash the dashboard app.
We fix the problem and add a test.
X-original-commit: 7e77bb74bfa1bfef92c6d385dedc2d89e0040780
Part-of: odoo/odoo#80047
During the refactoring of the legacy control panel done in d679cd0d8ba9a2420e81a42a698763e9be2327e1,
the method "_addToBoard" was renamed as "addToBoard", but a call to _addToBoard
was left, breaking the keyboard navigation. We fix that situation.
X-original-commit: 6aa10e8c9118eba3c19563431c57912108fe12b9
Part-of: odoo/odoo#80047
The identification of timedelta with relativedelta was wrong.
Here we define a class PyTimeDelta used by py.js to evaluate most
expressions in which datetime.timedelta and some operations producing
timedeltas occur.
The class PyTimeDelta allows to:
- create a timedelta
- add/substract two timedeltas
- multiply (divide) a timedelta by a float (resp. an integer);
- take opposite of a timedelta
- evaluate equalities between timedeltas and other expressions
- decide when a timedelta is "false"
- get total_seconds of a timedelta
In relation with that, we have improved the implementation of PyDate
and PyDateTime to allow most manipulations of datetime.date and
datetime.datetime producing/using timedeltas. It is now also possible to
evaluate equalities between dates/datetimes and other objects.
closesodoo/odoo#77453
X-original-commit: fcd4959a65a92e34ce986575c7fc279c195e9a11
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
The fix ff28db335fa77dadc did introduce some differences in the way
forecast filters work for a legacy or a new view. For example, let us
assume we have two filters F1 and F2 active in the same group with F2 a
forecast filter. In that situation, a legacy view would load with
domain = F1 domain AND F2 domain, and a new view would load with
domain = F1 domain OR F2 domain.
In the present commit, we harmonize the behaviors of ForecastModelExtension
and ForecastSearchModel as much as possible. We also make ForecastModelExtension
use a state received when it loads for the first time.
We have also taken the opportunity to normalize the states of the
extensions: it was not necessary to memorize forecastField (constant)
and forecastFilter (determined by the rest of the state).
closesodoo/odoo#77159
X-original-commit: 37aeb048c286f2f1a78370213635341c32ea621b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
current_date was absent from py_builtin. For that reason, it was
impossible for the search model to evaluate a dynamic domains like
"[('date_deadline', '<', current_date)]"
We add current_date to py_builtin.
closesodoo/odoo#77035
X-original-commit: ade082c5ad9221c82de90ddbe68b814b1487753d
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The class PyDateTime did not have a method to_utc. For that reason, it was
impossible for the search model to evaluate a dynamic domains like
"[('date', '>=', (datetime.datetime.combine(context_today(), datetime.time(0,0,0)).to_utc()))]"
We implement that method.
X-original-commit: 3ad9a3be64da78d596ee3dc435d4b224728a9e76
Part-of: odoo/odoo#77035
In order to be able to easily patch Date in py_date_tests and elsewhere,
we refactor the code of the legacy and new patchDate functions.
X-original-commit: 0e697c82be80cae9cc993b4be179fec42b8dae83
Part-of: odoo/odoo#77035
