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>
This revision is related to odoo/enterprise#33088
The needs is the same:
While using Studio,
instead of removing the node from the view
when the user is not part of the group,
set the node as invisible.
This is so the xpath expressions computed by Studio
takes into account nodes which are removed from the view
when the user is not part of the group required by the node.
e.g.
```xml
<form>
<group>
<field name="name"/>
<field name="currency_id" groups="base.group_multi_currency"/>
<field name="foo"/>
</group>
</form>
```
With the above view, if you want to add a new field after
`<field name="foo"`/>
and the `currency_id` field node is removed from the view
during the post-processing of the view
because the user doesn't have the group,
Studio computed the xpath expression with `field[2]`,
and then the new field was mis-placed,
it was before the `foo` field instead of after.
The strategy is to let the nodes, as invisible,
for which the user doesn't have the groups
so the xpath expression is correctly computed
for the view as it is stored in the database/
before the post-processing step removing the nodes.
The above revision applies this strategy for
nodes other than `<field/>` and `<t/>`.
The `<field>` were not included because it was,
at that time, believed it wasn't necessary.
Even though the index was wrong as demonstrated
in the above example, it was then converted
with the expression `field[@name="foo"]`
instead of `field[2]`, and therefore it was
fine not to include the `field` nodes
in the strategy.
Also, fields were not included in the strategy
because for them, if the `groups` is set
in the Python model
e.g.
```py
currency_id = fields.Many2one(..., groups='base.group_multi_currency')
```
Attempting to read them while you don't have the group
will lead to an AccessError exception.
And there was no way to display the field as invisible in the view
without the web client to try to read its content.
Unfortunately, it isn't the case,
as demonstrated by the tours included in this revision,
field nodes must be included in the views, as invisible,
so Studio can compute correctly the xpath expression.
This revision therefore aims to apply the same strategy
for `field` nodes, make them invisible instead of removing
them from the view when the user is not part of the groups.
The revision takes care to override the web client so it doesn't
try to read the value of group-protected fields when the user
doesn't have the group.
So the field, with the label and everything,
is included in the view, but its content/value is left empty,
as the user cannot read the content.
Technically, there won't be many cases, because
users editing views using Studio are admins,
and in most-cases admins have access to these group-protected fields.
Having a field group-protected to which the admins do not belong
doesn't happen that often.
closesodoo/odoo#107877
X-original-commit: 91f213e202ca29c4ef0bb190663fc48f169a64a6
Related: odoo/enterprise#34940
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Co-authored-by: kebeclibre <lpe@odoo.com>
*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos,
l10n_sa_pos, pos_adyen, pos_discount, pos_epson_printer,
pos_epson_printer_restaurant, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_restaurant_adyen, pos_restaurant_stripe, pos_sale,
pos_sale_product_configurator, pos_six, pos_stripe
We are about to refactor most of the Javasript code base of the point of
sale and related modules. In doing so, we will move a lot of files and
modernize the entire code-base. In order to avoid diffcult rebases,
their conversion to odoo-modules is done as a first step to avoid
getting lots of conflicts on files that were unindented, which marks the
entire file as being in conflict. Conflicts will occur during forward
ports but they will be easier to manage as the changes will be much
smaller in scope, and the author will have the context of the change
that causes the conflict in mind when dealing with it.
closesodoo/odoo#107621
Related: odoo/enterprise#34910
Signed-off-by: Trinh Jacky (trj) <trj@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
closesodoo/odoo#107856
X-original-commit: 409fc809bafec2507342534bcdf4810ebffe9228
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In the QUnit type definitions, there is a QUnit namespace and a QUnit
interface. When using a jetbrains IDE, it is confused between the two
and thinks the global QUnit is the namespace.
This means that it can't resolve QUnit.test, QUnit.module, etc
This fixes this issue by disambiguating between the two.
X-original-commit: 26dc799f841e51a6d57d427e095b662a45bc7e5a
Part-of: odoo/odoo#107856
In this version of the tooling, the prettier files do not exist anymore.
We don't want to check if the files have changed, it will always be true
and trigger a reload of the tooling.
closesodoo/odoo#107825
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, it was possible to define a <widget/> in the arch of
an x2many in list mode. But this was not supported in normal list views.
So in order to unify the api, we decided to support in the list
view as well.
In a future commit, we plan to improve the widget api to receive only
the necessary props.
closesodoo/odoo#107811
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
The /web/login route is historically defined to be auth=none, which
means that it is available even when no database is selected (yet), and
no db_filter is set to automatically select one.
This is done mainly to be able to redirect users to the database
selection screen (cfr ensure_db()) instead of showing them a 404 until
they manually go to the /web/database/selector page.
The conversion of this mechanism in odoo/odoo#87571 can cause
problems because the user environment used to render the login page uses
the superuser ID. In certain configurations of installed modules, it was
possible to have the /web/login page showing "OdooBot" as the logged in
user, despite no user being actually logged in at all.
To fix this, we override the env that was set by auth=none:
- with the current session user, if there is one (like `/web` does)
- with the public user otherwise (as auth=public would do)
closesodoo/odoo#107613
X-original-commit: 6e42a07d7637070d45be81dcbf7261eda08425b4
Signed-off-by: Julien Castiaux <juc@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
## Steps to reproduce
* Using Firefox, Go to Accounting > Invoices > create a new invoice.
* Add a line to the invoice and remove the label.
You should see that there's no indication that the label field is
required. (It works well in Chrome)
## Cause
This is happening because the table borders (that become red when a
field fails validation) are not displayed in Firefox.
opw-3040299
closesodoo/odoo#107564
X-original-commit: 74726c649fa5bddec30573c18acd11020302d093
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Issue:
1. Install eCommerce + set up "Contact" header (there are probably other
configurations where this bug occurs but this one fails for sure).
2. Go to website in english version (with few menu items on header)
3. Switch language to Arabic
=> The "+" dropdown appears on the header even when there is enough
space for other menu items.
Explanation:
The 'AutoMoreMenu' option is used on website menu to auto adapt the
header layout so that elements are not wrapped on a new line (and sets
a "+" dropdown that contains the overflowing menu items).
When the language is switched to Arabic (or any RTL language), the
current code ('computeFloatOuterWidthWithMargins()' method) won't be
able to compute the reversed margins correctly for "unfoldable" items:
For example, if we want to compute the width (including margins) of the
"user dropdown":
============================================
IW -> Initial width value (without margins)
LR -> Left margin computing
RM -> Right margin computing
============================================
A- On English version (LTR):
1- LM: item has left auto margin class -> left margin won't be added.
2- RM: item has no right auto margin class -> right margin added (=== 0)
3- The final width is the same as the initial value (IW).
B- On Arabic version (RTL):
1- LM: item has left auto margin class -> left margin won't be added.
2- RM: item has no right auto margin class -> right margin added (> 0).
The right margin value added here is just the left auto margin
reversed because of direction. The code will return a final width > IW
and since the item is "unfoldable", its width will reduce the available
space for foldable items.
Solution:
The goal of this commit is to make the code smart enough to avoid adding
wrong right/left margin value caused by left/right auto margin class
on 'RTL' direction.
opw-2963123
closesodoo/odoo#107573
X-original-commit: 8a4a59389338ad1f50c08df3d55c267ca4d830da
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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 X2ManyField did not have a display name and its supported
types only mentioned one2many.
After this commit, those fields have a display name and the type many2many
is rightfully put has beng handled by the fields.
Part-of: odoo/odoo#107233
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>
Simple refactor in order to make changes to these line trigger the CI/Security
closesodoo/odoo#107032
X-original-commit: 3c215581aa1f8f74f2d9daf1e15f30ee750ec3df
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When converting the list view to owl, the caret indicator for groups in
list view was incorrectly given the extra class `fa-fw` which gives the
icon a fixed-width. This is incompatible with using padding as spacers,
and caused the caret to overlap the group name in nested groups.
This commit fixes that by removing the `fa-fw` class.
closesodoo/odoo#106994
X-original-commit: ff1055ddd07653d156a5887081f3ebe22dcbcae0
Signed-off-by: Samuel Degueldre <sad@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>
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.2
- fix: compiler: do not look up ComponentNode in the context
- fix: t-model takes precedence over t-on-input
- fix: reactivity: fix issues with reactive objects in proto chain
closesodoo/odoo#106898
X-original-commit: a86a8544883aaaf5d530320c84706dde35d17ef6
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Purpose:
Make the command palette easier to discover - indeed, unless you
know about CTRL+K, it's difficult to know you can use that elsewhere
than the home screen.
Solution:
Add CTRL+K next to the Shortcut menu in the user menu.
closesodoo/odoo#106820
Tackid: 3074492
X-original-commit: 536ea340ec1347a4a7598b5b51e2f2801521973f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
The input element properties `selectionStart` and `selectionEnd` method
applies only to inputs of types `text`, `search`, `URL`, `tel` and
`password`.
This specification is interpreted differently depending on the browser:
Accessing those properties in a `checkbox` input results in a crash in
Safari but not in Chrome/Firefox.
Current behaviour:
In a list view, in safari, press the arrowdown key -> it causes a crash
Expected behaviour:
Pressing the arrowdown key causes the next checkbox to be focused.
closesodoo/odoo#99050
Related: odoo/enterprise#34101
Signed-off-by: Bruno Boi (boi) <boi@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>
Aaron Bohy