**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>
In PR 102662, we added a protection to manage the call to RPC in the new
form views when the component is destroyed.
This fix did not exactly reproduce the behavior of V15 and the new
relational model. The expected behavior of an RPC call when the component
is destroyed is a promise never solved. This commit will therefore
reintroduce this behavior.
In web, it is impossible to test this behavior because no rpc is
triggered when the view is destroyed.
closesodoo/odoo#106171
X-original-commit: 207f26ace6732c33d7169102f2a5a9695f5dda99
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the listArchParser did not offer ways to be extended.
Specifically, when extracting fields and widgets, there was no way to add information
from the outside.
After this commit, the functions that parse fields, widgets and button are methods
of the class hence offering extension points. Specifically, studio uses those to add information.
closesodoo/odoo#105970
X-original-commit: 4c1e0ba228f294c7bd5dd067431a1b660960d8b5
Related: odoo/enterprise#34074
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since odoo/odoo#99660
the `depends` field attribute is no longer passed
from the server to the web client.
Because of this, the "Set Defaults" feature
of the debug menu is completely unusable,
as the list of fields on which to set a default is empty because of it.
The use of this `depends` field attribute has been introduced in
revision odoo/odoo@ce9bbf6c10
In the commit description, we can read that setting a default
on computed fields having depends has been disabled
because the defaults set were being overwritten by the call to onchange.
Note that only the fact the field has depends is required,
the actual list of field names is not used, just the fact the list is
not empty.
However, since revision
odoo/odoo@488e334fc8,
available since Odoo 14.0,
this is no longer the case, the defaults are no longer being overwritten
by the call to `onchange`, since the `default_get` has been integrated
into the `onchange`.
A video attached to the pull request of this revision
shows the behavior difference.
Hence, setting a default on a computed fields having depends
(with an inverse method, hence not readonly)
can be allowed again in this "Set defaults" debug feature,
therefore avoiding to have to send back the `depends` field attributes
to the web client.
opw-3031290
opw-3038711
opw-3055292
X-original-commit: 48ac799288e76a0256b9ce0712a70ed5abc0f62e
Part-of: odoo/odoo#105251
Since the "always edit" task in form view, the underline (border-bottom)
only appears when input is `:focus` or `:hover`.
The problem occurs because the rule for `.o_field_invalid` doesn't match,
so the transparent color is applied and the red underline only appears
when we are hover or when the field has the focus.
This commit fixes the problem by setting the border transparent only
when the field is not invalid, not hover and not focus and not in a form
`.o_field_highlight`.
So now, we better see the invalid fields without hovering it.
Steps to reproduce:
* Open Project
* Select a project
* Select a task
* Create a new task
* Try to save manually the task => BUG a notification appears but the
"task title" (name field) is not underline
Task ID: 3069662
closesodoo/odoo#106123
X-original-commit: 1666ee5515996fab8a843b36b4fd93b776172f75
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Steps:
- Go to studio
- Open report editor in any report
- Use Text block
- Insert /checklist
Normal bullets without boxes are used in the report, because the checklist are styled separately in web_editor/static/lib/odoo-editor/src/checklist.css
opw-2995045
closesodoo/odoo#102072
X-original-commit: 9b4a1d3a45d294797813d653090b3a3c541210f5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
Steps to reproduce:
- go to Contacts app;
- add a reporting view (Graph, Pivot or Dashboard) (with studio for example)
- tape any character in the search bar;
- on "search related company for" field either use the arrow keys to go down to this and then click the right arrow key or click on the triangle to the left of this field.
Issue:
An error occurs.
Cause:
There is a mismatch between the parameters that are sent by the rpc call and those processed by the logic part.
Specifically, the domain must be part of the kwargs and not the args of the params key in the rpc call.
The problem occurs with a filter that looks like: `<field name="parent_id" domain="[('is_company', '=', True)]" operator="child_of"/>`
Solution:
Move domain in kwargs under key named args in the params of the rpc call.
opw-3031096
closesodoo/odoo#106074
X-original-commit: 8a9b418b27dcc9b904413f14cd0443f9a5b10d17
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Steps to reproduce:
- Activate debug mode
- Go to Sales and open a quotation (actually any form view from any
module will do)
- Start Studio
- Select the "Confirm" button (or any of the top buttons)
- Check the "Set approval rules" box
- Edit the domain by clicking the 'filter' icon next to the 'trash' icon
- Add a condition. You can just keep the default one.
- Click save to save the domain.
- Again, click on the 'filter' icon.
You should see that the domain in the text editor is malformed.
Furthermore, should you change the domain in the text editor (let's say,
change 1 to 2) and hit save, an error message will pop saying the domain
is not properly formatted.
opw-3001622
closesodoo/odoo#106043
X-original-commit: 9535026e00ca07453863d13d68935732cac49bfe
Signed-off-by: Mathieu Duckerts-Antoine <dam@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>
In grouped kanban, when having groups but no record to display, the
group creation button (ie. "+ Stage" in Project) and its related column
are muted instead of being the regular colors (like for the groups'
titles).
This commit fixes it by applying a fix similar to the group's title one
(cf. odoo/odoo@cbefc9cd51)
for the quick create column element.
Steps to reproduce:
- Open Project
- Create a new project and open it in kanban view
- create a few stages
=> the quick create column is "muted"
- dismiss the quick create column (ESC or click outside it)
=> the "+ Stage" button is muted
closesodoo/odoo#106022
X-original-commit: e95e2a23bc168815a27a9c64e4ff9394de468ada
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Bug
===
If we hover the property label, we should see the bottom border of the
property value (like for standard fields).
The bug still exist for the tags and many2many, because it's based on
the AutoComplete component, and the same bug exist for standard
many2many tags.
Task-3039733
closesodoo/odoo#105969
X-original-commit: 3ced33f434e84361448062b4795108df6186ffed
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds and fixes type annotations to give more accurate
autocompletion for javascript.
closesodoo/odoo#105670
Signed-off-by: Simon Genin (ges@odoo) <ges@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>
Remove the Dynamic Placeholder from the legacy Odoo field.
Introduce in 308f639e295fce07e4f34d6c76b35aab259e21ad
And migrate to be OWL compatible in #101768
Therefore the old code targeting legacy odoo field is unnecessary
and need to be cleaned.
task-3071417
closesodoo/odoo#105920
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Fields in views can be decorated with attributes decoration-xxx
(e.g. decoration-danger="state == 'error'"). This typically
results in a bootstrap contextual classname being applied on the
field's root node (e.g. text-danger). However, these classes have
no effect on children inputs and textareas. Since we wrap wowl
fields into a div (which thus receives the contextual class),
decorations were no longer visible in edition (which is, by the
way, the mode of almost all fields in form views now).
To fix this issue, we manually force the color of inputs and
textareas inside fields, to the color of their parent.
closesodoo/odoo#105781
X-original-commit: 4b2624ab3e398fe036832d9348bc319992b4fcd1
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Romeo Fragomeli <rfr@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>
QWeb views allowed to render QWeb templates rendered by the server in
a view.
Today, QWeb views are only used in website to see the hierarchy of
their views. The use case of website has now more sense in a client
action rather than an extension of a QWeb view.
This commit removes this view because it is not used anymore and will
probably not find any useful use case in the future.
closesodoo/odoo#103477
Related: odoo/upgrade#4016
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
### Steps to reproduce
* install Live Chat (`im_livechat`)
* Go to Live Chat > click any channel
* Under Widget, Click the copy button for the first link
If you're on firefox, nothing will happen (text won't be copied).
On chrome, you will get a traceback saying `Failed to execute 'write' on
'Clipboard'`.
### Expected behavior
The text should be copied to the clipboard, and a tooltip should appear
to confirm that.
opw-3058357
closesodoo/odoo#105756
X-original-commit: 977f5aacf46c3746380dda33585b407df659e07d
Signed-off-by: Luca Vitali <luvi@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>
This commit adds the isAvailable option to the command. If you set this
option, then it determines if the command should be displayed or not
in the command palette.
Why add this option?
We want to allow a component to define a command that will be displayed
according to the internal state of the component
Part-of: odoo/odoo#91821
**Issue:**
When moving a record in a kanban view from one column to another,
it is possible to keep holding the record, hover it in one column
for a moment, then move again to another column then eventually
drop the record. Doing this where a folded column is the intermediate
column results to visual issue, such that the darker highlight of
a folded column is lost.
The desired behavior is to keep the background color of a folded
column.
**Solution:**
When moving a record, the hovered column is highlighted, and right
after leaving the column, we remove the highlight. And we are doing
this without exempting the folded column, thus, its darker highlight
is lost during the record-moving-hovering process.
Instead of adding/removing .bg-100 during unhover/hover on each
kanban column to make sure of the "greenish" tint of the column when
hovered, we just make background of the .o_kanban_hover to be important.
closesodoo/odoo#105689
X-original-commit: fdd7f017c73718c9582256dde3124dd2655aeb01
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.
Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.
Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.
How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
the right values)
Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.
After this commit:
The ui will not block.
closesodoo/odoo#105286
X-original-commit: 1700416551725a70eca5597b6e106b43282c00d2
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.
Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.
Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.
How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
the right values)
Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.
After this commit:
The ui will not block.
closesodoo/odoo#105269
X-original-commit: 9917d841fa38ccc1e6d67875a665494dc22ef92f
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit fixes the styles applied to the popover in left/right
direction. Since start/end are used as the classname of the popover,
the element was no longer animated, as it is the case for top/bottom
directions.
For example, when adding data-tooltip-position to an element using the
data-tooltip attribute, the element appeared, but without an animation
for horizontal positions only. After the commit, animation is played
for any position.
The commit adapts the stylesheet of the component to adapt to the
renaming of left/right to start/end.
closesodoo/odoo#105144
X-original-commit: 14553007ec2d46cf1a70bf4e5b228d30c7a817b5
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
This commit restores the `display: inline-block` to the fields' textarea
to match the char field's input and allowing the textarea and the icon
to stand side-by-side. This rules went away in the
odoo/odoo@fb0bebc6cf commit, but should
have been restored in this case afterward.
Although, a tweak is required for the editable ListView as it triggers
a layout shift at the row's height level (ie. bigger when editing). This
is due to the textarea content's vertical alignment which, in its
default setting (ie. baseline) makes room for the descender portion of a
letter (eg. the part below the baseline, as "g", "j", "q", "p", "y"
letters) and, as result, makes the field vertically bigger.
Steps to reproduce:
- In Settings, add (at least) another language
- Open Project
- Open a project
- Edit a kanban stage
=> the description field's translation icon is below the textarea
closesodoo/odoo#105565
X-original-commit: 2168893749c2c361c3c79e8c3879d673e366c36b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In a grouped KanbanView, long group's title makes the group (aka.
column) grows instead of keeping its original size and truncate the
title using an ellipsis.
This commit fixes it by forcing a maximum width in addition of the
Flexbox rules (`flex-basis`, `flex-grow`) to prevent this effect.
Steps to reproduce:
- Open CRM
- In the KanbanView, create a new Stage with a very long title
=> the column grows instead of keeping its original width
closesodoo/odoo#105554
X-original-commit: d9872ecce78d6d7ad02cdaa16782aa473e5a7655
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In grouped KanbanView, group's width follows three usecases:
- on smaller screens, the group (aka. column) takes 90% of the viewport
(to give a hint of the next/previous column)
- on desktop-like screens, the group's width is based on the regular record's
width and padding
- on desktop-like screens, a smaller variant of the one above (cf.
`o_kanban_small_column`)
As the definition of those usecases where a bit
all-over-the-place, this commit takes advantage of the CSS custom
properties and the cascade to conditionally define the
`--KanbanGroup-width` property and set only once the group's width (cf.
`flex-basis`).
Note: it fixes a small issue where the "quick create" column was always
set to the smaller variant, even with regular record size.
X-original-commit: d7aa7dc892c9aa7120291e6eedad7f03bf78baf2
Part-of: odoo/odoo#105554
This is a port of https://github.com/odoo/enterprise/pull/30046 for wowl
Steps to reproduce:
On a mobile device:
- Go to Inventory > Product Variants
- Switch to the list view
- Long press on a record
-> We can't scroll to select records below the current screen
closesodoo/odoo#105545
X-original-commit: cd874593b2390efba8e92228f85e9cf07c0e1a8c
Related: odoo/enterprise#33861
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
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>
... when re-opening the dropdown.
Before this commit, in an autocomplete component with an async
source, when:
- clicking on the input to open the dropdown,
- then typing something to filter the results
- then selecting one of them (which closes the dropdown)
- and finally re-opening the dropdown:
the previously displayed (and filtered) results were briefly
displayed, while the source was being fetched again. It thus
produced a weird and annoying flickering.
This commit fixes the issue by reseting the source before fetching
it.
closesodoo/odoo#105539
X-original-commit: 83769b00837f4eea29586f53709d65d3078ddce3
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the drag & drop feature for the Project "Tasks"
kanban view did not work if the drag sequence was initiated from the
title of the card.
This was due to the "o_kanban_record_headings" class having the CSS rule
`overflow: hidden`, because of a well known 6 year-long-and-counting
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1352061
Namely: mouse enter|leave events won't fire on anything underneath
elements having `overflow: hidden`.
This commit solves this issue by introducing a dedicated class name
'o_dragged' to all elements dragged using the `draggable_hook_builder`,
and defining on it the CSS attributes that were assigned in JS before,
as well as `pointer-events: none` on itself and all its children to
avoid the issue mentioned above.
Also in this commit: fixed a syntax error in a CSS rule in project's
"task_name_with_subtask_count_char_field" widget.
closesodoo/odoo#105353
Related: odoo/enterprise#33774
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>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Before in a legacy client action, using a link to change view and
going back to the client action with breadcrumb does not restore the
scroll position.
Now with this commit, the scroll position is restored when going back to``
the client action.
Steps to reproduce:
- Install Accounting
- Go to `Accounting -> Reporting -> Balance Sheet`
- Unfold the tree to make the window scrollable
- Click on a link at the bottom of the window
- Go back to Balance Sheet
closesodoo/odoo#105443
X-original-commit: 225e809aa3ce1c506be69287e8084adf877547d7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Issue:** When creating a custom filter for a selection field,
the selected value is not properly displayed. Note however that
applying the filter still works. The problem is only in the displayed
value.
This is caused by setting the "value" attribute of the selection
element which is always an empty string (because formatField doesn't
properly work for selection field). However, the empty string is not
the issue because it doesn't matter what "formatted value" is returned,
it is not needed. The selection field's value is based on the value
of the selected option.
**Solution:** To properly show the display text of the selection item,
we need to make sure that value of the selection field is not overridden
during its onChange event. As a result, the selected option will become
the value of the selection field, displaying the proper text.
Therefore, in the onValueChange event handler, if the field type is
selection, we don't reset the value of the the selection element.
closesodoo/odoo#105420
X-original-commit: afadac5e21e6af2111ef42852243e78bb085d7c3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The rpc service has a protection (when used via useService) that
prevents the returned promise from being resolved/rejected if the
component has been destroyed meanwhile.
However, as the FormView still uses the legacy BasicModel, all rpcs
done by its model do not go through our new rpc service. As a
consequence, before this commit, they did not benefit from the
protection. This caused a non deterministic issue in the main flow
tour.
This commit implements a similar protection as the rpc service, but
specialized for the BasicRelationalModel, which redirects all RPCs
done by the BasicModel.
This change highlighted two scenarios where we sometimes performed
RPCs (or could perform RPCs) on a destroyed component. This commit
fixes those as well.
X-original-commit: f613e916d5e8b465fc360e340094c09037450ff1
Part-of: odoo/odoo#105332
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>
Before this commit, the labels tags that were after the fields losses
their attributes (i.e. classes) after the compilation of the form view
arch.
Now, the attributes are correctly copied after the compilation.
similar to : 873790f802
X-original-commit: 395bdf8880c5929652838a93351596b045708905
Part-of: odoo/odoo#105315
Co-authored-by: Patrick Hoste <pko@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>
Steps to reproduce:
1-set language to an LTR language (arabic / hebrew...)
2-select any field with the date-time range widget (eg: planning>add)
3-the hour and the minute selection is reversed.
Bug:
the hours and minutes order depends on the language orientation where
they should always follow this format HH:MM
Fix:
force the time to be displayed Left To Right regardless of language
opw-2953221
closesodoo/odoo#105255
X-original-commit: 8d396fd8800baf29a9242987b610e3bb7b9da265
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, since there is a mildly transparent filter over the
entire view when the "no content" helper is displayed, the interactive
elements of the empty kanban view (namely: the title with the name and
"quick create" button) were slightly hidden.
This commit enforces a superior z-index on those elements s.t. they can
appear on top of the helper's filter.
closesodoo/odoo#105140
X-original-commit: cbefc9cd51b3c903a6c54d8e3f95bf2b592cf402
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, some scss selectors where duplicated
(`.select2-results`) and where not targeting the right element.
This commit also changes the css variables name based on the right
structure : --component__childItem-property--state
task-2710677
closesodoo/odoo#105118
X-original-commit: 25a7ca929b4342fe7b2941f941a001e0dd0370e9
Related: odoo/enterprise#33689
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Joseph Caburnay