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>
Before this fix, the '.o_form_status_indicator' was in the right
part of the control panel.
But on desktop, we want it next to the last breadcrumb item
to cognitively attach the "save status" to the record name.
closesodoo/odoo#107397
Task-id: 3067691
X-original-commit: 24b098767b03c97ffe108a7f8aa0f77c08aecef5
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@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>
**Issue:**
On the first group level, the caret that prefixes the label is
separated from the label by 5px.
But, on the 2nd group level (and deeper levels), the caret and
the label have no space in between. This is not visually pleasing.
**Solution:**
The span containing the caret has a fixed-width which conflicts with
the specified padding to show hierarchy of the groups.
We avoid this conflict by specifying margin to indent nested groups
instead of padding. This indentation (start) margin is calculated in
css to be able to reuse the values from `$spacers`. It is based on the
dynamically assigned css var "--o-list-group-level" that is calculated
based on the group level.
We also specified the end margin using a utility class (.me-1). This
is the space that separates the caret to the group's label.
closesodoo/odoo#107333
X-original-commit: 1d8f6359bbf55983a9582282d12a187c67cdf509
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@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>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
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>
Before, in the list view, the user could not select a record range easily. He had to
check/uncheck manually each checkbox in the range.
Now, the user can select a range of records in list view by hitting its first record
and and its last record while holding SHIFT for the second.
It's also possible to do it with the keyboard:
- pressing <SPACE> to select a record and <SHIFT+SPACE> to select a range of records.
- pressing <SHIFT+ARROW> to extend to current checkbox
task-2039894
Part-of: odoo/odoo#99050
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>
Purpose
=======
Prevents auto save of not dirty forms with
text fields on page reload and tab/browser closing.
Specifications
==============
The text field default value is making Odoo consider
the form as dirty even when it's not which triggers
auto saving for not dirty forms.
Change the text field widget setDirty condition to
prevent considering empty textarea string dirty.
Typically, if the previous value was false, false and
empty string should be considered as the same value.
Task-3031570
closesodoo/odoo#106619
X-original-commit: 787ef58dd3f91f829509f738ee40c8764c403757
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use case:
in the reconciliation widget, we need to know when the pager
is updated before the next render because we need to select the
appropriate id to use.
cf the following PR: https://github.com/odoo/enterprise/pull/33631
opw-3031131
closesodoo/odoo#106581
X-original-commit: 19523b511d54278613a3d3e7389a51665dcc3fc1
Related: odoo/enterprise#34408
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@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>
Scrolling inside a grouped kanban with a lot of cards on a column
makes the text header appear over the kanban card due to the missing
background.
Steps to reproduce :
- Open Helpdesk on small screen like a mobile
- Open VIP Support
- Made a Group by "Create date => day" (there should be enough cards on
a column to scroll)
- Scrolling the column => bug, the text header appears over the kanban
card
closesodoo/odoo#106368
X-original-commit: 041fddf0c884ae9a6e2b040decfb1f31e9d25a29
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
**Issue:**
When at the first page of the list, and the user deleted all/or some
of the records, the next page is not automatically displayed.
**Solution:**
This is because the first page (offset=0) is exempted from offset
adjustment (_adjustOffset) which is responsible in reloading the
records in the list.
In this commit, we propose to reload the list if the call to
`_adjustOffset` didn't call `load` and there are actually deleted
records.
closesodoo/odoo#106317
X-original-commit: 2863978041d2856644da938ced9eedc640b8f198
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:**
- Open a list view and group the records. Notice the count per group.
- BUG: When deleting a record under a group, the count in the group
is not updated.
**Solution:**
When calling `deleteRecords` in the `DynamicGroupList`, we call
`deleteRecords` on each group's `list`. This "list" can be
`DynamicGroupList` or `DynamicRecordsList`. Regardless which instance
calls the `deleteRecords` method, we should take the number of the
deleted records and subtract it from the group's current count.
If it turned out that the calling object is a `DynamicGroupList`,
we should make sure that it returns the ids of the deleted records
so that the parent group can update its count as well, that's why
we are collecting the deleted record ids.
It's not so easy to follow but we can roughly imagine the structure
this way:
DynamicGroupList
-> DynamicGroupList[]
-> DynamicRecordsList[]
Deleting items from the inner dynamic records list should result to
update of the parent group list, and eventually, to the update of the
root group list.
X-original-commit: 865c1b37f7986f00b85c9e8135e46cc4b2ac70da
Part-of: odoo/odoo#106317
**Before this commit**
Various issues are present in the calendar filter autocomplete:
- typing a character in the input would close the autocomplete dropdown
- search for a term yielding to no results would not display the
"No records" entry
- click on the "Search more..." entry yields to a validation error
message: "a mandatory field is not set". [1]
**After this commit**
The FilterAutoComplete component has been removed as it was useless.
It was a kind of higher order component trying to manage the
AutoComplete component's input state, leading to unwanted complexity.
We decided to remove this component despite being in a stable branch
for the following reasons:
- it was not exported and only used by the CalendarFilterPanel
- it brought unnecessary complexity
- it was not working properly
- the branch is still a bit young
- the diff in the CalendarFilterPanel template is minimal
Now that the CalendarFilterPanel directly make use of the
AutoComplete component, the first listed issue has been solved.
The two other issues were simple fixes addressed in the mean time.
[1] this issue comes from opw-3031045, more infos below:
Steps to reproduce:
- Go to calendar basic view
- Click on "+ Add attendees" and then on "Search more ..."
Current behavior:
Validation error on partner_id in calendar_filter create
Expected behavior:
You can look for a partner with advanced research options
Explanation:
The code treated the "Search more ..." option like a partner
option instead off calling the onSearchMore method that creates
the advanced research dialogue.
opw-3031045
closesodoo/odoo#106292
X-original-commit: 73af1d04d9d49eace16e3f88c32ce5d457b44b83
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Martin Fockedey <mafo@odoo.com>
Co-authored-by: Hubert Van de Walle <huvw@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@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>
**Issue:**
- Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`.
- BUG: The pager shows that it's displaying the limited records, but in reality,
it's displaying all records under each group.
**Solution:**
This is because we are *not* limiting the number of records being fetch in the first
read_group rpc. We are now specifying the expand_limit in this commit.
closesodoo/odoo#106238
X-original-commit: e5bba9f5eb63ee95924c892801fe18feaef6d1fc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
Current behaviour:
When rendering a calendar view with "Year" option,
the weekday headers may be incorrect in some cases
when the timezone is set to a negative timezone GMT.
For ex. it renders "S S M T W T F" instead of "S M T W T F S",
if the first day of the week is Sunday.
Expected behaviour:
Formatting should be consistent with the first day of the week,
and be indepedent of the timezone.
Steps to reproduce:
- Change your system timezone to somewhere in Alaska
- Install TimeOff
- Open TimeOff and switch to the yearly view.
- Observe that the weekdays headers are incorrect.
Reason for the problem:
The custom calendar header formatter was trying to generate
the end result directly based on the date marker, which is
incorrectly set in that context. This patch doesn't fix the root
cause of why the `info.date.marker` starts at an incorrect date.
Fix:
A formatter shouldn't read state. Since we are using the luxon plugin,
we use the `"EEEEE"` format, which is equivalent to the `"narrow"` options
from JS's `Intl.DateTimeFormat()` available in all browsers.
Affected versions:
- 16.0
- master
opw-3033464
closesodoo/odoo#106041
X-original-commit: e212f8752047222d1d81e1e9589934e70ecacf2a
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
*: im_livechat, website_livechat, website_slides
In c989ff3, the odoo module system has been changed so that it now
errors out when modules are defined but have missing dependencies and
cannot run. Unfortunately, tours are defined in a single bundle,
`assets_tests`, and this bundle is used everywhere tours need to run,
but some of these tours depend on modules that only exist in the backend
and others on modules that only exist in the frontend. We don't want to
break up the `assets_tests` bundle as this creates a poor developer
experience, and so the solution that was chosen at the time is that when
the `assets_tests` bundle is defined, we ignore all module dependency
errors.
This causes a problem however, which is that if a module dependency is
missing in production code, the page will be broken by the module error
(which is expected) but if the `assets_tests` are present, which is the
case when running tours and tests, then it won't, meaning the tours will
happily pass despite the application being broken, which is
unacceptable.
This commit fixes this issue by replacing the assets_test bundle by a
new bundle (`__assets_tests_call__`) within which all module dependency
errors are ignored, which lets dependency errors that are hapenning in
other bundles (ie in production code) happen even during the tests.
Because of this, this commit also fixes the dependency errors that
already existed but were previously silent:
- for im_livechat and website_livechat, the code was refactored to use
the standard mechanism that we use elsewhere to add data directly in the
page: we store the data in __session_info__, and the module that exposes
that data is always present, instead of having a module that's defined
conditionally, which causes issues when non-conditional modules depend
on it.
- in web, the `report_assets_common` bundle was used alongside
`assets_common` but without `assets_frontend` or `assets_backend`.
Reports do not need any js and it appears that it already had what it
needed as far as css is concerned except for one fontawesome override.
Code was changed so that the js from the bundle is not included and it
reports no longer use `assets_common`, the js part of the bundle is no
longer used.
- in website_slides, the `slide_embed_assets` bundle is used alongside
`assets_common` without using `assets_frontend` or `assets_backend`
which is required for `assets_common` to function, the approach here was
to simply take the files from `assets_common` and remove the files that
were causing issues. This bundle should be trimmed at some point, as it
contains way too many things that it does not need.
The file colors.js was also moved to core, as it isn't graph specific
and was causing dependency issues with a field that was importing it.
Fields shouldn't depend on files in specific views' directory.
closesodoo/odoo#104794
Related: odoo/enterprise#33909
Signed-off-by: Aaron Bohy (aab) <aab@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>
The purpose of this commit is to add extension points that allow code
to be executed before and after the save of a record.
CallBack:
onWillSaveRecord is a callBack that will be executed before the
record save if the record is valid if the record is valid.
If it returns false, it will prevent the save.
onRecordSaved is a callBack that will be executed after the save
if it was done. It will therefore not be executed if the record
is invalid or if a server error is thrown.
This commit will replace all the save overrides by the onWillSaveRecord
and onRecordSaved callBack.
Observed problem:
We could notice that each of the overrides of save in order to execute
for example a doAction after this one did not take into account the fact
that the save did not succeed.
For example, a required field is invalid and we try to save, then the
doAction will be executed without the "write" of the save.
The callBack onRecordSaved will prevent this common error.
closesodoo/odoo#105180
Related: odoo/enterprise#33710
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The code does not actually depend on mail features and it is intended to be used
in the base form view of user.
closesodoo/odoo#105415
Signed-off-by: Alexandre Kühn (aku) <aku@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>
Before this commit, the modified test sometimes failed on runbot.
We need to wait for an extra tick, because the dialog might be
rendered in another animation frame that the crashing client
action.
X-original-commit: fb73b9f08fbb315544b3a4fce727a4bf2fbaa1bc
Part-of: odoo/odoo#105693
Before, the `Layout` component was not friendly enough for
client action. There was no default component for `ControlPanel`
and `SearchPanel` in `Layout`, resulting in the fact that it had to be
defined manually in the client action environment:
```js
useSubEnv({
config: {
...getDefaultConfig(),
...this.env.config,
},
});
}
```
Now, the `Layout` component defines default component for `ControlPanel`
and `SearchPanel`. Making it easier to use for generic usage.
closesodoo/odoo#105413
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a grouped list view, it was possible to have
empty groups when changing pages.
Why:
Before this commit, if a grouped list performs a load, then it is
checked if its previousParams are equal to the current one. If so, we
keep all the old groups empty. This requirement is related to the kanban
view, so we will move it to the kanban model.
The kanban view needs it when we archive data but don't want to delete
groups (colomns). So we perform a load but we don't want to delete the
empty columns.
How to reproduce:
- Go to a grouped list view
- Click on a record
- Return to the list view using the breadcrumb
- Go to the next page
Before this commit:
The groups on the first page are always present with those on the second
page. The groups on the first page are empty.
After this commit:
We only have the groups on the first page.
closesodoo/odoo#105488
X-original-commit: 04467197b9ec0851e3f9f7a74d1b97c5e27420bc
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, we had an issue with the width calculated
for data cell (see. sizeOfDataCell).
In some case, the width was 50% instead of taking 100% of the
available space.
This was because some elements of the inner groups that should not
have been visible were computed as if they were, taking an effective
slot in an innergroup's row.
E.g. with two labels:
Before:
"invisible label" and "label" on the same line with `style="width: infinite"`
"data field" on a second line with `style="width: 50%"`
After this commit:
"label" and "data field" on the same line with `style="width: 100%"`
Note that as `infinite` is not a valid value, this wasn't interpreted and
style attribute was empty.
Thanks to grid for still aligning elements even if they are technically
in different rows. It's why we only saw this issue because of the
width of the data cell.
Steps to reproduce:
- Go to Accounting
- Customer -> Invoice
- Create a new invoice
-> See Customer field
Thx to @kebeclibre
closesodoo/odoo#105489
X-original-commit: e177c63e3618e4b9e492a27d1301c098a0066cb6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@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>
Before this commit, when compiling a form group, the scope class is
added to the elements of the outer group. It was added on the element
class attribute. The issue is that FormLabel don't have a class
attribute but a className attribute. So the class wasn't shown on the
DOM.
Now, the class is added on the FormLabel className attribute and shown
in the DOM.
closesodoo/odoo#105315
X-original-commit: 214beb39d7c1a315255f0a5a842e60f73e7900cc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@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>
**Issue:** The aggregate row of the list renderer doesn't take into
account the fields with zero values. As a result, average values are
not correctly computed. E.g. average of [2, 0] => 2 instead of 1.
**Solution:** Make sure 0s are included in the valid values to
aggregate.
**Change note:** We took the opportunity to make a simple refactor
in the affected test. Instead of asserting contents of the row
with multiple strictEquals (one per cell), we use deepEqual to
check the cells in the aggregate row.
closesodoo/odoo#104968
X-original-commit: 2dcb71aab911a47d8d3a5db6f68a28d1c6d8c9fb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
Custom grouping by m2m field is introduced here: https://github.com/odoo/odoo/pull/74985.
However, after refactoring in https://github.com/odoo/odoo/pull/73311,
users are unable to add custom groups based on stored m2m fields.
This is because the stored m2m fields are not included in the list of
"Add Custom Group" options.
In this commit, we are now again including the stored m2m in the options
for "Add Custom Group".
closesodoo/odoo#104873
Task-id: 3046183
X-original-commit: 5087d9011be7f46a4a3e05b1e951f2556f254b4c
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@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>
**Issue:**
When a group contains more than 10k items, its pager only shows
10k as limit, even if the group already knows it's total count.
**Solution:**
We now allow creation of `DynamicRecordList` with 'countLimit' as
one of the params. It will be used in the instantiation of the
class but will default to WEB_SEARCH_READ_COUNT_LIMIT if not
provided. This way, pager's limit will be properly set to the
group's count.
closesodoo/odoo#104698
X-original-commit: 4751f85ac9d430528106de05bcdc484ae0c7079b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@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, in the list view, clicking on the "export all"
button created an xslx file that did not reproduce the order of the
columns in the view.
Why is this?
The order used was based on the data fetched by a
rpc("/web/export/get_fields".
Solution:
Do not do a rpc("/web/export/get_fields") and use the order of the
columns in archInfo.
How to reproduce:
- Go to a list view
- Click on the "export all" button
Before this commit:
The order of the columns in the created file may be different from the
order in the list view.
After this commit:
The order of the columns in the created file is the same as in the
list view.
closesodoo/odoo#104541
X-original-commit: 734eee368d548fddc6c516ff559d09e853d1ab74
Signed-off-by: Luca Vitali <luvi@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>
"div" as a child of "tr" is not really allowed. Because of this,
custom widgets in a list_renderer are not properly styled resulting
to issue where a widget doesn't take the full height of the
parent "tr" element.
This was missed during initial wowl porting so in this commit,
we are putting the widget inside a "td" element.
closesodoo/odoo#104475
X-original-commit: 092b6b66d998795a03de82be4d33990a138396e1
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Aaron Bohy