This commit adds a new SelectMenu component. This component makes it
possible to search for options for a select element. It can be used to
replace the jquery select2 element for most cases.
Changes have been made to the Dropdown component as well as the position
hook, to allow the menu to be placed with the same width than the toggler,
using the 'fit' variant. Tests have been added to assert this position
feature.
Tests have been added to make sure the behavior of this component is
working as expected, and let the core element's usage being asserted.
Part-of: odoo/odoo#106265
Co-authored-by: luvi <luvi@odoo.com>
This commits adds another variant to the position hook. This one allows
a popper to be positionned next to a side, having the same dimension from
this side. A classname is then added to the popper, allowing the element
to be stylized depending of the side it's fitting.
Possible values:
(bottom/top)-fit would give the same width as the reference
(left/right)-fit would give the same height as the reference
Tests have been added to make sure those dimensions are correctly
applied when using thr fit variant.
Part-of: odoo/odoo#106265
This commit moves some parts of the code used by the progress bar of kanban
to its own component. It is now clearer to distinguished its code from the
renderer code (see crm_kanban_renderer). Also, it allows to re-use this
component in other views without making a direct use of 'kanban' elements.
The KanbanAnimatedNumber component has simply be renamed to AnimatedNumber,
as this naming suggested the element was only used as a Kanban element. This
more generic name now indicates that the element can be imported and used in
other places.
Part-of: odoo/odoo#107916
Co-authored-by: Florent Dardenne <dafl@odoo.com>
This commit adds the ability to quick create records from the
kanban view when it is grouped by a many2many field.
This feature improve the user experience for multiple views, here are
some examples of new possible workflows:
- Project -> My tasks (this view is grouped by m2m) -> quick create
- Project -> Select a project -> group by Assignees -> quick create
- Multiples module -> group by tags -> quick create
The "My Tasks" view is grouped by the m2m `personal_stage_type_ids`
field which is a complicated computed field on which we cannot write. A
custom behaviour in their `ProjectTaskRecord` was necessary in order to
support this feature. Previously, they also implemented a custom
behaviour for this field to be able to move records between groups.
closesodoo/odoo#108150
Task-id: 2960497
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this commit, the header of list views no longer scrolls with
the table, it remains visible on the top when scrolling.
Task 1917230
closesodoo/odoo#107631
Related: odoo/enterprise#35097
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, editing views from debug menu opened a dialog
and the user needed to refresh the page to see the changes.
Now, the edit view is opened in a new action so when the user goes back
in the breadcrumb, the view is updated.
task id: 3081332
closesodoo/odoo#108524
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, we added some handling so that errors that were not
defaultPrevented would have their traceback logged by the error service
instead of the default behaviour of the browser, because not all
browsers correctly log error chains (errors with causes). This did not
actually work because the errorEvent was written on the object at the
top of the error chain and checked on the error at the bottom of it.
This commit fixes that by just looking at the event on the uncaught
error.
closesodoo/odoo#108463
X-original-commit: cefba026ad7fe453da840a948e25d29d4d1837e9
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Previously, when restoring service metadata after clearing it, we would
use the patch function instead of an Object.assign. This is probably a
relic of a previous version of the code that used patchWithCleanup, but
in this context it is completely wrong, as we are giving something other
than a string as the patch name and no object at all as the patch value.
closesodoo/odoo#108390
X-original-commit: b83ab5061fe15e69f6c0703baf6f1eec61332f0e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In html, tags are case-insensitive. However, owl templates aren't,
as nodes starting with a capital letter are considered as component
nodes (not html). This means that people can use capital letters in
form or kanban archs for html nodes and it should work.
Before this commit, it didn't, because the compiler kept the case
when generating the owl templates. For instance, an arch like
`<form><Div/></form/>` produced the error 'Cannot find the
definition of component "Div"'. This commit fixes the issue.
Part-of: odoo/odoo#108221
Kanban and form archs aren't owl templates. Kanban archs define
a (historically) qweb template ("kanban-box") which is html + some
directives (e.g. t-esc, t-foreach...) and extra tags (field, widget).
Form view archs are html + some extra tags (e.g. group, notebook,
field, widget...).
With the conversion of those views to owl, a door was left open:
one *could* use owl directives (for instance, t-on-click) in archs.
However, we don't want people to do that, as it would tie the archs
in database with js implementation details, which will then limit
the evolution of the js framework.
This commit adds warning when such forbidden directives are detected.
In master, we'll raise errors.
Part-of: odoo/odoo#108221
This commit adds the possibility to define buttons that are always
present in the arch of a list view.
Purpose:
Several customisations of the list view consist in adding an always
present button in the control panel that performs an action/calls a
model's method.
We want to support this feature directly in the framework to remove
these customisations.
Solution:
Add a "display" option that lets you know when to display a button.
The different values that can be assigned to "display":
- "selection": the button is only displayed if at least one record is selected.
- "always": the button is always displayed.
The default value of "display" is "selection".
Exemple:
<tree>
<header>
<button name="to_do" type="object" string="Do" display="always"/>
</header>
</tree>
Taskid: 3082303
Part-of: odoo/odoo#106519
- Before this commit
Keyboard navigation in dropdowns lead to a traceback
- Explanation
The traceback happens in the bootstrap library.
When upgrading to bootstrap v5.1.3 (see c48f57e), a fix done in the
previous bootstrap version was lost (see 78f85f2).
This previous fix also added a test but it was not enough to
detect the issue when the bootstrap lib was upgraded.
- After this commit
This commit reintroduce the same previous fix and adapts the test,
hoping it would be enough for future changes to not break further
the expected behavior.
closesodoo/odoo#108080
X-original-commit: daca8fe4e3da4a5ad5fabf3730496a3919af8abc
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, there were two kind of related issues with the
AutoComplete component, involving an "Enter" keydown.
1) Click in an empty Autocomplete input s.t. the (only) source has
no option, then press "Enter" -> crash
2) Enter something in an Autocomplete input s.t. there are results
in the dropdown, then update the input again s.t. the (only)
source has no option, then press "Enter" -> crash
This commit fixes those two issues by
1) Ensuring that we don't store in the state an option index that's
out of range with respect to the current available options
2) Reseting the options when reloading the sources.
Those issues were reproducible on the Company form view, by using
the company name field (which uses partner_autocomplete).
closesodoo/odoo#107982
X-original-commit: 390a9b589495e67235b15137ccc510b76350443f
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
An act_url action in target "self" redirects the current window/tab
to the given url. It always reloads the page, except when only the
hash or query string changes.
This commit blocks the ui when the page reloads, because there's a
lack of feedback and interacting with the ui is unnecessary anyway.
For instance, module operations (install, remove and update) end
with page reload. During the operation, the ui is already blocked
because the operation takes time. After the operation and before
the page is actually reloaded, the ui is unblocked. As the reload
also takes time because of asset rebuilding, it makes false feeling
for the user that operation completes and interface is ready for
interaction. With this commit ui is blocked until the page is
reloaded.
closesodoo/odoo#107830
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
- On the settings view;
- Open the CRM settings;
- Click on "Update Probabilities" button;
- Change the "consider leads created as of the" date;
- Click on "Confirm" button;
Before this commit, the fields on the settings related to the dialog
were not updated. This occurs because, as the setting model is a
transient model, the settings view should always perform an onchange to
fetch the view, and it wasn't the case here.
Now, we patch the basic model used on the settings view to remove the
res_id, to consider the record always as new. This will always perform
an onchange to fetch the data. Note that, this hack is the same as it
was done before the owl migration.
opw-3073124
closesodoo/odoo#107879
X-original-commit: 792567c71aed626b5566f32b656104e3e70c496c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@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
Purpose:
When a list view with searchpanel is empty, the searchpanel is completely
empty and white, and it's unclear what it's for. Make it obvious by
displaying an empty state. This will typically happen in some views when
you have no data or don't have the groups needed to show filters.
Spec:
Display the following paragraphs with the bs classes "small" and "text-muted":
"No quick filter available."
"Update the filters in the search bar to display more records."
"Quick filters will become available if the records shown can be filtered."
closesodoo/odoo#107379
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a kanban view by default grouped by a date field, with a granularity
eg: "date:month".
Have no data so that the read group returns with only the groups for the range (fill temporal).
Those groups should have a count of zero, triggering the sample server to make up data.
Before this commit, there were multiple crashes basically because the groupby written
as field:granularity was not handled at least in the case were groups are returned by the server.
That is, from the sample server perspective, groups are reused and records are just made up
matching those groups.
There were two issues in fact:
- the groupBy with granularity (eg: date:month) was not properly handled, sometimes not splitting
the field name and the granularity, sometimes splitting those up where it should not.
- since the RelationalModel's groups are re-used verbatim by the sample server
(which still needs to return what the real web_read_group would), the "__range" data was missing,
since it had been transformed by the RelationalModel after the real call to web_read_group to the server.
After this commit, this use case is supported.
opw-3063067
closesodoo/odoo#107529
X-original-commit: 060b237f3caac5241130915b41a34aab7d28f4cb
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit adds a new Unselect all button displayed when at least two
records are selected in a list view. This button appears near other list
buttons. Once clicked, the selected items are deselected and the button
disappears.
Some list view tests have been modified since that change now adds a
button in cases where it was not expected before. Those tests now verify
the behavior when the button is clicked.
task-3081101
closesodoo/odoo#107294
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The keys from the action context were not available in the context of
a name_search done when a user expand a one2many field in the search
bar. We add them.
closesodoo/odoo#107660
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently the `not like` and `not ilike` operators are available for the Odoo domain in Python but not in JS.
This commit adds these two operators in the JS Odoo domain too for better code clarity. For instance:
`[('fiscal_country_codes', 'not like', 'AR')]`
instead of
`['|', ('fiscal_country_codes', 'like', 'AR')]`
Part-of: odoo/odoo#106221
Before this commit, the setting search was done exclusively in some
selected texts. These texts needed to be on some specific selectors
(field, label, span.o_form_label and div.text-muted).
Now, all text on a setting are searchable (including the text in
buttons). This commit also re-structure the setting compilers file to
remove the functions outside the class, this is done to standardize the
compilers (setting, form and view).
closesodoo/odoo#107226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
Steps to reproduce
==================
- Create an invoice
- Add a line
- Type storage in the product field
- Ctrl+A then press backspace
- Press escape to close the autocomplete dropdown
- Click elsewhere
-> The first suggestion is now selected
opw-3055185
closesodoo/odoo#107302
X-original-commit: e0613bc06ba9f2653dd0cfc4057ba93abf8513f7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@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>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@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
Pressing `<space>` in browsers results in a ` ` event key.
We don't want this event key as ` ` is not recognized and not
whitelisted in the hotkey service.
Instead we want to use `space` because it is more readable in the
codebase.
Part-of: odoo/odoo#99050
Previously, when calling error handlers, we would give them a new error
created by the error service, as well as an `originalError` which is the
error that was caught by the error service. In some cases, this error is
part of an error chain, eg: errors that happen in the owl lifecycle are
wrapped in an `OwlError`, so that when an error occurs in a callback
passed to a lifecycle hook, the position where the hook was called to
register the offending callback is part of the stack trace.
In practice, most error handlers only care about the error that caused
the entire error chain (the root) when deciding whether they should
handle the error or not, eg: an RPCError should be handled by the rpc
error handler, regardless of whether it occured in an event handler or
in a component's willStart. It already reads the traceback to display on
the UncaughtError provided by the error service as this traceback
contains the entire error chain stack information and is annotated with
source maps by the error service.
This commit makes it so that the `originalError` passed to handlers is
now the root of the error chain, it also sets the `cause` of the
UncaughtError which is passed to handlers as the error that was caught
by the error service, so that if a handler needs to inspect the error
chain to know whether it can handle the error or not, it can still do
that.
related to OPW-3069633
closesodoo/odoo#106720
X-original-commit: dd6f103b1635868e03a7aa40eb7186861d22d377
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Samuel Degueldre <sad@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>
**Before this commit**
When a popover is shown and then repositioned to a different placement
(i.e. due to window scrolling or resize), its arrow is misplaced.
This is due to the fact that classnames added in order to correctly place
its arrow are just added to the previous ones instead of replacing all
the needed classnames.
**After this commit**
The classnames are now properly replaced instead of just being appended.
closesodoo/odoo#106495
X-original-commit: c54cc2f87930147b5addb6f447574c677ef3504d
Signed-off-by: Luca Vitali <luvi@odoo.com>
When a one2many is used as a search default, its label has to be fetch
via a name_get in order to get a correct display of the facet
corresponding to that field in the search bar. It turns out that the
search model did not wait properly the return of the name_gets before to
start to compute the facets.
closesodoo/odoo#106624
X-original-commit: 50f58212410b321c1c4ad3d42a91cd1d23567308
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@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
