Purpose:
Allow quick assignation of records in the kanban views (and other places
by extension).
Currently, if you want to work in a board-like env (e.g. tasks in
kanban, crm in pipeline, that kind of thing), having the possibility to
quickly assign/unassign records without having to open them fullscreen
can be really useful => it should be possible to "quick edit" these
fields in kanban views easily, without switching to form views.
If you want to keep the field readonly don't forget to add the readonly
attribute.
Task-id: 3121207
Part-of: odoo/odoo#114400
Purpose:
Allow quick assignation of records in the kanban views (and other places
by extension).
Currently, if you want to work in a board-like env (e.g. tasks in
kanban, crm in pipeline, that kind of thing), having the possibility to
quickly assign/unassign records without having to open them fullscreen
can be really useful => it should be possible to "quick edit" these
fields in kanban views easily, without switching to form views.
If you want to keep the field readonly don't forget to add the readonly
attribute.
Task-id: 3121207
Part-of: odoo/odoo#114400
Before this commit, in x2m fields with a parent record dependent context,
the context used to generate default values for a new record by clicking
on "Save & New" could be wrong. It was not based on the edited values of
the parent record.
How to reproduce:
- Go to a form view with a text field (field_a) and an x2m field with the
context { default_field_b: 'field_a' }.
- Edit the 'field_a'
- Click on "Add a line"
A dialog opens with the edited value of 'field_a' as the value for 'field_b'
- Click on "Save & New"
Before this commit:
A dialog opens with the unedited value of 'field_a' as the value
for 'field_b'
After this commit:
A dialog opens with the edited value of 'field_a' as the value
for 'field_b'
closesodoo/odoo#114460
X-original-commit: b22ef9d2cc4119c8cd6e9c72103279e37f043440
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit 17a24020ac, StateSelectionField
displays its label in all views. This was an error. It should only
display its label in list views.
closesodoo/odoo#114538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the possibility to display a properties field in a list
view.
How it works:
When a properties field is present in the arch of a list view, it will
not be displayed directly. It will display its properties as an optional
column. Now, we will find at the end of the dropdown of the optional
columns a section by record parent of the properties field. The proposed
sections will be the properties linked to the parent record of which at
least one record referring to it has been encountered during the
navigation in this list view.
(A parent record is the record storing the properties definition).
Limitation:
Multi-editing is not applicable on properties fields as you cannot edit
one property without modifying all the others.
closesodoo/odoo#112005
Taskid: 3105039
Related: odoo/enterprise#37004
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: mcm-odoo <mcm@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
The aim of this commit is to make more warning and error dialogs behave
like the "oh snap" dialog of form views.
task-id=3126594
closesodoo/odoo#112276
Related: odoo/enterprise#37593
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
Currently, the default value of a property is only used when we create
new record. But it can also be used when we create a new property.
Note that the default value is written on the property ONLY if the
property just have been created, to not update existing value on
other records (the goal is to have a behavior similar to normal fields).
Task-3172106
X-original-commit: e3099ae584cef74434fdb51f7fee2ae6250f18ca
Part-of: odoo/odoo#113448
*: hr_skills, project
This commit improves the behavior of the ProgressBar field. Before 16.0,
views had a readonly mode, and to avoid having the inputs always visible,
the user had to click on the progressbar to enter into an edition mode.
Nowadays, this is redundant, and make it difficult to guess that the field
is editable. With this commit, the input is always visible, which also
allow to improve the template and the code of the component. The commit
delete unused props/options that were no longer used by the widget.
This commit also remove a legacy scss file that was still present, and the
style of the component has been moved to its own file. Some dead classnames
have been dropped, or replaced by bootstrap classes, reducing the size of
the scss file.
Tests had to be adapted, because some assertions were irrelevant, or were
triggering the click to enter edition mode.
task #3178958closesodoo/odoo#113002
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The external button of the Many2one field has been changed with the
"always edit" feature of the form view, s.t. it displays by default
another icon (a right arrow) and when clicked, opens the related
record in another plain screen action instead of a FormViewDialog.
However, this doesn't work for Many2One fields that are already in
dialogs, because
1) if it's an action dialog (target="new"), that dialog will be
closed when opening the related record and the user loses its
working context
2) if it's another type of dialog (e.g. FormViewDialog), the
related record opens in the background and the dialog remains
open, which is obviously a bad UX experiment. This had been
locally fixes at some places [2].
This commit fixes the issue by automatically opening the related
record in a FormViewDialog if the Many2One is itself already in a
dialog.
This commit also fixes an issue with the scenario where the related
record opens in a dialog: if there were changes done in the main
record, those changes where lost when the user clicked on "Save"
in the dialog of the related record. We now only reload the
display_name of the related record, and apply it to the model.
[2] https://github.com/odoo/enterprise/commit/ba0e95fe42696dcf44b8feddeb302f04876fcbdc
Task 3191319
closesodoo/odoo#112959
Related: odoo/enterprise#37213
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The form view currently reads its data as follows:
1) read the main record, which returns [id1, id2...] for x2manys
and [id, display_name] for many2ones.
2a) read x2manys records, with the context set on the x2many field
node, which returns records like 1)
2b) call name_get for many2ones with option "always_reload" set to
true, with the context set on the many2one field node
3) same as 2), but for records returned by 2a)
The context set on a field node is a string, and needs to be
evaluated (some placeholder values need to be replaced by actual
values), e.g. "{'partner': partner_id}" -> { partner: 4 }.
For 2a and 2b, the context sent is evaluated with the main record
as eval context. For 3, there an additional key "parent" in the
eval context which contains the values of the parent record.
The rationale of this commit is that those data related keys in the
eval context are useless for read-like rpcs.
In the future, the data of the form view will be fetched with a
single rpc, returning the main record and its related records, with
all the values required by the UI. To achieve that, we must ensure
that sub records are never read with a dynamic context depending
on the parent record.
This commit thus directly imposes the limitation, by removing from
the eval context the record related data when it is used to evaluate
the context to send to read-like rpcs.
Part of tasks 3171453 and 3179751
closesodoo/odoo#113527
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Bug
===
If the Reference field is in a list view, and has a default value, an
error is raised if we create a new record without editing the reference
value. This is because the ORM return a string "model,id" in the
onchange method and this value is wrongly parsed in that case.
Task-2234179
closesodoo/odoo#113392
X-original-commit: b1a35d1b95612bc449b68ed38749d8b3755287ed
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This commit revamps the UX of the StateSelection field widget. Now, instead
of filtering the options by removing the current selected value, the field
displays the entire list in the dropdown, and the selected item has a
checkmark to indicate its status.
This allows us to remove the tooltip, since its presence was not useful
anymore, and was unintuitive to use. This changes required to adapt some
tests asserting its presence, as well as the number of items shown in the
dropdown menu.
task #3177182closesodoo/odoo#113203
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The number property should be formatted like a normal integer / float field,
in the form view (show 2 decimal for the float, thousands separators, etc,
even when editing).
Task-3162402
closesodoo/odoo#113449
X-original-commit: 99c251820dcf4791625fabd3fcd61db84280d408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the widget's description was stored on the
component and this component was then registered.
Now, an object describing the widget is used on registration the same way
as it is done for views since b828cfc.
This split the component's description (props, template, ...) of
the widget's description ( component, extractProps, ...) and makes
it clearer.
We did the same thing for fields in 9f4622492c
Part of task: 3179751
closesodoo/odoo#112962
Related: odoo/enterprise#37215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
Before this commit, in a form dialog view, clicking on an action button
in the header does not save the record being edited. The record is reset
in case a new record is created.
How to reproduce:
- Go to a form view with a non-editable m2m
- Click on add a line
- Click on Create
- Edit the new record
- Click on an action button (the arch must contain a <button> in the <header>)
Before this commit:
The record is reset. All encoded data is lost.
After this commit:
The record is created in db and we keep all the encoded data.
closesodoo/odoo#113063
Taskid: 3165983
X-original-commit: 52fdfe0b26941718bf1532e517a51de38cacfdbc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce
=============
- on settings upload a custom background on document layout and save it
- open document layout again and try to download the image -> Traceback
Problem
=======
when calling download method we will ask server for a record with `id=false`
which gives an error
Solution
========
download button shouldn't be visible when `record.resId == false`
opw-3138230
closesodoo/odoo#113029
X-original-commit: 2e2cdee563dd645cabe2d361489d6eb17b174a33
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit is a refactoring of the domain selector to simplify it.
The component DomainSelector now uses less sub components.
Consequently, the code is centralized in fewer files and more readable.
closesodoo/odoo#110978
Task: 3149707
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
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>
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
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, 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>
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, 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>
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>
**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>
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>
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>
Before this change, if a user left a string value in a m2m_tags
and removed it afterward without selecting a tag, the update method
of Many2XAutoComplete would be called with false.
As the update method for m2m_tags expects a record or record list
this caused a traceback.
The fix is to simply skip the update in that case.
task-3109811
closesodoo/odoo#110123
X-original-commit: 14f314feb7594dc888de6af4e4ad23a948044854
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
`fields.Json` is introduced in v16. There are just few usage of it in standard
code. It's usually used via `widget="analytic_distribution"`. However, user may
add the field to list view via a Studio. To prevent errors, this commits adds
basic formatter for the field.
STEPS:
-In the Purchase app, add a new Menu based on the existing Model "Purchase Order Lines"
-In the list view of that new Menu, add the existing field "Analytic
-Distribution"
opw-3055926
closesodoo/odoo#109573
X-original-commit: d0621a2aec9cdc4bad348804fe5ada974b75f322
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce
==================
- Install mrp_product_expiry
- Go to Inventory > Products > Lots/Serial Numbers
- Add the column "Expiration date"
- Remove the groupby if any
- Select 2 records, set an expiration date
- Confirm
- Select the same records, remove the expiration date
-> TypeError: value.setZone is not a function
Cause of the issue
==================
When entering the readonly mode after changing the date, the function
`formattedValue` is called. But `this.props.value` is equal to `""`.
`formatDateTime` only handles `DateTime | false`
The field is rendered from this template https://github.com/odoo/odoo/blob/1d8f6359bbf55983a9582282d12a187c67cdf509/addons/web/static/src/views/list/list_renderer.xml#L233-L236
When `canUseFormatter` returns true, formatDateTime is called with
false, coming from `record.data[fieldName]`
opw-3111869
closesodoo/odoo#109436
X-original-commit: 5b26a080ae28fab2a78e92a838472578591eef17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in the form view, the date range picker field was
not updated correctly when switching pages.
How to reproduce:
- Go to a form view with a date range picker field
- Open the date range picker
- Close the date range picker
- Next page
- Open new date range picker
Before this commit:
The dates selected in the date range picker correspond to those on the
previous page.
After this commit:
The dates selected in the date range picker correspond to the current
page.
closesodoo/odoo#109423
X-original-commit: da5c4fb5a363158bcdef17f593ab8a556415a65d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Before this commit**
When a breadcrumb is restored, the props resId is overwritten by the
res_id of the action.
**After this commit**
The props resId is kept if it is defined.
closesodoo/odoo#108996
X-original-commit: 810a1d29bfa7c497627a37e0cec64df51b75bb4b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
Romain Estievenart