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>
This commit fixes the wrong label that was displayed when options
are defined inside groups. Since displayValue was only looking for
a label on choices set using the choices props, the getter was only
returning the technical value for choices defined in groups.
A test has been modified to verify that the correct label is shown,
also on choices present inside of a group. This test previously
asserted that, but only on choices given by the choices props.
closesodoo/odoo#112766
X-original-commit: 176e61d5c25111a1e9339a0687bb526d1d430790
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
The redirect function in the router exists only for the wait option.
This option is only used in one case (client action home). We have
therefore decided to remove the redirect function and to call
browser.location.assign(...) directly.
We will also remove the "wait" param for the "reload" and "home"
client actions. Because no call to "reload" needs it (1) and all calls to
"home" want it wait=True. So we will move the code that was executed
if wait=true to the "home" action client.
(1) In the POS, wait=true is used for a "reload" but this has no impact.
Wait=true was intended to wait for the server to restart before reloading
the page. In the case of the POS, there is no restart of the server, so
wait=True is useless.
closesodoo/odoo#112621
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>
Before this commit, some QUnit asserts and test helpers taking a
"target" param (or equivalent) would try to evaluate it, among other
possibilites, as an HTMLElement.
This is too restrictive however, as all these helpers can also be
performed on 'Element' instances (querySelector, classList, etc.), which
covers other sub-classes than HTMLElement, such as the whole range of
SVG Elements.
This commit changes the checks for `instanceof HTMLElement` to
`instanceof Element` instead to allow the helpers to be used on the
whole range of native Elements.
Part-of: odoo/odoo#110819
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit introduces a hook named "useVirtual" which allows to filter
a given list of objects and return only those that are visible in the
current viewport. This effectively allows to use virtualization in lists.
The hook will trim down the list of objects it received to those that fit
in the current viewport (with a fixed margin above and under to allow
smoother transitions on scroll).
The following requirements must be met to use this feature:
- the scrollable area has a fixed height
- along with the list of items, a "getItemHeight" getter must be
provided to determine the actual height of each individual item;
- the items are rendered with a proper offset inside the scrollable area.
This can be achieved e.g. with a css grid or an absolute positioning.
Part-of: odoo/odoo#110819
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit handles 2 things:
1. bring the mock server "copy" handler closer to its actual
implementation, supporting a second argument which is a dictionnary of
default values to be applied to the copied record;
2. make the mock server debug logs more readable, with a nice color code
(blue for requests, orange for responses) so that debug info are easier
to read in the console.
Part-of: odoo/odoo#110819
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit improves the performances of the mock server "read" handler
by reducing the amount of iterations performed on the current set of
records.
This was needed as some tests (namely: gantt manual performance tests)
mocked huge amounts of records and the main bottleneck was the mock
server, while the actual impact was supposed to be measured on the
rendering process.
Part-of: odoo/odoo#110819
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@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, the bottom row of control panel in
list view could change height when reducing window size
and give an ugly layout.
This commit gives more flex to this row to keep a correct
layout when reducing window size.
task 3095775
closesodoo/odoo#110277
Related: odoo/enterprise#36895
Signed-off-by: Adrien Dieudonné (adr) <adr@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>
# Steps to reproduce
* Have Arabic language installed
* Create an invoice
* Register a partial payment (keep invoice open)
* Switch to Arabic language
* Click the register payment again
=> You should be met with a traceback
# Cause
Currently, the `parseDate` function relies on `parseDateTime`. If no
format is passed to `parseDateTime` (like in our case), the user's
`localization.dateTimeFormat` is used. `parseDateTime` implements
workarounds to allow parsing of dates (without a time).
However, those workarounds do not work with languages such as Arabic.
opw-3133992
closesodoo/odoo#112354
X-original-commit: 869b01da4948775d9a3009426a74cc9207e81374
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: huvw <huvw@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>
Date fields are changing format if you type it in instead of using the
date selector calendar popup
Steps to reproduce:
1. Install Time Off
2. Open the current language and change the date format to `%d.%m.%Y`
3. Go to Time Off > Approvals > Allocations
4. Create a new allocation
5. Change the validity period to 10.03.2023 (by typing it in, not using
the datepicker) and click out of the field
6. The date displayed is changed to 2010/03/20 or 20.03.2010 (if the
datepicker was opened)
Solution:
Add dot and comma as a possible character for static format
Also deduplicated function isValidStaticFormat so we have a single
definition
Problem:
Formats using dots were not considered as valid static format so the
value entered was parsed with the format `yyyy/MM/dd` instead
opw-3081268
closesodoo/odoo#112218
X-original-commit: 18d6944510b55a4de21be050b8fef327f00e71d5
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
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
Those views are no longer used and about to be removed. This
commit also removes the benchmark lib as it is no longer used.
Part of 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>
This commit aims to solve two problems:
1. Keeping the hash if no action_id or menu_id is passed as a parameter.
2. Always force a reload of the page.
Description of the issues:
1. When reloading from an action, we just want to force a reload of the
page while staying on the same action. We only want to modify the hash
if we want to reload the page by opening another action.
2. When installing the website module, an error dialog is displayed and
the page is not reloaded because location.assign(...) only causes
a reload when the url has changed (path or search, it ignores the hash).
The error comes from trying to access a client action that is not yet
in the assets. It will be added when the page is reloaded.
Solution:
1. Modify the hash only when you have action_id or menu_id in the action params
2. We have thought of two solutions:
- Do a location.reload(...) when the url has not changed. The error
appears during the reload time because location.assign(...) modifies
the hash. The service action will then try to execute the client action
which does not yet exist. (legacy solution)
- Always have a different url so that location.assign(...) causes a reload.
So we decided to add/remove the reload key in the url search. This will
always force a reload. We will opt for this solution because it avoids
displaying a crash.
closesodoo/odoo#112077
Taskid: 3144132
X-original-commit: 77772c0e73d9f561fed63847175e2dbc9b809fa1
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>
This prevents the property field from calling repeteadly the server for
an information that (almost) never changes. Note that all checks should
probably go through this services for the rest of the codebase.
closesodoo/odoo#111571
Signed-off-by: Géry Debongnie <ged@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
Before this commit:
- Let's say we are in January 2023
- User's TZ has an offset from UTC (say UTC+2)
- Purchase > Create an rfq
- Set order deadline to 1st of next month (February), at 0.05am
- Add some products
- Confirm order
- Go to Reporting > Purchase then pivot view
- Add a filter on Order Date for the current month (January)
- Collapse the row groupbys
- Group the rows by Order Data > Month
- You can see the record of February and it should not be seeable.
After this commit
- the date range is now properly computed
closesodoo/odoo#111847
X-original-commit: 20c9e473419b92bbed01617c494b75847c60eea9
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Kristjan Tehu <kristjan.tehu@estpos.ee>
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>
Steps to reproduce:
- Install Dashboard, Inventory apps
- Go to Inventory > Products
- Add a custom filter "Quantity on hand > 0.00001"
- Favorites > Add to my dashboard > Add
- Go to dashboard app
Issue:
JS Traceback is raised: `Expected "]", got "(name)"`
When executing the rpc call to `/board/add_to_dashboard`, the number
`0.00001`, which is passed as argument, is decoded as `1e-05` in the
python code and stored in the custom view.
When parsing the same view in the frontend, the tokenizer fails to
detect `1e-05` as a floating number and an error is thrown while parsing.
Solution:
Add regex for floating point numbers in scientific notation in `py.js`.
The regex accepts numbers such as:
- 1.2
- 12.
- .1
- 1e-02
- 1.2E-2
- 12.e+2
- .1E3
opw-3038707
closesodoo/odoo#111664
X-original-commit: d2d23e517fb81ab3779f6f0dbf0d035544c863d8
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@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>
Before this commit, the creation date and last modification date in
the metadata dialog (in debug, in any form view, click on the debug
item, then View Metadata) were displayed in UTC, whereas they
should be formatted in the user timezone. This commit fixes the
issue.
closesodoo/odoo#111153
X-original-commit: 104e17211be9098b48eac842d65b1c378af5c05a
Signed-off-by: Michaël Mattiello <mcm@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>
Vincent Schippefilt