Only kanban, tree and form implements onchanges.
Therefore, on calendar, graph, pivot, ..., putting `on_change="1"`
is useless and is a waste of resources and KB.
e.g. CRM lead pivot view
Before:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" modifiers="{"invisible": true}"/>
</pivot>
```
I would have like something smarter, like using the `editable` concept
for instance, but it's not that easy.
e.g. kanban is not considered as editable, while it does support
onchanges when grouping record by a field and drag and dropping
record from one column to another.
However, if we change the kanban view to make it editable,
the view validation will start validating the fields domain:
https://github.com/odoo/odoo/blob/45d4ac14f65c53dcde56592715d50169bde116ad/odoo/addons/base/models/ir_ui_view.py#L1439-L1442
causing issues:
- If a field used in the domain is not in the view, it will need to be
added in the view,
- while it will not be used, as you cannot do a search in related fields
in kanban views anyway.
e.g.
```
odoo.tools.convert.ParseError: while parsing /data/build/odoo/addons/analytic/views/analytic_line_views.xml:120
Error while validating view near:
<kanban class="o_kanban_mobile" __validate__="1">
<field name="date"/>
<field name="name"/>
Field 'company_id' used in domain of field 'account_id' ([('company_id', 'in', [company_id, False])]) must be present in view but is missing.
```
In addition, the kanban doesn't need the readonly and required
attributes on the field nodes, as other editable views (tree and forms)
do.
In addition, the tree list is currently considered as "editable" only
when it has `editable="bottom" or `editable="top"`, while
a tree without this editable attribute can still trigger onchange,
for instance when using `widget="handle"` or `widget="boolean_toggle"`.
We should therefore making the tree list editable whatever the case,
leading to the same issues than listed for the kanban above,
or make an exception for field in non-editable tree views using a
widget..
So, as the smarter way seems difficult and risky, for a limited gain
I choose the easy way by separating the concept "editable" and
"onchange-able" and to not set `on_change="1"` on views not considered
as "onchange-able".
closesodoo/odoo#102788
X-original-commit: aeb65ee536b1611c1cb829c91906f327f8e331c7
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since BS5, the <html> receive the 'smooth' CSS value for the
'scroll-behavior' property. As the name indicates, it makes scrolling
smooth (on click on anchor link for example) instead of an instant
jump (although the exact behavior is left to the browser).
The problem is that this auto-smooth from the browser conflicts with
the "smooth drag and drop" code (at least if the scrolling target is
actually the `<html>` element which is never the case currently). Indeed
this code expects to make small instant jump depending on the position
of the user cursor. This commit solves the problem by disabling the
browser auto smooth for the duration of the drag and drop.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
Note: this bug fix could be back-ported, should the need arise (custo
might want to use the 'smooth' 'scroll-behavior' in stable without BS5).
Although the only side effect is slower smooth drag and drop.
X-original-commit: 81ed9bee81bacca7b55598e9af7cac51cd7805cf
Part-of: odoo/odoo#102785
The smooth drag and drop in edit mode (over the website iframe)
currently works correctly. This would not be the case if the scroll was
not on the `#wrapwrap` but left to the `<html>` element. Indeed, special
code handles that case, but that code is actually not needed in case
what is being dragged is outside an iframe and that the smooth
scrolling is performed inside that iframe.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
X-original-commit: 4947ef118c646171fd3358135dcab8f63efa04d2
Part-of: odoo/odoo#102785
The `scrollTo` method and related utils (jQuery animate, ...) were not
properly adapted to work in the context of multiple documents. E.g. the
website editor code (outside the website iframe) is calling the
`scrollTo` util to scroll to added snippet elements (inside the website
iframe). In that case, the util was performing some searches in the DOM
outside of the website iframe while it was meant to be done inside. The
result was that the scroll was not considering the website fixed navbar
and scrolled "too far".
Another bug is visible only when the scrollbar is left to be the natural
browser one (not on the `#wrapwrap`). In that case, the `scrollTo` util
simply had no effect anymore as the `animate` override of jQuery was not
adapted.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
X-original-commit: ab417de98068afaaa12995726c7c6445f075ca4f
Part-of: odoo/odoo#102785
Inline fields for numeric and date values shouldn't be as wide,
since they tend to be 'close by' another field (e.g. currency,
periodicity, etc.) in the same 'row' or included in a text zone - in
which case we want the value to be closer to its context, and not
completely isolated in a huge area.
closesodoo/odoo#102775
X-original-commit: 5f5729f8ba79c7919774021310208d41cb8ddb56
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Have a form view in a dialog (action in target=new)
The create/write of that model throws an error.
Before this commit, the "Oh snap!" dialog was displayed, but makes little sense
in a dialog.
After this commit, the old UserError dialog is displayed.
closesodoo/odoo#102764
X-original-commit: d36f1708219f63fae5a86b6c1e81b328ca96b347
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a list view, if you clicked the discard button
for an invalid row, it would not be discarded and the discard button
would disappear.
Why did this happen?
Invalid fields in the record were not deleted.
How to reproduce?
- Go to a list view with a required char field
- Edit the char field of a record with an empty string
- Click outside the record (it becomes invalid)
- Click on the discard button
Before this commit:
The record is not discarded (its values do not change and it remains
in edit mode) and the discard button disappears
After this commit:
The record is correctly discarded and the discard button disappears
closesodoo/odoo#102763
X-original-commit: 73ba2217ec56819ff979020a43d0c13f8ff0b697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In house implementation of automatic scoll when dragging an element to
the edges of its container.
closesodoo/odoo#102756
X-original-commit: 290a6213a6e36fc2e5d11216b59a6aaf79554196
Related: odoo/enterprise#32568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Co-authored-by: Julien Mougenot (jum) <jum@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Reproduce:
Go on a kanban view, with enough columns so it goes off the screens.
Scroll on the right, try to drag anything beyond the original (before
scrolling) limit of the screen. The cards are stuck floating at that
limit. Note it didn't prevent the drop to work properly where the mouse
was.
Issue:
The useSortable hook gets an owl ref, which is used as a limit to where
things can be dragged and dropped. Originaly and logically, it was the
current component ref, the renderer. But for some unknown reason, this
space was not getting wider than the initial screen size. It may be a
problem with the flexbox layout.
Tried solutions:
- A first solution was to add the overflow-x-scroll css property to the
renderer. It works, but now the horizontal scroll bar is no longer
always visible. You have to scroll all the way down to see it. UX wise
this is not acceptable.
- We could remove the clamp mecanism inside useSortable to let the drag
and drop motion go anywhere. This works, but decrease the quality of the
interaction. It looks cheap and not polished.
Final Solution
Finally, we decided to pass a ref to the o_content div from the layout
component down to the kanban renderer. If the useSortable is given this
ref, it works as intended. While it may seem too much, it is not
unreasonable to propose a reference to the most parent element of the
view contents to the renderer.
X-original-commit: a569305acaa1c812ede739c267e2e9530945f65f
Part-of: odoo/odoo#102756
This commit fixes the number of cells created in the ListView's footer
when the optional field's button is present.
Steps to reproduce:
- Open Accounting > Customer Invoices
- Switch to ListView
=> the footer (containing totals) has one less cell
closesodoo/odoo#102222
Forward-port-of: odoo/odoo#101954
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit fixes the pager's position in a grouped ListView when the
optional field's button is present.
Steps to reproduce:
- Open Account > Intrastat Code list
- Unfold "Commodity" group
=> The group's pager is misplaced
Forward-port-of: odoo/odoo#101954
Part-of: odoo/odoo#102222
Add missing exclusion `o_list_record_remove` class used to allow text
overflow mixin.
Steps to reproduce:
- Open the Employee app
- Plan creation
- The trash as an overflow ellipsis => bug
closesodoo/odoo#102758
X-original-commit: a2ee880237724463b90fc43df69b689b82756fe4
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Allow `o_state_selection_cell` to have the overflow mixin to allow the
resize of the kanban state column on list view without text overlapping.
This commit follows https://github.com/odoo/odoo/commit/e22abffdc230c2ae494a85fdf7fd8d6b488be3ea
Steps to reproduce:
- Open the helpdesk app
- Click on VIP Support tickets
- Go to the list view
- Check the kanban state column and try to reduce it's size
=> The text is overlap
X-original-commit: a9f83d6d2e9f53a6a562044303c5bcb5ab5f1a9c
Part-of: odoo/odoo#102758
Have an InnerGroup which has a first div visible all the time
and a second div conditionally invisible.
Before this commit, when the second div was invisible, the first was not
displayed.
After this commit, the two divs are displayed correctly.
X-original-commit: c69836e3c53e1efb61f66612c266a31aa9b54816
Part-of: odoo/odoo#102578
This commit fixes the properties field alignment to make it more similar
to the form's group layout (using grid and its gap).
Steps to reproduce:
- Open CRM
- On a lead's form view
- Add properties
=> labels from second column aren't aligned with fields above
closesodoo/odoo#102730
X-original-commit: 5a1c14fe5761e964a2370883bf209b474e498918
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, editing a domain field with an invalid value
for the field type will display a parsing error.
The purpose of the commit is to reintroduce the old behaviour of the
field, it should not display an error.
How to reproduce?
- Go to a form view with a domain field (in_dialog=True)
- Click on the "Edit Domain" button
- Add a domain comparing a field of type int with "01/01/2000"
Before this commit:
An error is displayed.
After this commit:
The domain is applied with the wrong value.
If the server considers the domain to be false, then "Invalid domain"
is displayed.
closesodoo/odoo#102753
X-original-commit: 7f22512149f5d634306cf0b280d055a60ba9e356
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the behavior of date, datetime and daterange
fields. It was no longer possible to open the date/datetime picker
by clicking on the corresponding label, since the inputs were
missing the id attribute associated with the label.
Now, it is possible again, and hovering the label will correctly
highlight the input border of the field.
Tests have been added too, to make sure this works properly.
closesodoo/odoo#102742
X-original-commit: 0e35d2b995165cfcb50db7eaec44cce7547eb4e4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
When a m2m field add a context in its arch, it's passed through to the
rpcs made to the server. In a m2m situation, while the name_search
worked properly, the read operation on a dropdown item select did not
provide this context.
This PR fixes that.
closesodoo/odoo#102741
X-original-commit: 5c7066fc064ecc175104603d524b52991678a2cd
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In Knowledge, we would like to disable the autofocus of the view search
bar when the view is embedded in an article. Disableling the autofocus
will ensure that:
1) The cursor of the user will not be teleported to the view search bar
when loading an embedded view.
2) The autofocus will not trigger a page scroll when the view search bar
is not visible on screen.
To disable the autofocus, we will simply add a new key in the default
configuration of the view. By default, the autofocus of the view search
bar will be active as it was the case before.
task-3004117
closesodoo/odoo#102724
X-original-commit: 1e9de9787613acb1066171568c5beb774235eea6
Related: odoo/enterprise#32543
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With this revision, we are now able to select a specific line item.
Useful especially in tests.
Part of task-id 2987871
X-original-commit: c8c7afc1e81c2e7de6b32de5db41d8f3d83a005c
Part-of: odoo/odoo#102688
This commit removes legacy views that are not used anymore as they
have been converted to owl. They could actually have been removed
in the commit that converted them, as we never needed to have a
double implementation of views, unlike we need to (field) widgets.
The LazyColumnList is a special case. This view hasn't been
converted. Instead, it has been decided not to use it anymore.
So it was dead code, and this commit removes it.
The form/list/kanban views are no longer necessary in the view
registry, since their owl version exists. However, we kept them
in the test asset, as they are massively used in legacy tests
(in field tests for instance).
closesodoo/odoo#102634
X-original-commit: 186a8b31161fc8c75b346ff97f9403dca1ae677e
Related: odoo/enterprise#32501
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The percentage pie field was broken in enterprise, because the rules
that it needs are overwritten in enterprise but scoped to the legacy
version only.
This commit moves the community rules so that they always apply and are
not overwritten, it also removes an extra level of wrapper on the field.
X-original-commit: e3dfb1bbaa7aa2bf2bed62fb278e09c739503f4b
Part-of: odoo/odoo#102611
Add missing `o_list_activity_cell` class used to allow the text overflow
and a rule to applies the o-text-overflow mixin on their spans child
Steps to reproduce:
> Open the helpdesk app
> Click on VIP Support tickets
> Go to the list view
> Reduce the size of `Assigned to` or `Activities` column
=> The displayed text isn't ellipsis
closesodoo/odoo#102608
X-original-commit: fabc5350904c207bda6e7cdffbae0d7309769e89
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
before, currencies were not aligned properly with the input field.
now, it is properly aligned.
closesodoo/odoo#102607
X-original-commit: 4be4d11d75f6a211685d122b6e1f2b97476c5416
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
Add missing feature of the ModelFieldSelector popover :
* keyboard navigation
* additional debug value
* add default value page ( for dynamic placeholder)
* add validate callback
Migrate dynamic placeholder to be compatible with new OWL field.
task-2978722
X-original-commit: 929108e29168058fad5da85e0ff9c66d2c5b2525
Part-of: odoo/odoo#102603
The purpose of this commit is to allow the restoration of open pages
in notebooks of a form view when switching view.
How to reproduce?
- Go to a form view with a notebook.
- Select a page in the notebook
- Go to another view
- Use the breadcrumb to go back to the previous form view
Before this commit:
The page opened in the notebook is the default one (the first one
or the autofocus one)
After this commit:
The page opened in the notebook is the one previously selected
closesodoo/odoo#102468
X-original-commit: 160c0347526612b6e6f93b8079eeb868d37d48f4
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, in new views, it is no longer possible to click
on buttons with barcode_trigger="..." using a barcode scanner.
Why:
New views no longer propagate all attributes to the button.
How to reproduce:
- Go to a form view with a button with barcode_trigger="doit"
- Scan "O-BTN.doit", "Enter".
Before this commit:
Nothing happens.
After this commit:
An event click is applied to the button.
closesodoo/odoo#102423
X-original-commit: b4cb2ee2662173e08f671eb736130f8332265de7
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before, carret was not contrasted enough which made it less visible.
Now, it's more contrasted and visible.
closesodoo/odoo#102564
X-original-commit: 49ffc05da315a9060233c9960038dd0b36a54d91
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
Previously, the emoji data that is used in the emoji grid was part of
the main assets bundle. This file is almost 500kB and the data it needs
is only needed when opening the emoji grid. This commit moves this file
into its own bundle and only loads it when opening the emoji grid
instead.
This PR also batches the inserts in the emoji model, bringing the time
it takes to do those inserts from ~8000ms to ~800ms.
closesodoo/odoo#102562
X-original-commit: e272e4fc6abce3153cce3748d8a5a7df63565916
Related: odoo/enterprise#32468
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, in a list view, it is possible to have two records
in edit mode at the same time if an error is thrown when saving
the editedRecord.
The editedRecord is the only list record that can be in edit mode.
Why:
If a server error is returned when saving the editedRecord, then it
stays in edit mode but is no longer considered the editedRecord of the
list. It is therefore possible to switch another record to edit mode.
Solution:
The record that fails its save due to the error should stay the
editedRecord of the list.
How to reproduce:
- Go to a list view
- Edit a record
- Click on another record (the "write" operation returns an error)
- Close the error dialog
- Click again on the other record
Before this commit:
Both records are in edit mode
After this commit:
Only the edited commit is in edit mode.
closesodoo/odoo#102560
X-original-commit: 77092167cf8f8fca11a39005d720fa82abeec0ae
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Before this commit
Suppose that in a form view, there is an x2many list view
that would open a form view dialog when edited.
For the dialog to open, the concerned record is duplicated and
passed in props to a FormRenderer.
Now suppose that this form view dialog also has an x2many list
view rendered somewhere: the StaticList datapoint attached to
this list will have the same context as its parent.
This is not what we want because some of the keys of the context
does not make sense with the list's model.
In fact, it has led to tracebacks to be displayed in case of we want
to open a record of this list in another form view dialog.
- After this commit
When those lists are created, their context are cleared from
their parents' keys starting with "default_" or ending with "_view_ref".
closesodoo/odoo#102557
X-original-commit: 1ba468706295f651105ca3fc8aae477b4f05c28e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
# Before this commit
The viewswitcher in mobile would take the whole width of the device.
# After
Fixed
# Explanation
The dropdown menu is positioned through the usePosition hook.
For this hook to compute a position, 019bbef
ceiled all the compared values.
But it may occur cases where the comparison was missed by a pixel.
Here we relaxed those comparisons in
manner that they may sometimes be off from 1 pixel, but at least the
positionment behaviour will be better.
closesodoo/odoo#102548
X-original-commit: 4c82a2bba675c71b57001fda0c2e242ddba99997
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
# Before this commit
The searchmenus are aligned to the right when there is no view switcher.
# After this commit
They are aligned to the left
X-original-commit: 2a167da8096730c2bf4348e19649a0f957144b6d
Part-of: odoo/odoo#102548
The commit e88988f mistakenly changed a scss rule
for the control panel bottom right section.
This commit reverse that.
X-original-commit: cc3bf7f736fe5778b4a93f1b439221557d2c8564
Part-of: odoo/odoo#102548
Restore the old CSS rule:
```css
.o_form_view .o_group .o_field_widget {
width: 100%;
}
```
Also note that since grid, ´.o_inner_group´ doesn't have the
´o_group´ class anymore.
closesodoo/odoo#102533
X-original-commit: 98dc0b9b9c17354d03714cb51fd3e310f16bef6a
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Only on devices not handling touch.
Before this commit, the phone, email, and selection fields always displayed
their field as in edit mode, even if not hovered.
eg. The envelope button of the email field, the SMS and call button of the phone field
and the caret of the selection field where always visible.
Since the form is always in edition, it doesn't make sense to always display those elements.
This commit makes those element display only on hover and on focus.
closesodoo/odoo#102489
X-original-commit: f87aa36f42fc190285241aeb8e1a4d9ab1644989
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This is a followup to: https://github.com/odoo/odoo/pull/102268
When navigating around the view with keyboard arrows:
**Before this commit:**
- there is blue outline on focused cell
- focused row is not highlighted
- https://youtu.be/kD72hic7dME
**After this commit:**
- row is highlighted when hovering or focusing
- no more blue outline on focused cell
- https://youtu.be/qqSqOVaqbEAclosesodoo/odoo#102512
X-original-commit: ded2cf44a7b6d6b79dbe8317be2018da922e0cfd
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit fixes the behavior of the FormView in a dialog. Since the
view is only visible in edition, it is no longer necessary to keep the
dialog open after the save has been processed. If the save has been
successful, the dialog now closes as expected.
A test has been added to assert this behavior.
X-original-commit: 86f68fe072a50baf49b9a8cf06f9c1e2541756e3
Part-of: odoo/odoo#102522
Before this commit, in debug=assets, if a test crashed for
instance because we try to click on an element that doesn't
exist, we tried to load the stacktrace js lib, via loadJS.
However, in the test environment, loadJS is patched to go
through mockRPC. If in that particular test, mockRPC did
an assertion (e.g. assert.step), we entered an infinite loop
of loadJS calls, which obviously made the tab crash.
With this commit, we ensure to use the real loadJS function
when we want to fetch the stacktrace lib.
closesodoo/odoo#102295
X-original-commit: 0661c8fa1dad88b1f9c9e177e25ddb97211f55a2
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Causes inconcistencies in the case of a o_form_nosheet (form view
without a <sheet> tag) and are visually not obvious enough to warrant
inspecting this very deeply. Remove them entirely.
closesodoo/odoo#102511
X-original-commit: 018a7a0706928930486e324dbac32c2497ec52ba
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
This reverts commit 8d7bcc8eee7a333e8e463469177a1a86f9928254.
The fix also impact a lot of form views without a <sheet> node
(o_form_nosheet), e.g. Settings, Knowledge articles, Mass Mailing, Bank
Reconciliation, widget, etc.
Not the correct solution.
X-original-commit: 00e71f3ebad40d32f74f945475fb474e89b6cf4a
Part-of: odoo/odoo#102511
Even if the `StateSelectionField` is readonly we doesn't want visual
difference and we remove the `disabled` class.
This behavior is the same as in 15.
We also remove `btn-link` as it's not appear as a link and we had to set
`p-0` to avoid the growing of the cell.
Steps to reproduce:
> Open the helpdesk app
> Click on VIP Support tickets
> Go to the list view
> Add kanban_state column => visual bug
closesodoo/odoo#102504
X-original-commit: 26d6942ed1b0c328d94e7dfd5e50c18a68c8c2f3
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
When the section and note fields were converted, the section and note
text field ignored the list-specialisation of the text field, resulting
in a textarea with a minimum height of 50 in list view which causes the
line to be too high. It was also not using the o_field_text class which
among other things hides the resize handle on the text area which looks
weird in list view. This commit fixes that.
closesodoo/odoo#102465
X-original-commit: 5735f89245f8efa980069973b3dbe94beac59061
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Going to My profile (user menu item when hr installed), the user name
is not fully displayed in the breadcrumb although there is enough space
to display it. We fix that by removing a rule that has become apparently
useless.
closesodoo/odoo#102492
X-original-commit: 09b5b83b41cd450359993eaca510d2e5b5a429ea
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Denis Ledoux