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>
The goal of this commit is to disable sample data mode when creating
a record using an on_create action in an empty kanban view.
How to reproduce:
- Go to an empty kanban view with an on_create and sample="1"
- Click on the create button
- Validate the creation
Before this commit:
The kanban view is still in sample data mode.
After this commit:
The kanban view deactivates the sample data mode.
closesodoo/odoo#112732
Taskid: 3176939
X-original-commit: b5909daaa16466321a0ad85aaf013155c0bcf5b2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds several improvements and overall changes the way
draggable builders can be built, adding some helpers to temporary
manipulate DOM elements during drag sequences and making some changes
on the way drag callbacks are handled.
The current implementations of draggable hooks built with this feature
have been adapted.
The drag test helpers have also been reviewed to more accurately
mimick real-life scenarios and allow for more flexiblity (i.e. moving an
element to a certain point during the drag sequence before being
dropped).
Part-of: odoo/odoo#110819
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
After a model in sample mode has fetched sample data, its orm is reset
to be the "true" orm (standard orm service using the real server (prod)
or the mock server (test)). Thus any change in the view parameters that
imply to fetch data will lead to fetch "true" data (possibly none) and
thus present "true" data in the view. The problem is that the graph and
pivot views did keep the class .o_view_sample_data in that case.
Here, we make sure that that class is removed at an appropriate time.
closesodoo/odoo#112612
X-original-commit: ae6ec8dcfb24b86743e3ee14ae2526b4f8b681b9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this revision, the pivot view used the wrong label for the
headers in the case of the group by value was "0". This was due to
the use of the falsy value of the group by value to determine if
the label should be used or if the label should be "Total".
closesodoo/odoo#112571
X-original-commit: 97db8c975643bb79e95f7506da03c7142651a3cf
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, when creating a new record using the quick create on
a kanban view, a flickering was visible. We can see the quick create
form disappear, the record list goes up, the quick create form re-appear
and the record list goes down again.
This occurs because, the record list contains an empty record that is
used on the quick create form. When clicking on the add button on the
quick create form, this record is directly saved, and as is already on
the list (the quick create form disappear and the record list goes up),
only after this action, a new empty record is created and added to the
list (the quick create form re-appear and the record list goes down
again).
Now, an empty record is created independently of the list, so when we
click on the add button on the quick create form, the record is saved,
a new empty record is created (the quick create form is emptied), and
the saved record is added to the list (the record list got the new saved
record), avoiding the flickering.
task-id=3085247
closesodoo/odoo#112367
X-original-commit: 9c82f5dca00921b6911671db3845ad593d2e1191
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, if a many2x fall the quickcreate, it will fall back
correctly to the slow create, but it will also raise an error.
Now, the error is not raised anymore.
closesodoo/odoo#112311
X-original-commit: 800e7ab6658b013930e6691cf778bb425da3e723
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
Before this commit, in a form view, it was possible to open a record in
a x2many list field when the list is editable (`editable="top|bottom"`)
and the form view or the field is in readonly.
We want to disable the opening of the record in this case to stay
consistant for a better UX:
- when in a editable x2many list, the record form view never opens (even
if the form view or the field is in readonly)
- when not in editable, the form view always opens
This commit does not modify the behaviour of the x2many field kanban
view.
task-2964320
closesodoo/odoo#110838
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The CopyClipboardButton Component acts as a button. As such it is
interesting to add the possibility to make it disabled when needed.
This commit adds the possibility to add the attribute `disabled="1"`
to the xml code and let it function as one should expect.
See task 2672713 for a practical use.
closesodoo/odoo#111724
Signed-off-by: Luca Vitali <luvi@odoo.com>
`formatFloatTime` uses `Math.floor` to compute minutes out of float time value.
It doesn't work in edge case when the float value is already rounded (e.g. by
server). Example:
* 35 minutes is 0,58333...
* server rounds value to 0,58 hour
* 0,58*60 = 34,8 minutes, which is rounded to 34 minutes by `Math.floor`
STEPS:
1. Field Service > Any task > Timesheets tab
2. Add a line for 1:35
3. The total shows 1:34
4. Add another line for 0:45
5. The total shows 2:19
opw-3091805
closesodoo/odoo#111890
X-original-commit: e3417200913623c56d430f163f731d4424f7cc70
Related: odoo/enterprise#36687
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
This commit fixed the ExportDialog used when there are the same
field used multiple times in a list view. Since those duplicated
elements were given twice to the dialog, there was a bug causing
a crash due to a duplicated t-key in the template.
Since duplicated fields must not be displayed twice in the list
of available fields to export, the defaultExportList has been
filtered to only return unique elements.
A test has been added to verify that duplicated fields are not
given twice by the list controller, by only displaying once the
corresponding field.
ticket #3150866closesodoo/odoo#111884
X-original-commit: 74b09fbd346f5759fc3fa8ed28ec15d5f58a7a42
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit:
model translation:
when the user changes the translation for the current language in the
translation dialog, the value in the form view is also updated and marked
modified.
But if the user wants to invalidate the translation and set the translation to
`false`, the form view value is also updated to `false`, if the user saves by
accident, all translations are lost.
model_terms translation:
when translations are modified in the translation dialog, the field value will
not be changed
after this commit:
form view data will be reloaded after translations changed in the translation
dialog
closesodoo/odoo#111869
X-original-commit: 9aab8347a1a4cc74050dd2e5035cba838b93863c
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Before this commit, there is no way to "void" model translations, i.e.,
discard a translation and let the value fall back on the 'en_US' value.
The API of methods write() and update_field_translations() can only
overwrite the translations for the specified languages.
After this commit, calling update_field_translations() with a falsy
value except the empty string discards the corresponding translation
value, and let the value of the field in the given language fall back on
the 'en_US' value of the field.
X-original-commit: 5434fb845c393327db377abf872c448f4860a7d3
Part-of: odoo/odoo#111869
Purpose
=======
Extend the customization of the confirmation dialog
by creating 2 new optionnals attributes:
"confirm-title": To change the dialog title
"confirm-label": To change the dialog confirmation label
Task-3098731
Part-of: odoo/odoo#108410
**Current behavior before PR:**
Even when the "drag-handle" is already hidden (since the field is already readonly),
the items of x2m field can still be resequenced by the user.
**Desired behavior after PR is merged:**
User should not be able to resequence the list items when the list field is already
readonly.
**Solution**
If a shown list is representing a x2many field, it makes sense to prevent
resequencing when the field is "readonly". However, the list is oblivious
of that property unless we force it, therefore we introduce the "readonly"
props to the list renderer.
Note that a heuristic was tried to compute "resequenceability" based on
the "editable" property, but that is rather difficult if not impossible.
Also note that "readonly" defaults to "false" to be compatible with the
current situation where the list is rendered -- list view, field, select/
create dialog -- which by default, the items can be resequenced.
closesodoo/odoo#111797
X-original-commit: 7682a5c87b8e2f59a4c277143d6054adb40edef9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduction:
1. On Odoo 16, install Sales
2. Go to Sales -> Configuration -> Quotation template
3. Click the example “4 person desk”
4. In the “Lines” and “Optional Products” tabs, the translation button
is not show in the Description field
5. In Odoo 15, it shows the translation button
Reason: 1. In text_field.xml, the translationButton is not in the same
div element. This causes the translation button is hidden when in the
tree view. This is the case of the Optional Products tab
2. For the case of Lines, another reason causing this issue is the use
of widget “section_and_note_text”
Fix: move the translation button to the same div element with the
textarea in text_field.xml; remove the widget “section_and_note_text”
from the Lines tab. Also added a test for the text field translation
button
The adding of div:
https://github.com/odoo-dev/odoo/commit/98e94d45fd6176d7afdcf682c10ce8894f86915a
Rewrite of Text Field js:
https://github.com/odoo-dev/odoo/commit/32bc28aa665c479e31a40afffca2f03f6f2cc805
Rewrite of section_and_note:
https://github.com/odoo-dev/odoo/commit/5a21823f4364d6db407d48178435de041b157b44
An community PR for the translationButton by niyasraphy (same change):
https://github.com/odoo/odoo/pull/111291
opw-3078122
closesodoo/odoo#111763
X-original-commit: 99a23902bd2002099322b5c36fac94c8bd500951
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: niyasraphy <niyasraphyk@gmail.com>
Before this commit, there was a weird issue with tooltips. If the
element was entered very slowly from the left or top, sometimes,
the tooltip didn't open.
The problem came from the way we closed the tooltip. This was done
by checking the x and y mouse positions within a setInterval, and
if it wasn't inside the element having the tooltip, the tooltip
was closed. When approaching the "?" icon, the mouseenter event was
triggered, we registered the setTimeout to open the tooltip. In the
next ms, the setInterval callback to check whether the mouse is
still hovering the element was executed. We observed that when the
mouseenter event is triggered, the x and y mouse positions aren't
yet inside the element, for 1 or 2 px (like if the mouseenter was
triggered too soon). As in the scenario, we move the mouse very
slowly, the setInterval callback determined that the mouse wasn't
hovering the element and thus cancelled the setTimeout callback that
will open the tooltip.
This commit fixes the issue by changing the way we detect that we
have to close the tooltips. We now listen to "mouseleave" events,
and when triggered on the element with and opened tooltip, we close
it.
Task 3150954
closesodoo/odoo#111718
X-original-commit: 89770d32cbb368f73ab304ea5c1637bd3cc19bcd
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the `field_digits` options of the monetary field
has not been reimplemented since the owl conversion and so the digits
of the currency was used.
Now, when the `field_digits` option is given, the digits of the field
is used instead of the currency digits.
task 3072702
closesodoo/odoo#111308
X-original-commit: 996cc74745a2fb72547053991a79d233d6916587
Related: odoo/enterprise#36568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to add the possibility to define a <control>
in the arch of a kanban view. This works exactly like in the list view
arch. So we can add <create> and <button> that will be present when the
arch is used by an x2m in kanban view.
As a reminder, <control> allows you to add buttons to an x2m in list or
kanban view without js customization:
<create> allows to add a button allowing the creation of a record with
a different context
<button> allows to add a button action.
closesodoo/odoo#111307
Taskid: 3143419
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit makes the data entry of numeric fields
easier by selecting all the content of the input on focus.
task 3132899
closesodoo/odoo#110181
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the buttons of the draft record in a
list view were disabled. Now, they are enabled and will
save (create) the record before executing the button's action.
closesodoo/odoo#110383
Task: 3132960
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This PR change generic calendar view to make it behave more like
google calendar.
These changes includes :
- Scss rules for small event(<15 minutes) so that the title is always readable.
On top of that, the top border of a darker color has been removed
for these even to allow more space.
- Event longer than 24h are now shown in the all day column independent
of their 'allday' status
- Time is now added in the event description, if the event is
shorter than 30 minutes, only the start time is displayed at the end
of the line.
If the event is longer, the start time and end time are displayed
on a new line.
task-id : 3114155
closesodoo/odoo#109736
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
This commit adds a new widget to the field registry. This button
is represented with an icon and acts as a boolean field widget.
The label is shown as a tooltip when hovered.
A test file has also been added to verify its behavior.
task #3121078closesodoo/odoo#110365
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Open User-defined Filters in debug mode;
- Create a new Filter, name it;
- Use Contact model;
- Add a filter in the domain;
- Choose Last Update On;
- on the domain code editor modify it to be :
`[("write_date", "=", context_today())]`
- Save the new filter and comeback to the filter lists;
- Open again the filter;
- Click in "Invalid DateTime";
- Choose a new date;
- Discard the changes;
- Click again in "Invalid DateTime".
Before this commit, a traceback is raised. This error occurs because
Bootstrap's Tempus Dominus don't manage correctly when in the setup we
send `null` as date.
Now, we sent a invalid date to Tempus Dominus.
closesodoo/odoo#111593
X-original-commit: b43f9473d1597b71323488f7d11e5f1fbdf0d638
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
- have a current date of 24/03/2022;
- have a date field of 29/01/2020;
- use compute date (+5d for instance) on the field;
- as the date field changed, the datepicker will update with the new
value : 29/03/2022;
- use again the compute field, with the same value (+5d);
Before this commit, the datepicker didn't shown the result of the
compute date but it will show 05/01/2022. This occurs because the
datepicker updates when the dates are different, in this case the result
of the computation and the current date are the same. The shown date
05/01/2022 is shown because the input have 5 in it.
Now, the datepicker input will always update, and the correct date is
shown.
closesodoo/odoo#111574
X-original-commit: 85a36a183de5a1a68f8566489b307216568dad9c
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, when editing a form view, when editing a input field,
the status indicator buttons (the save and discard buttons) didn't show
up until a click outside the field was done (change event).
Now, the status indicator buttons shown as soon as the input field is
edited (input event).
task-id 3147130
closesodoo/odoo#111387
X-original-commit: 64aa9a6afdc8eb27711f6deb5d6ee3e79e6276b2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in the list view, the html field displayed the value
false when there was no value.
How to reproduce:
- Go to a list view with an html field with a record that has no value for
that field
Cefore this commit:
The value false is displayed by the html field
After this commit:
An empty string is displayed by the html field
closesodoo/odoo#111447
X-original-commit: 6d9a546213db953a8ac78828bf9d0a2d885ac0fe
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Before this commit**
- Be in a far from UTC timezone, i.e. UTC-8. You could mock this with
the Chrome devtools and the following IANA time zone: Mexico/BajaNorte
- Open Calendar App
- Create an all day event from the calendar view: e.g. click on a date
in the month view
- The event is written as expected in the DB, but it is displayed one
day before.
**After this commit**
The event is properly displayed.
**What is the fix?**
The deserialization (read) of the date/time fields is now mirroring
what is done at serialization (write).
The "allday" part was missing at deserialization.
closesodoo/odoo#111432
X-original-commit: 5a1ce3644deeaebf3712280d000f618d15bd93cb
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
This commit adds an attribute in kanban and list archs that
fixes performance issues.
Some tables are very huge and depending of the searched domain,
the search_count made in web_search_read takes much more time
than the search_read. For 10M records, the search_count could take
more than 10x the time of search.
This commit allows to set the count_limit in the arch to override
the hardcoded 10k value.
closesodoo/odoo#111284
X-original-commit: 699215ec9a71b8c9b6a53fe96e924a400d216729
Related: odoo/enterprise#36431
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, the changed test sometimes failed because the
autocomplete dropdown wasn't opened yet when we tried to click on
one of its items. Setting the autocomplete delay to 0 doesn't
remove the setTimeout, but overriding the setTimeout method from
browser like this commit does ensures the callback (i.e. the
dropdown opening) is called directly.
Fixes runbot error 15715
closesodoo/odoo#111178
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
If a field is present twice in a view, the field information
stored in the relational model `activeFields` holds and consider
only the latest xml node found.
Therefore, a field is sometimes considered alwaysInvisible
when it is visible and editable. This means that you might click
on the 'Save' button and get a server error because a required field
is not set when you should the required field should have been
highlighted and requested before making a `create` rpc request.
This commit makes sure that for the alwaysInvisible logic,
both nodes are considered.
closesodoo/odoo#110959
X-original-commit: 3d490a264b2fe837f9dc5138f8605f5466b7c312
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Go to base Runbot and install Time Off.
- Go to Time Off > List View and select a list view item (checkbox).
- Go to Action and notice there is no Archive option.
- Go to the form view and go to Action > Archive.
- See error about not being able to archive leaves.
Issue:
We can see the action archive but we can not run it
Expected behaviour:
We shouldn't be able to see that action archive
Cause:
When computing the value of archiveEnabled we use the wrong variable "activeFields".
Solution:
Give the good one, "this.props.fields"
opw-3079475
closesodoo/odoo#110836
X-original-commit: 122fa724e1f15e8c28a29bbe8a80c089ff954956
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The Record component becomes more and more used, but its API and the flows
it can support are both a work in progress.
Its specs become a little clearer, we probably want two things:
- be able to display some values via Fields widget and interact with them, in
particular relational fields.
- fetch, display and interact with a proper record in the db.
- disconnect it from the use of model in Views (via the hook useModel), because Record's
feature are simpler.
This commit aims at clarifying at least 2 aspects:
- how to pass the values to the record, that is, without reading anything from the db
=> a `values` props contains server formatted data, it supports changing them via the props
- when to reload the data from the db, when not to.
=> when props did not change, don't reload anything.
We expect further improvements on this component, as the feature is still very basic at this point.
See 475f8aa for earlier improvement
closesodoo/odoo#110122
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The setting tag was introduced in [1], it was restricted to the setting
view (the js_class : base_settings).
This commit move the setting tag to the form view, to remove the
restriction and allow the use of the setting tag in any form view.
[1]: c7c2959449
Part-of: odoo/odoo#110432
This commit introduces the documentation link widget, the aim is to
standardize the help documentation links that can be found in the views.
This widget will add an icon (o_doc_link), this icon is a link to the
documentation. Note that you can use relative or absolute path. The
relative path is relative to `https://www.odoo.com/documentation/server_version`,
so it's not necessary to hard-code the server version on the arch any more.
```xml
<widget name="documentation_link" documentation="/applications/technical/web/settings/this_is_a_test.html"/>
```
Task-id: 2980478
Part-of: odoo/odoo#110432
**Steps to reproduce:**
- helpdesk.ticket form view
- set a user on the ticket
- create & edit a new user on the fly
- discard the user creation modal
- [BUG] the avatar of the user that was initially assigned to the ticket is still displayed
**Solution:**
This is because when closing the dialog, we only clear the input. This fix
proposes to also clear the value of the field -- which unlinks the previously
selected record for the field. Note that it only makes sense to do it in m2o
fields so another test is added for extra assertion.
closesodoo/odoo#110781
X-original-commit: df783ada3281e33038253deffd75d35f44b9d579
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a char field with trim option set to True (this is the
default). Open a form view where the value of this field has
leading or trailing spaces. Press F5 (or close the tab/browser).
Before this commit, a write was done before leaving, with the
trimmed value of the char field.
This isn't the expected behavior: as the field hasn't been manually
edited, we don't want to write on it.
This could be reproduced on project.task form views, on tasks with
a name with leading/trailing spaces (e.g. tasks created by mails
sent to feedback@odoo.com).
The issue occurred when we saved a record "urgently" (before unload)
because we parsed the value of each input field, and we sent it if
it was different from the initial (or last set) value. In our case,
parsing the value trimmed it, and it was thus different from the
initial value.
Bug reported after the migration of odoo.com to 16.0.
closesodoo/odoo#110528
X-original-commit: 43b7ae39e633ced6008b067bb4e63ed9be7eda01
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Purpose:
========
The `create_name_field` option of many2one fields in form views does not
work: when setting it, the value entered in the many2one field is copied
in the default `name` field, instead of in the field set, when clicking
on the "Create and Edit" button.
This is because an incorrect prop is used: the many2one component uses a
prop named `createNameField` for that purpose, but passes a prop called
`nameCreateField` to the Many2XAutocomplete component.
This commit renames the `createNameField` prop of the many2one field to
`nameCreateField`, to match the prop used in many2many_tags_field and in
Many2XAutocomplete.
Task-3113954
X-original-commit: c0ff0824d964cd702470076d31c066c5443ce9ca
Part-of: odoo/odoo#110474
Have a one2many that defines a list arch.
The list should not be editable, precisely, when adding a record, it should go through
a form view.
Define a standard form view in DB, not in the main arch, that doesn't have
at least one of the field that the list arch has.
Create a record in the one2many list, change a field in order to trigger an onchange.
Before this commit, there was a crash, because the onchange asked for the field present in the list
and the ones present in the form, but there was a description (the result of fields_get) only
for the fields present in the form.
After this commit, this is solved.
closesodoo/odoo#109749closesodoo/odoo#110410
X-original-commit: c6897e1e1e5bcf3378bddeb58393baa7426b64c7
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form view, from the second opening of a
selection dialog by clicking on the "Search More..." button of a
many2one with a "search_default_..." in its context opened the selection
view without the filter corresponding to the "search_default_...".
Why:
The search model removes the "search_default_..." keys from the context
it is given.
Solution:
Clone the received context so as not to modify it.
How to reproduce:
- Go to a form view with a many2one field having in its context "search_default_..."
- Click on the m2o
- Click on "Search More..."
The search dialog opens with the filter corresponding to "search_more_..."
- Close the dialog
- Click on the m2o
- Click on "Search More..."
Before this commit:
The search dialog opens without the filter corresponding to "search_more_..."
After this commit:
The search dialog opens with the filter corresponding to "search_more_..."
closesodoo/odoo#110342
X-original-commit: 82293c5f4d0955c4688a619bf69e3f0049f10fb6
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
In a grouped list view, click on the header of a column for a
sortable field. The record rows inside opened groups are correctly
sorted. However, before this commit, the icon indicating that the
column is sorted wasn't displayed. It worked fine if the list
wasn't grouped. This commit fixes that issue. It also adds a 1s
delay before opening the header tooltips (1s is the delay we have
for the other tooltips in the list view).
Issue reported in the feedback pad after migrating odoo.com to 16.0.
closesodoo/odoo#110351
X-original-commit: e68e13cfce8eb82248336361998b873f26096634
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] adds a limit on the search_count done to get the total
number of records matching the domain in a list or kanban view
(displayed in the pager).
When the limit is reached (10000), a `10000+` is displayed as
total. Clicking on it performs a search_count to get the actual
number of records.
Before this commit, from that point, the count limit was set to the
total number of records. It means that if a record was created or
modified to match the domain in the meantime, and the user clicked
on the pager to see the next page (for instance), a `+` was again
displayed next to the previously fetched search_count, which looks
like a bug.
To prevent this from happening, this commit simply removes the
count limit once the user has clicked on the total.
[1] 6acfad2651closesodoo/odoo#110348
X-original-commit: 9aab36bcfb682865b615c8fbbc107afeee3a24f4
Related: odoo/enterprise#36001
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This reverts commit 8d437bf.
Because of the above commit, the sample server did not correctly group
the records when a date/datetime field was used as a groupby.
We revert id and add a test.
closesodoo/odoo#110321
X-original-commit: 1a0c688aee7682919b66492636f46eff481abd29
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Have a list or kanban view with 10k+ records (or manually change
`WEB_SEARCH_READ_COUNT_LIMIT` in the code). On a slow network,
click on the pager to go to the next page and click on `10OOO+` to
fetch the total number of records.
Before this commit, this might lead to a race condition where the
total number of records displayed in the pager is incorrect (if the
search_count returned before the web_search_read).
This commit fixes the issue at the pager level. We already disabled
it when clicking on next/previous or editing it. However, this
didn't prevent from fetching the count. Moreover, fetching the
count didn't disable the other features either. With this commit,
the pager is fully disabled when the user interacted with it, until
the view is reloaded.
closesodoo/odoo#110265
X-original-commit: 0ac84bda8de0c1a620d05469562932c0d04e8c3f
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the statusbar added a hotkey even if
it was readonly or non clickable.
Because of this, the user could change the status with a hotkey.
Now, if the statusbar is readonly or non clickable then
the hotkey won't be available.
closesodoo/odoo#110262
X-original-commit: 9569b4f463b6e82df3c8eafb8bd4329faac871b1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
The `expand` attribute in list views can be dynamic (e.g.
`context.get("some_val_from_ctx", False)`). Before this commit, it
wasn't evaluated, so a dynamic value would always result as true,
as it isn't "O", "false" or "False". To instance, go to Invoices
and add a group by. This commit fixes that issue.
Task 3130159
closesodoo/odoo#110235
X-original-commit: 1072c4880fdd2835b0711869da06681dab20d33c
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Open a kanban view;
- Select a progress bar filter;
- Open a record;
- Came back to kanban using the breadcrumb.
Before this commit, the progress bar is selected, but the records aren't
filtered.
Now, the kanban is exactly the same as it was when we click on the
record, the progress bar is selected and the records filtered.
closesodoo/odoo#110224
X-original-commit: ca864d7e6d510ef6410898099364d854a15150d7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Owl last update fixes the leaking `this` in rendering context of
templates called with `t-call-context` [1]. Since [2], we use the
`t-call-context` directive to control the rendering context of
templates compiled from an arch (e.g. in form and kanban views).
We can now better control what people use in archs, where we don't
want them to access js implementation details, as `this` is no
longer available.
However, the component instance still needs to be accessible in
the compiled template. We thus add the `__comp__` key in the
rendering context. Since we do not want people to access it in
archs, we add a check in the view validation that this string
isn't used in dynamic attributes.
[1] https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
[2] https://github.com/odoo/odoo/commit/4c5b867ff6b0b674cb83d1a1262ae354ebaa6d57
X-original-commit: 264f313012aa99449d1576ae1110252c13755142
Part-of: odoo/odoo#110196
Before this commit, when unfiltering a column in a kanban view, a
flickering occurs and the show more button is visible for a moment.
closesodoo/odoo#110130
X-original-commit: 0cd9c7dbba12e362a6445f47d52b43c48dffdb61
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Vincent Schippefilt