Before this commit, in a grouped kanban view, a lot of rerenderings
were done when the user dragged a record from a column to another.
This commit adds an option to Record.update to bypass the rendering
part, and we use this option for calls during the record move and
resequencing, as we know that the view will be rendered at the end
anyway.
Fixes performance issues spotted on odoo.com (Project task grouped
kanban view).
closesodoo/odoo#114225
X-original-commit: 3aa91db099532c09b12f1a4148ae3829a1a9593b
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Very niche usecase, but still:
\- Create a planning shift, set a recurrence for ever.
\- Go few occurences later (form via kanban) and set...
...recurrence type to "Number of Occurences",
...recurrence nmber to 1.
\- Save.
The write method will update the recurrence
so that it only contains only one occurrence.
Consequently, the record you just updated is deleted.
Then we try to fetch the record to display its form again.
Because de read returns [], _fetchRecord rejects the promise,
and we're stuck.
So, in this commit, we make `FormController.saveButtonClicked` call
`Record.save` with its params, so itself can be called with throwOnError,
and the potential error catched.
We all so cover the case where `BasicModel._fetchRecord`
returns `Promise.reject()`, in `BasicModel.save`.
Also, `Record.save` has an object as a default value for params.
When we call it from `FormController.saveButtonClicked` with params,
say params is an empty dict, the default value will be lost.
Istead of overriding this object, this commit only overrides/adds
the key of the object we give `Record.save` if any.
Also, when investigating on that, we jsut noticed that,
when you click save on a form dialog,
it reloads the record before closing it, which is useless.
closesodoo/odoo#112335
Related: odoo/enterprise#37752
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
This commit adds the possibility to display a properties field in a list
view.
How it works:
When a properties field is present in the arch of a list view, it will
not be displayed directly. It will display its properties as an optional
column. Now, we will find at the end of the dropdown of the optional
columns a section by record parent of the properties field. The proposed
sections will be the properties linked to the parent record of which at
least one record referring to it has been encountered during the
navigation in this list view.
(A parent record is the record storing the properties definition).
Limitation:
Multi-editing is not applicable on properties fields as you cannot edit
one property without modifying all the others.
closesodoo/odoo#112005
Taskid: 3105039
Related: odoo/enterprise#37004
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: mcm-odoo <mcm@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
This commit adds the possibility to navigate between the different views
of the view switcher from the palette command.
closesodoo/odoo#113658
Taskid: 3205658
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove setDirty prop from concrete fields. Now if
needed the fields can declare itself dirty using triggering
"FIELD_IS_DIRTY" on the model's bus.
Note that this PR partially revert [1] and completely revert [2]
task-id 3179751
[1] : 89c2a3978e
[2]: c79bb3c9c6closesodoo/odoo#114124
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: point_of sale, web
Previously, the error handling code was refactored and centralized, in
doing so, we broke the ability to select a table while offline: when
selecting a table we ask the server about the orders for the table. When
offline, this creates an error that was previously caught, and showed an
offline error popup, but continued the rest of the flow normally. The
refactoring centralized the display of offline errors to an error
handler, but removed the catching, causing the error to interrupt the
flow.
This commit fixes that by catching the error again, and when it's a
ConnectionLostError, it dispatched the error in a separate async call
stack (using Promise.reject) so that the display of offline errors is
still centralized, the the flow can continue normally.
closesodoo/odoo#114077
X-original-commit: f45f5e644b4b219b968fa19737d75cc710c823f3
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Steps to reproduce:
1. Install Dashboard & Inventory (enable multi-locations)
2. Make inventory adjustments to have a location with negative stock
3. Go to the dashboard app & click on “Inventory On Hands”.
4. An error shows up: TypeError: chart.dataSource.getData() is null
Issue:
If one of the locations have negative stock, the pie chart will not be
displayed and it will throw many errors, It has the same behavior If
every location have negative stock.
Solution:
Discussed with the PO, when we have positive and negative values, we
want to ignore the negative values and display the pie chart with the
positive values only. For this case, we modified `_prepareData` and
`_isValidData` methods so they check and filter the positive values in
case we have any. For the other case when we don't have any data, that
can be displayed in the pie chart, we added a way to don't get any error
and only display a blank pie chart.
opw-3103967
closesodoo/odoo#113794
X-original-commit: 3fdfc357097fc77cb998e8a6794efe1f9ffa53bb
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Before this commit, the new drag & drop tour helpers could only be used
on the white-listed "o_record_draggable" class name. This meant that
only the new kanbans could use the "drag_and_drop_native" tour helper.
This commit allows any element using the "o_draggable" class name to use
that helper, and renames occurences of "o_record_draggable" to
"o_draggable".
Part-of: odoo/odoo#112756
The aim of this commit is to make more warning and error dialogs behave
like the "oh snap" dialog of form views.
task-id=3126594
closesodoo/odoo#112276
Related: odoo/enterprise#37593
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
Currently, the default value of a property is only used when we create
new record. But it can also be used when we create a new property.
Note that the default value is written on the property ONLY if the
property just have been created, to not update existing value on
other records (the goal is to have a behavior similar to normal fields).
Task-3172106
X-original-commit: e3099ae584cef74434fdb51f7fee2ae6250f18ca
Part-of: odoo/odoo#113448
To reproduce
============
- Modify the task list view like so: <field name="partner_id" attrs="{'invisible': [('partner_id','=',8)]"/>
- the field value will be invisible if the customer is "Joel Willis" (with standard demo data)
- However the popover for the value is still there
Problem
=======
the value of tooltip is always set even if the value is invisible
Solution
========
set value of the tooltip based on condition about field visibility
opw-3177191
closesodoo/odoo#113785
X-original-commit: 5bee2125528ee1d20779112093e098eaa64cf5c0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: hr_skills, project
This commit improves the behavior of the ProgressBar field. Before 16.0,
views had a readonly mode, and to avoid having the inputs always visible,
the user had to click on the progressbar to enter into an edition mode.
Nowadays, this is redundant, and make it difficult to guess that the field
is editable. With this commit, the input is always visible, which also
allow to improve the template and the code of the component. The commit
delete unused props/options that were no longer used by the widget.
This commit also remove a legacy scss file that was still present, and the
style of the component has been moved to its own file. Some dead classnames
have been dropped, or replaced by bootstrap classes, reducing the size of
the scss file.
Tests had to be adapted, because some assertions were irrelevant, or were
triggering the click to enter edition mode.
task #3178958closesodoo/odoo#113002
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The external button of the Many2one field has been changed with the
"always edit" feature of the form view, s.t. it displays by default
another icon (a right arrow) and when clicked, opens the related
record in another plain screen action instead of a FormViewDialog.
However, this doesn't work for Many2One fields that are already in
dialogs, because
1) if it's an action dialog (target="new"), that dialog will be
closed when opening the related record and the user loses its
working context
2) if it's another type of dialog (e.g. FormViewDialog), the
related record opens in the background and the dialog remains
open, which is obviously a bad UX experiment. This had been
locally fixes at some places [2].
This commit fixes the issue by automatically opening the related
record in a FormViewDialog if the Many2One is itself already in a
dialog.
This commit also fixes an issue with the scenario where the related
record opens in a dialog: if there were changes done in the main
record, those changes where lost when the user clicked on "Save"
in the dialog of the related record. We now only reload the
display_name of the related record, and apply it to the model.
[2] https://github.com/odoo/enterprise/commit/ba0e95fe42696dcf44b8feddeb302f04876fcbdc
Task 3191319
closesodoo/odoo#112959
Related: odoo/enterprise#37213
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
From a practical point of view, it seems better to also add the
dialog service in the service registry when calling
setupControlPanelServiceRegistry.
closesodoo/odoo#113610
Related: odoo/enterprise#37510
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduction:
1. Install Sales
2. Go to the quotations
3. Drag the column “name” and change the size
4. Check any sale order in checkbox
5. The column size is reset to default
Reason: the keepColumnWidths parameter isn’t set to True after changing
the size. This happens to all the list views
Fix: we freeze the list after resizing the columns. Remove the extra
keepColumnWidths setting in reordering since it's already set to true
after resizing. Also added tests to check the column size is kept after
toggling the checkboxes
A similar fix is here: https://github.com/odoo/odoo/pull/10902
opw-3113822
closesodoo/odoo#113607
X-original-commit: 30a346a90b633dd73fa823de2cdaf37a0e52c526
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The form view currently reads its data as follows:
1) read the main record, which returns [id1, id2...] for x2manys
and [id, display_name] for many2ones.
2a) read x2manys records, with the context set on the x2many field
node, which returns records like 1)
2b) call name_get for many2ones with option "always_reload" set to
true, with the context set on the many2one field node
3) same as 2), but for records returned by 2a)
The context set on a field node is a string, and needs to be
evaluated (some placeholder values need to be replaced by actual
values), e.g. "{'partner': partner_id}" -> { partner: 4 }.
For 2a and 2b, the context sent is evaluated with the main record
as eval context. For 3, there an additional key "parent" in the
eval context which contains the values of the parent record.
The rationale of this commit is that those data related keys in the
eval context are useless for read-like rpcs.
In the future, the data of the form view will be fetched with a
single rpc, returning the main record and its related records, with
all the values required by the UI. To achieve that, we must ensure
that sub records are never read with a dynamic context depending
on the parent record.
This commit thus directly imposes the limitation, by removing from
the eval context the record related data when it is used to evaluate
the context to send to read-like rpcs.
Part of tasks 3171453 and 3179751
closesodoo/odoo#113527
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Bug
===
If the Reference field is in a list view, and has a default value, an
error is raised if we create a new record without editing the reference
value. This is because the ORM return a string "model,id" in the
onchange method and this value is wrongly parsed in that case.
Task-2234179
closesodoo/odoo#113392
X-original-commit: b1a35d1b95612bc449b68ed38749d8b3755287ed
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This commit revamps the UX of the StateSelection field widget. Now, instead
of filtering the options by removing the current selected value, the field
displays the entire list in the dropdown, and the selected item has a
checkmark to indicate its status.
This allows us to remove the tooltip, since its presence was not useful
anymore, and was unintuitive to use. This changes required to adapt some
tests asserting its presence, as well as the number of items shown in the
dropdown menu.
task #3177182closesodoo/odoo#113203
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As with fieldsToFetch in commit 25bf5a3fabfa9da5367e82d1c5713425c77bc373,
we will convert fieldDependencies into an array of fields.
We did it because it's easier to use and more natural to has an array.
Part of task 3179751
closesodoo/odoo#113482
Related: odoo/enterprise#37449
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When using the ControlPanel's bottom-right slot in another component, if
`viewSwitcherEntries` wasn't defined in `env.config` it would raise a
traceback, as the template would try to check an `undefined`'s length.
Removed the workaround that added an empty `viewSwitcherEntries` in the
forecast report and the bom overview report since it's no longer
necessary.
closesodoo/odoo#112415
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
It may happen that the response of a json rpc isn't json parsable,
for instance when the connection pool is full (PoolError). In this
case, the response is an internal server error (500) in html.
Trying to json parse it throws an error. Commit [1], backported in
15.0 by [2] aimed at throwing a more readable and meaningful error
when this happened.
However, this error occurs frequently on the saas for the moment
(see task 3193565), and users constantly report those HTTPError
tracebacks introduced by [1].
In 14.0, we were using jQuery ajax, and the legacy rpc and error
system, where those internal server errors were handled as
connection lost errors (error code -32098). So basically, a
notification was briefly displayed instead of an error dialog.
This commit restores the previous behavior in the new rpc service.
[1] https://github.com/odoo/odoo/commit/5c4a54022b320
[2] https://github.com/odoo/odoo/commit/a01122543a79cclosesodoo/odoo#113434
X-original-commit: 278686d8540a194f0af51e1a0b68b26b13eaf544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The number property should be formatted like a normal integer / float field,
in the form view (show 2 decimal for the float, thousands separators, etc,
even when editing).
Task-3162402
closesodoo/odoo#113449
X-original-commit: 99c251820dcf4791625fabd3fcd61db84280d408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The delay of tooltips opened with the tooltip service can be given
in xml, with attribute data-tooltip-delay. If not specified, there
is a fallback in the service to 400ms. Before this commit, the
fallback wasn't correctly applied, because we parsed the xml delay
into an integer, which was NaN when the delay wasn't specified,
and as NaN isn't undefined, the fallback wasn't applied. As a
consequence, we opened the tooltip in a setTimeout with NaN as
delay, and it thus opened directly.
closesodoo/odoo#113425
X-original-commit: 553b2775a4b31c75d1d246816b749e4521e25726
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Steps to reproduce:
- In debug mode
- Go to a cancelled invoice in Accounting
- Click to the "Reset to draft" button in a fast timing (before the
`PopoverContainer` is mounted).
When hovering an element, a tooltip appears. If the target element
disappears before the `onMounted` of the `PopoverContainer`, then the
popover causes a crash because the target element does not exists
anymore.
This fix makes the `tooltip_service` verify that the target still exists
before adding the popover.
closesodoo/odoo#113406
X-original-commit: 589acab37a4c1b68876386b752a91c3412dc4569
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
Before this commit, the widget's description was stored on the
component and this component was then registered.
Now, an object describing the widget is used on registration the same way
as it is done for views since b828cfc.
This split the component's description (props, template, ...) of
the widget's description ( component, extractProps, ...) and makes
it clearer.
We did the same thing for fields in 9f4622492c
Part of task: 3179751
closesodoo/odoo#112962
Related: odoo/enterprise#37215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Problem:
In a list view, editing a record and then clicking an action button
on that record does not save the edited field values.
Expected behaviour:
Changes applied to the record must be saved before executing the button
action.
Solution:
The 46bd694c8a67f25470a911c1eb04e0bf2e17a5f7 commit in master solves
this problem (TaskID-3132960). We will backport it and add a test for
our use case.
How to reproduce:
- Go to a list view with one text field and one button action per record
- Edit the text field
- Click on the button action
Before this commit:
The value of the text field has been restored. We lost our modification.
After this commit:
The record has been saved.
closesodoo/odoo#113120
Taskid: 3168517
X-original-commit: 5f5040730707e62885757aa6a39345a46cda9b48
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
In the sample server, we generate random float values between 0
and 100. The faulty assertion expected the value to be strictly
less than 100, however, it sometimes failed: when Math.random()
generated a value >= 0.99995, it produced 100 as float value.
Runbot error 15206
closesodoo/odoo#113181
X-original-commit: 4abfb9553559080d53bc5a8ba521eec000c56a26
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The sample server did not create a __range value when grouping by 'date'
This resulted in a traceback as it is expected to at least be false.
This commit computes it properly.
task-3098681
closesodoo/odoo#113163
X-original-commit: cf074f1dc01da39e75aa30e4ac21eafa29d528d9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
For performance reasons, we added a feature that allows to limit
the search_count done when fetching records in list and kanban
views, to display on the right side of the pager [1][2]. However,
the page previous case wasn't correctly handled when we had a
limited count. When doing page, we need to know the total number of
records to compute the offset. Before this commit, we went to the
last page, which wasn't really the last page (because we sent a
wrong offset), which can be misleading for users. With the commit,
we force a search_count when doing page previous on the first page.
[1] 6acfad2651
[2] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
closesodoo/odoo#113134
X-original-commit: cefff0dcd5b3b1120b215e6af28d678c7ec34d52
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since commit [1], we can have list or kanban view with same limit
and count_limit (to save a costly search_count), i.e. have a pager
like "1-80/80+". Before this commit, when reaching the count limit
on page next, we performed the search_count. This was fine before
as the count_limit was hardcoded to 10k, so you basically never did
page next until the limit. However, it's a issue now that the
count_limit can be specified, as in the above example, we don't
want to slow down the loading of the second page records because of
the search_count.
With this commit, we slightly increase the count limit when we
reach it, so for instance doing next when the pager shows 1-80/80+
fetches the records with args offset=80, limit=80, count_limit=160
and the pager then shows 81-160/160+. If the total number of records
is reached, we know the count and display it, for instance, after
another pager next: 161-190/190.
The same logic applies when the pager is manually edited, e.g. when
you write 1-150 in a pager showing 1-80/80+, you'll get 1-150/150+
if there are more than 150 records.
[1] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
X-original-commit: d39559274e6de6cdba6972775f9bda8bd2de8fa6
Part-of: odoo/odoo#113134
This commit adapts the translation tests for non-English Numbering
system to rely on the month's numbers instead of names, as the goal of
those tests is to verify that the correct Numbering System has been
applied instead of this specific datetime format.
This is due to Chrome 110+ modifying/fixing month's name translation in
the Intl API, and more specifically the bengalese's test breaking since
this update.
Note: Firefox and Webkit browsers applied similar fixes in their recent
versions.
closesodoo/odoo#113121
X-original-commit: 42b679b9b71bf2b58e0f785c21ef002de6f3ca32
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
For the Knowledge module, we would like to allow the user to fully
customize a graph view and let the user insert the graph they see in an
article. When loading the graph view from an article, the system can not
currently restore the following settings:
- For the bar chart and the line chart: The system will not able to
restore the "sorting order" and the "stack option" set by the user.
- For the line chart: The system will not be able to restore the
"cumulative option" set by the user.
This commit will ensure that these options can be specified from the
context of the view. The context configuration will have a higher
precedence than the configuration stored in the metadata of the model.
When the user will open an article containing a graph view, the graph
view will automatically load the options that have been set by the user
when inserting the view. The user can thus create their own dashboards
by customizing the graphs and inserting them in an article.
task-3056268
closesodoo/odoo#112600
X-original-commit: 458bf22c7e275b7893505bb39c16073a9f63b9ca
Related: odoo/enterprise#37046
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, there are a few mistakes in the standard view props definition:
1. To check the type of each element in an array, the prop definition has
to include an "element" entry. In the standard view props definition, we
included an "elements" entry which will completely be ignored by the
schema validator of owl in debug mode.
2. The "element" entry is only used when the `type` entry of the prop
definition is `Array`. We will therefore simplify the property definition
and remove the "element" entry for the props that are not arrays.
3. The `orderBy` definition of the standard view props mismatch with the
`orderBy` definition of the `WithSearch` component and the search model.
This commit will fix that inconsistency for all those components and
update the tests and the JSDoc accordingly. It will then be possible to
set the `orderBy` value from the props of the `View` component without
getting an error in debug mode.
task-3056268
X-original-commit: 4911e6cd366eadc60923940364274b30372e1584
Part-of: odoo/odoo#112600
For performance reasons, the grouped kanban view automatically
folds groups when they are to many, s.t. at most 10 groups are
open by default (because for each one of them, we must perform
a web_search_read rpc to fetch their records) [1].
However, during the convertion to owl, we broke half of this logic.
The qunit test introduced by [1] simulates a read_group that only
sets the __fold key to true in folded groups, but doesn't define it
in other groups. This test passed. But the logic in the model
didn't correctly handle the case where the __fold key was given for
all groups, even when its value was set to false. This happens for
instance in the project task kanban view.
This commit fixes the issue.
[1] https://github.com/odoo/odoo/commit/fa4c650b01dc184041c61d9d52299b0b740a83bd
Task 3191948
closesodoo/odoo#113061
X-original-commit: dd71662cc994fb8716cae63944b4df9d4201dcdc
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form dialog view, clicking on an action button
in the header does not save the record being edited. The record is reset
in case a new record is created.
How to reproduce:
- Go to a form view with a non-editable m2m
- Click on add a line
- Click on Create
- Edit the new record
- Click on an action button (the arch must contain a <button> in the <header>)
Before this commit:
The record is reset. All encoded data is lost.
After this commit:
The record is created in db and we keep all the encoded data.
closesodoo/odoo#113063
Taskid: 3165983
X-original-commit: 52fdfe0b26941718bf1532e517a51de38cacfdbc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce
=============
- on settings upload a custom background on document layout and save it
- open document layout again and try to download the image -> Traceback
Problem
=======
when calling download method we will ask server for a record with `id=false`
which gives an error
Solution
========
download button shouldn't be visible when `record.resId == false`
opw-3138230
closesodoo/odoo#113029
X-original-commit: 2e2cdee563dd645cabe2d361489d6eb17b174a33
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit
Many of the usages of the "throttleForAnimation" util did not
cancel the call to the throttled function when the using
component is unmounted.
After this commit
A "useThrottleForAnimation" hook:
- is introduced
- is tested (as of the prior "useDebounced" hook which was not)
- replace the "throttleForAnimation" usages.
closesodoo/odoo#112913
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The commit restores a similar crop overlay like in the Odoo Android
Mobile App for the Barcode scanner.
This feature helps to scan the right barcode when the user scans a
barcode surrounded by other barcode, which before this commit a barcode
was scanned but in some cases not the good one. The commit solves the
problem by returning only the values into the rectangle overlay.
Part-of: odoo/odoo#112855
This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.
This is basically a revert of 9407383a56
due to the changes in the DOM and styling made in the meantime.
But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.
Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
closesodoo/odoo#112878
X-original-commit: 766498a36b322ffe9c647616f56f3ba04cc51d96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Let us have records with values 1, 0, 77, 3 for a float field 'foo'.
read_group allows to get those values in an array with the aggregate
function array_agg:
read_group([], ["foo:array_agg", ...], []) will return
[{ __count: 4, foo: [1, 0, 77, 3], ... }]
We now support the use of array_agg for integer and float fields in
the mock server.
closesodoo/odoo#112825
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
mockReadGroup should not count the value false for a many2one when
aggregating a many2one field with the aggregate function count_distinct
and should always return a number. We fix that.
Part-of: odoo/odoo#112825
Let us have records with values false, 1, 2, 1, 1 for a many2one 'm2o'.
read_group allows to get those ids in an array with the aggregate function
array_agg:
read_group([], ["m2o:array_agg", ...], []) will return
[{ __count: 5, m2o: [null, 1, 2, 1, 1], ... }]
We now support the use of array_agg for many2ones in the mock server.
Part-of: odoo/odoo#112825
This commit is a refactoring of the domain selector to simplify it.
The component DomainSelector now uses less sub components.
Consequently, the code is centralized in fewer files and more readable.
closesodoo/odoo#110978
Task: 3149707
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
repro steps:
1) in any kanban view that is not grouped, use the arrow key to focus the last card
2) use the up key to focus the previous card
3) use the TAB key to focus any element inside that card
4) use the down key to try to navigate to the last card -> traceback
The error comes from the fact that `focusNextCard` assumes that the
focus is exactly on the card element and not on any of its children.
closesodoo/odoo#112797
X-original-commit: 76434f4959cd0fade41ad02f790226f1a8046fea
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the legacy CustomCheckbox and the backward
compatibility layer for the systray items. Both of them are no
longer used.
closesodoo/odoo#112718
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Aaron Bohy