Domain widget has Components for every type of field to define list of available
operators, initial value, etc. However, class and template for some fields is
missing (e.g. for binary field).
This commit adds support for such fields via Default class. More specific
classes could be added later.
STEPS
* Activate Debug mode
* Open menu *User-defined Filters*
* Create a filter for `product.product`
* Select any binary field in the domain widget
opw-3084273
closesodoo/odoo#108631
X-original-commit: 3d0044046517690215625c92a6550fd6083fbd93
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
**Issue:**
- Install CRM.
- Change language to French.
- From CRM, open a lead that has `Revenu espéré` thousands as value, e.g. 10 000,00.
- Try changing `Revenu espéré` by deleting one of the thousands digit.
E.g. 10 000,00 -> 1 000,00
- BUG: The modified value is not understood by the system.
**Solution:**
This is because the thousands separator from the French language is nbsp.
Coincidentally, the parsing logic assumes that the separator between the
currency symbol and value is also nbsp. So when inputting `1 000,00`,
the parsers thinks either `1` or `000,00` is the currency symbol.
We concluded that it's better to be less restrictive when parsing
monetary values. So, instead of making sure that the current input's
currency is compatible with the currency of the the field, we just
strip the non-numeric characters from beginning and end of the input
without validating the currency symbol, then parse the remaining
string as float.
This leads to a more user-friendly monetary input fields such that
inputting "DOGE 1,000,000.01" in a "$" monetary field will be
parsed as 1000000.01. NOTE that *no* currency conversion is performed.
**Minor breaking change:**
The second parameter `options` of the `parseMonetary` function is now
removed. Any existing use of that parameter is just ignored.
closesodoo/odoo#107862
X-original-commit: dc27f1f4c039bdbf84c55a4fb5364c6398c45949
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:**
When the thousands separator is "nbsp" and the user inputs a value
that is "1 234", the parser will crash because the thousands separator
is different from what is manually inputted by the user.
This is problematic because when typing, it's very difficult for
users to enter "nbsp" character in their input.
**Solution:**
This change proposes that if the thousands separator is a whitespace,
we consider all whitespace characters from user input as thousands
separator. As a result, even if the thousands separator is "nbsp",
the system will successfully parse "1 234" as 1234.
X-original-commit: bffddcf015da9cf514fc25cc7f839e923e470d94
Part-of: odoo/odoo#107862
**Issue:**
- Set the decimal point to "," and the thousand separator to ".".
- In a float or monetary field, enter "=1.000,1+2.000,2"
- BUG: It's evaluated to: 30003
**Solution:**
Problematic evaluation steps:
```
-> parseNumber("=1.000,1+2.000,2")
- thousands separator are removed and decimals are converted to "."
so the string becomes "=1000.1+2000.2".
-> parseNumber("1000.1") + parseNumber("2000.1")
- since "." is the thousands separator, it will be removed
(replaced by empty string)
-> 10001 + 20001
-> 30003
```
Because the main parser `parseNumber` is recursive in nature, we
need to make sure that the logic that removes the thousands separator
and replaces the decimal point to "." is not called in the branch
that evaluates an input expression.
With this change, the new evaluation steps are:
```
-> parseNumber("=1.000,1+2.000,2")
-> parseNumber("1.000,1") + parseNumber("2.000,1")
-> 1000.1 + 2000.1
-> 3000.3
```
X-original-commit: 91eb5c40ce898428fb15d945d70510b92e9ebb03
Part-of: odoo/odoo#107862
According to the orm documentation, the `digits` attribute of
float fields must be either a tuple (int, int) or a string.
However, people set `digits=0` on a bunch of float fields (some
are there for a while now). Historically, the webclient handled
this as "there's no digits attribute set", so it fallbacked on 2
digits precision.
With the new views, and owl props validation, we assert that the
`digits` props, when given, is an array. In the above situations,
we have a props validation error.
This commit fixes the error by filtering out the `digits` props
when it is not an array, s.t. it keeps working as before (i.e.
fallbacks on 2 digits). In master, we'll remove the fallback.
opw 3083100
closesodoo/odoo#107418
X-original-commit: 36407a9837ba3bf90670ae763751dc631309867b
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
The currency_field shouldn't have to be specified in the view if it has
the same value as the field specification in python.
closesodoo/odoo#107396
X-original-commit: 47cf3688baf6aed6f027fc44db7293d9563789f4
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
This commit adds the ability to enable spellcheck on input/textarea only
if they are in focus. This avoids the UI to be bloated with unwanted
underlined text on unfocused elements. It is especially useful in a context
of form view in always edit mode.
A core hook has been introduced to allow other components to use the same
behavior without reimplementing it. It is currently used by the TextField.
It means it is also used in the HtmlField. Tests have been written, both for
the field component, and the core hook.
task #2861428
Part-of: odoo/odoo#106866
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, when a date field with the remaining_days widget did not have a value
typically on a new record form view, the props validation crashed because the datePicker widget
received the wrong type for its value.
After this commit, this is corrected and there is no crash.
closesodoo/odoo#107233
Related: odoo/enterprise#34668
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since odoo/odoo@69c3d5aa25
the readonly and required modifiers were no longer passed
for non-editable views. Which means:
- kanban: never passed,
- tree: passed only when `editable="1"` or `multi_edit="1"`,
- form: always passed.
The rationale behind that is that a view which is considered
as readonly doesn't need to know if its field are readonly or required,
as by definition, if the view is readonly, the user shouldn't
be able to modify anything in the view.
This was to make the views sent to the web client more light-weight,
not sending unused information, and save KB of transfers.
However, some widgets, used in the kanban and non-editable tree,
allow to modify fields, even in readonly considered views,
and therefore need to know these readonly/required modifiers
from the field definition in the Python model.
e.g. the `widget="color"`, odoo/odoo#103478
Ideally, these readonly/required modifiers should be transferred
only when the widget requires it, to avoid transferring the
readonly/required modifiers
when they are not useful in kanban/tree views
(which is 99% of the time).
However, this would require a bigger refactoring,
which is considered too risky compared to the added value
for a stable release.
task-3013110
closesodoo/odoo#106838
X-original-commit: 5a68d254949f1d0ff545023cfd14890efff10f5f
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
There was a typo in the color_field xml not allowing to disable the
pop-up in case of readonly. A test validates the feature is active.
The color_field now displays the transparent symbol (instead of black
color) in case the color is undefined.
The product configurator also displays the transparent symbol for
undefined non-custom colors.
task-3013110
closesodoo/odoo#106669
X-original-commit: c67c32c2dbe10b4885ec1177852839b3d18ecf05
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
The fix in #106174 was not good.
The translation dialog cannot update not translated terms
the initial term value may be empty "" when the source and the translation are
the same at first. So, the source to for update_field_translations should be
const source = term.value ? term.value : term.source;
closesodoo/odoo#106528
X-original-commit: 1ed5ce6f16d32efc0c5ec4cead67b2d8a57f6c41
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, new model term translations cannot be saved if it has been
translated before.
The reason is while translating fr_FR
the backend needs the mapping {old_term_fr: new_term_fr} to update old_value_fr
However the UI sent {old_term_en: new_term_fr} which was wrong
This commit fixes the bug by changing the key of the mapping from the
old_term_en to the old_term_fr
opw-3074712
closesodoo/odoo#106257
X-original-commit: f28c11917e093d0d3f5d18f0b377cfb24a7dbd92
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
**Steps to reproduce:**
- go to a product page
- replace image (=> image is shown)
- click on "Save manually" (the cloud upload icon)
- BUG: previous image is displayed.
But it was saved: if you move to another record and return then it
shows the correct one.
**Solution:**
Basically, in an image_field: If its props.value is a "binary size",
then the image source is a url pointing to a server endpoint and
this url is based on the rawCacheKey, otherwise, we use the "base64"
of the uploaded image.
The proposed solution for the said issue is to invalidate the
rawCacheKey during upload. Then, during the calculation of image url
(at `getUrl`), we reassign the rawCacheKey with the newest
"__last_update" value of the record when needed (if the props.value
is a "binary size").
closesodoo/odoo#106236
X-original-commit: 93911daab238e96c8aa9b0a951b9a268d83a9847
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Have a many2one field with a domain set in the field definition in
python. Use this field in an editable list view, with a domain set
on the field node. For instance, go to Sales > Sales Team and see
Team Leader field.
Before this commit, we combined the field domain with the domain
set in the view, which isn't the spec. The spec is to use the
domain set in the view if there is one, and if there is not, use
the field domain (see _getDomain in basic_model.js).
In the scenario described above, it produced a crash because the
field domain couldn't be evaluated with the fields defined in the
view.
This commit restores the previous behavior.
closesodoo/odoo#105774
X-original-commit: 32654fd17ab366d20fff8b3fc8134ee209569f1d
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
\- Add 'Move to next stage'
Generic, we think it is a useful tool to have anywhere.
\- Change the 'Set priority...' command
to 'Set priority as Low/High' :
Only 1 command will be available with the 'not current' priority.
Specific, because it is used on selection fields,
which means there could be more than 2 options.
\- Transform the 'Set kanban state...' command into three commands
Generic. 2 commands will be available.
One for each 'not current' kanban state.
task-2857447
closesodoo/odoo#91821
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The goal of this commit is to fix indeterministic crashes
in Many2ManyTagsField test suite.
We could see that the wrong helper was used in some tests. We used
selectDropdownItem after an editInput on this same field.
Cause of the error:
editInput => event input debounce which causes the autocomplete to open.
selectDropdownItem => event click which causes the autocomplete to open.
After this event, a second click takes place to
select the dropdown item (call to clickOpenedDropdownItem).
The setTimeout is not patched, it is possible that the input event takes
place after the click which does not cause any crash. But if the click
event happens after the input then the autocomplete is closed before
the dropdown item is selected.
To solve this, we will patch the setTimeout and we will use only
clickOpenedDropdownItem to select the dropdownItem.
We also patched the setTimout in all tests to avoid indeterminate
behavior related to the debounce in the autocomplete input.
closesodoo/odoo#105693
X-original-commit: 36f6e6801166865e0c8047c1c2be43ef8826581f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When editing a m2m avatar field in the list view, keyboard navigation,
e.g. pressing arrow-left when the focus is on the right-most item,
results to a crash. Also, the "delete" button when in edit mode
is not there anymore so the user is unable to remove items.
This is because we are not building the proper list of tags. More
specifically, we fail to provide `onKeydown` and `onDelete` handler
to the tags, thus, it crashes and no delete button. This proposed
change fixes both issues.
closesodoo/odoo#105467
X-original-commit: 02a046708a96567a41b5f9aec0f71cefc92ab981
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
- select a language where thousands separator is not (e.g. portugese)
- try editing any number input field
Bug:
error when parsing the new value when thousands separator is not defined
Fix:
fixed default value (only fallback to commas if it's not the decimal
Point separator)
opw-3041135
closesodoo/odoo#105312
X-original-commit: 71712acdf259aca7745a8a0b41a022d3abdcb047
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Issue:**
When a copy clipboard field is empty, there is no way to edit it
because the Field component is not shown.
This issue can be reproduced using any type of copy clipboard field:
- CopyClipboardChar
- CopyClipboardText
- CopyClipboardURL
Check the following video for illustration:
https://youtu.be/CTzqJRtwqv0
**Solution:**
This PR proposes a fix of *always* showing the copy clipboard field
(together with the copy button) even if the content is empty.
For illustration, check: https://youtu.be/jMM7zn_mFCU
**Notable changes:**
- The modified tests were using a wrong class name. But since they were
asserting the "non-existence" of the copy button, they were working.
- We are casting null text field to empty string (just like char field)
so that we avoid crash (in dev mode) when passing a "boolean" as 'content'
props to the 'CopyButton' component. This is asserted in the augmented
test case where we also try to render an empty text field.
closesodoo/odoo#104248
Task-id: 2861388
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Open studio in any form view
- Add Binary Field
- Close Studio
- Upload a file in the previously added binary field
- We can't download it because of always edit
This commit adds a new download button near edit and clear button
opw-3028094
closesodoo/odoo#104961
X-original-commit: 73a2329b8bf4e887890cae7669bc568ae0be7147
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this commit, accessing parent in a button context broke the button
throwing `EvaluationError: Name 'parent' is not defined`.
to fix,the proxy object `params.evalContext` was passed to `evaluateExpr`
similar to examples seen in `list_renderer.js`
closesodoo/odoo#102293
X-original-commit: 90afb529969ce7de83a20060f5c35a64ce4cf971
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
In the PR #97692, writing empty str `''` to a model term field no longer removes
all translations. Instead, only the translation for the current language is set
to empty str `''`.
Before this fix, if a web user sets a translation to emtpy str, and reopens
the translation dialog, the translation will be reverted to the 'en_US' value
which is wrong.
closesodoo/odoo#104181
X-original-commit: f97ff6308d472121e65a34d30b4dc5ab35065220
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
As of now, if a user clicks on the "Save & New" button while the form is
not valid, it will disable all buttons without any options to make them
enabled again. The only solution then is to close the form and re-open
it.
Steps to reproduce:
Inventory -> Configuration -> Route -> Select any route -> Add a line to
the rules.
As soon as you click on the "Save & New" button and the form isn't
valid, you can't use any buttons anymore.
Part of task-2985735
closesodoo/odoo#102315
X-original-commit: 6d63d1035b28f2004774a99a7be84b92a1cb1883
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, if a translation dialog was open, and the view where
the button is unmounted, the dialog stays open.
Now, the dialog closes, when the view is unmounted.
closesodoo/odoo#104543
X-original-commit: 40596ed1eccdf0f37b4fa3a8a337e7a7cc3461ce
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps:
Go to timesheet (grid view).
Launch the timer.
Got to list view and check the new line.
Issue:
Few seconds before the minute, the seconds are negative.
Fix:
Convert hours decimals in milliseconds before calculating minutes and
seconds.
Also deleted the unnecessary condition for abs().
Also changes some `${...}` to String(...) to reduce noise.
closesodoo/odoo#104209
X-original-commit: 9d3e7ab4e903d2ada99693aa23e024d3ff84f5fb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, the Datefield dropdown did not close when you
scrolled on the page.
How to reproduce:
- Go to a form view with a date field
- Click on the date field input (datepicker is opened)
- Scroll down the page
Before this commit:
The datepicker is still open
After this commit:
The datepicker is closed.
closesodoo/odoo#104160
X-original-commit: d93ed838fdf0a721426dc56e26b5a83b3af6a66f
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
The web client exposes an utility function that converts the tokens
of a luxon's DateTime format into a moment.js format.
While this function is not false (still it is uncomplete), the strategy
of using it to convert a luxon's DateTime object into a moment.js moment
is not good.
The daterange field make use of this bad strategy.
Because of the differences between luxon and moment.js locale handling.
Luxon relies on the native JavaScript Intl API.
Moment has its own implementation of locale handling.
So having to pass through formatters/parsers may yield to unexpected
results. For instance, when a locale does not have the same way (in
moment.js and Intl) to express i.e. months and we try to convert a
luxon's DateTime into a moment by formatting the first and then
parsing into the second, the second will be invalid. This is the same
the other way around.
This was in fact encountered with some locales, i.e.
- syrian arabic (ar-SY)
- albanian shqip (sq-AL)
This commit brings an alternative strategy by providing other utility
functions to directly convert a moment into a luxon's DateTime
and vice versa.
This is a better strategy for various reasons:
- it abstracts the way the conversions are done
- no need to play with timezone's offsets
- probably all libs that has moment as a dependency accept a moment
object in their options, that may not be the case for formats
- The daterange field now use the new strategy
- The datepicker component now use the new utility functions as it had
implemented locally something similar.
closesodoo/odoo#104138
X-original-commit: 9dedfcaa4ad1fb5ea24f604b40df1bf0830617cb
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This makes sure that the handler is properly assigned/removed
to/from the added/removed input elements.
closesodoo/odoo#104114
X-original-commit: d88b5e96a4d4a80dd14a271538a4669a6efd2d48
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When NumpadDecimal is triggered, appending the decimalPoint to the
input field value is not enough, rather, we should replace the selected
range.
Also, we should ignore this for input field of type="number" because
it's natively taken into account.
X-original-commit: 3389cd2226ec82df9aa015637ac2d6a405936a4a
Part-of: odoo/odoo#104114
This commit adapts the codebase to match its enterprise counterpart
where calls to legacy cookie api (cf. web.utils.cookies) are replaced by
cookie_service ones.
closesodoo/odoo#104080
X-original-commit: 724469e19ff83e91a41c6721e334df1ad8d1c02c
Related: odoo/enterprise#33189
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
**Before**
A traceback is raised when pressing shift-tab on the first column of
the first row in a focused list field as shown in the vid:
https://youtu.be/g97ZTp1QdBE
**After**
shift-tab on the first column of first row will now unselect the list field
and immediately focuses on the previous field.
**Additional change**
We now allow skipping focus on the dropdown toggler by introducing new
props.
closesodoo/odoo#103485
X-original-commit: 9ba9977e42d201035b5299bc13ba03211cddbc1f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
When a x2many record is opened in a X2ManyFieldDialog, it can happen
that the form renderer displayed in the dialog also contains a x2many
that use a kanban or list renderer. In those cases, the View component
is not used. Consequently, the WithSearch component responsible for
making available a search model in the env is not used either so that
a crash occurs at the setup of the kanban renderer (and sometimes later
on for the list renderer). We fix that problem.
closesodoo/odoo#103349
X-original-commit: 2c284317b6dc3c0f0b4e9e376dcee755d81222da
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit removes the code that wrapped legacy fields and widgets
(coming from the legacy registries) into owl components and added
them to the wowl registries. This temporary compatibility layer,
which was incomplete and only allowed us to merge the new views
without converting all fields/widgets in once without breaking
everything, is no longer necessary as we now have converted all of
them into owl components.
X-original-commit: 555959c87e25faa71396f61479e8bb41b66ac164
Part-of: odoo/odoo#102606
Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting.
That fix prevents attachments from 'dangling' and being garbage collected later.
That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now.
related commit: c112361bf9e2f5e7b087c5e5b9a31879856b1da4
task 3003939
closesodoo/odoo#103038
X-original-commit: 69fdca133b06eb66443635bc52d380233580ef51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since o_form_view class was not placed on the right element, as the
form is displayed in a dialog, some styles were not applied in x2Many
dialogs using a form view. Now, the selector matches all cases and
dialogs will be stylized as expected, since the class is placed on the
dialog container instead of the first div.
Now, we are consistent both for dialogs and standard form views.
Tests have been adapted to work as expected.
closesodoo/odoo#102953
X-original-commit: af67305b43d51e1669df19d376d9bda7418ba863
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
This commit adapts several components in order to correctly handle
color-scheme variations.
It also allows user_menu to handle switch entries
task-2710677
Part-of: odoo/odoo#102868
In legacy, an m2x autocomplete would not display extra lines
received from the server inside the dropdown menu.
This commit reintroduce that behavior as it was lost in the
wowl conversion.
closesodoo/odoo#102954
X-original-commit: 1b2686aeadfac97f060a07de86e5a0eb2051eee2
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the rows attribute given on the TextField component
was always 2, it is not possible to alter it without overriding the
component.
This commit adds a props to be able to update the rows with a prop
called `rowCount` and this prop can be set via `rows` attribute set on
the field.
task-2947516
X-original-commit: 110915c80c2a2578563283b1744e0e88d80ac4bb
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, editing a domain field with an invalid value
for the field type will display a parsing error.
The purpose of the commit is to reintroduce the old behaviour of the
field, it should not display an error.
How to reproduce?
- Go to a form view with a domain field (in_dialog=True)
- Click on the "Edit Domain" button
- Add a domain comparing a field of type int with "01/01/2000"
Before this commit:
An error is displayed.
After this commit:
The domain is applied with the wrong value.
If the server considers the domain to be false, then "Invalid domain"
is displayed.
closesodoo/odoo#102753
X-original-commit: 7f22512149f5d634306cf0b280d055a60ba9e356
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the behavior of date, datetime and daterange
fields. It was no longer possible to open the date/datetime picker
by clicking on the corresponding label, since the inputs were
missing the id attribute associated with the label.
Now, it is possible again, and hovering the label will correctly
highlight the input border of the field.
Tests have been added too, to make sure this works properly.
closesodoo/odoo#102742
X-original-commit: 0e35d2b995165cfcb50db7eaec44cce7547eb4e4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
When a m2m field add a context in its arch, it's passed through to the
rpcs made to the server. In a m2m situation, while the name_search
worked properly, the read operation on a dropdown item select did not
provide this context.
This PR fixes that.
closesodoo/odoo#102741
X-original-commit: 5c7066fc064ecc175104603d524b52991678a2cd
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to allow the restoration of open pages
in notebooks of a form view when switching view.
How to reproduce?
- Go to a form view with a notebook.
- Select a page in the notebook
- Go to another view
- Use the breadcrumb to go back to the previous form view
Before this commit:
The page opened in the notebook is the default one (the first one
or the autofocus one)
After this commit:
The page opened in the notebook is the one previously selected
closesodoo/odoo#102468
X-original-commit: 160c0347526612b6e6f93b8079eeb868d37d48f4
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, in new views, it is no longer possible to click
on buttons with barcode_trigger="..." using a barcode scanner.
Why:
New views no longer propagate all attributes to the button.
How to reproduce:
- Go to a form view with a button with barcode_trigger="doit"
- Scan "O-BTN.doit", "Enter".
Before this commit:
Nothing happens.
After this commit:
An event click is applied to the button.
closesodoo/odoo#102423
X-original-commit: b4cb2ee2662173e08f671eb736130f8332265de7
Signed-off-by: Georis François (fge) <fge@odoo.com>
Even if the `StateSelectionField` is readonly we doesn't want visual
difference and we remove the `disabled` class.
This behavior is the same as in 15.
We also remove `btn-link` as it's not appear as a link and we had to set
`p-0` to avoid the growing of the cell.
Steps to reproduce:
> Open the helpdesk app
> Click on VIP Support tickets
> Go to the list view
> Add kanban_state column => visual bug
closesodoo/odoo#102504
X-original-commit: 26d6942ed1b0c328d94e7dfd5e50c18a68c8c2f3
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Ivan Yelizariev