Since o_form_view class was not placed on the right element, as the
form is displayed in a dialog, some styles were not applied in x2Many
dialogs using a form view. Now, the selector matches all cases and
dialogs will be stylized as expected, since the class is placed on the
dialog container instead of the first div.
Now, we are consistent both for dialogs and standard form views.
Tests have been adapted to work as expected.
closesodoo/odoo#102953
X-original-commit: af67305b43d51e1669df19d376d9bda7418ba863
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Prior to this commit, the border of any badge was set to "1px
$o-brand-primary" in order to achieve the default badge design that
comes with transparent background.
Unfortunately this rule was affecting colored badges too, leaving no
choice rather then either remove the border (causing misalignment with
siblings default badges) or hide/re-color/keep the undesired decoration
, but with mixed results.
These commit will review the behavior applying an outline (that doesn't
affect badge's placement) to "default badges" only.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Prior to this commit, there was no common custom file to easily handle
select2 color values (e.g., dark mode).
This commit fixes this issue by redefining the values in webclient.scss.
task-2710677
Part-of: odoo/odoo#102868
Commit preparatory to the introduction of dark-mode.
note: Tooltip variables should be reworked in order to correctly handle
different scenarios. For simplicity this commit will just match popover
colors.
task-2710677
Part-of: odoo/odoo#102868
Move the file in a more convenient place to be shared and customized to
match different color schemes.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
This commit adapts several components in order to correctly handle
color-scheme variations.
It also allows user_menu to handle switch entries
task-2710677
Part-of: odoo/odoo#102868
The '$o-theme-text-colors' provides a list of fine-tuned text-color that
differ from the bg ones since used for text.
This commit adds `$o-brand-odoo` in the list.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Since the view's backgound-color has been historically white, white
borders have been used to adjust layout discrepancies between
components.
This commit introduces 'border-transparent' to handle the scenario
regardless by the view background color.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Since the view's background-color has been historically white, the
`bg-white` class has been used to make match several UI components.
Despite working for the default color-scheme, this approach leads to
inconsistencies when the default view's background-color changes, eg.
dark-mode.
This commit introduce 'bg-view' to set any element to match the view's
background-color, whatever it is.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Partially remove visual discrepancies between odoo and Bootstrap fields,
allowing to use BS variables to control fields' design across versions
and color-schemes.
This commit is preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Before this commit, the user was not notified when he
closed the tab or the browser while modifying a record.
Now, the user will be asked to confirm the close if there
is at least one invalid field.
task id: 2994132
closesodoo/odoo#102990
X-original-commit: 3fcc36786453f3006974f5fd0fa395ad5d07d9a2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a grouped list view with at least one
group_operator and optional fields, the aggregated values in the header
are shifted one column to the right.
Why is this?
Adding the +1 to the colspan in the group header for optional fields
is always added on the left side (group name).
Solution:
The +1 should be added on the left side (group name) if there is
no aggregated value otherwise on the right side (pager).
Before:
TH TH TH TH TH AGG AGG TH AGG AGG TH TH TH OP
0 1 2 3 4 5 6 7 8 9 10 11 12 13
[ TH 6 ][TH][TH][TH][TH][TH][ TH 3 ]
[ group name ][ aggregate cells ][ pager]
After
TH TH TH TH TH AGG AGG TH AGG AGG TH TH TH OP
0 1 2 3 4 5 6 7 8 9 10 11 12 13
[ TH 5 ][TH][TH][TH][TH][TH][ TH 4 ]
[ group name ][ aggregate cells ][ pager ]
closesodoo/odoo#102754
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, some functions overrode the save function of the
form controller. The issue is that this function is only called when the
button save is clicked, and not when we save differently (for example,
when clicking on the breadcrumb).
To avoid this mistake the save function on the form controller was
renamed to: `saveButtonClicked`, and the code that overrode the function
now override the save function of the Record, that it's called at each
time a save is perform.
X-original-commit: b6e3d833e6131562084eb13b2955c22f50ad1e79
Part-of: odoo/odoo#102992
This commit reverts https://github.com/odoo/odoo/commit/0e0a2014b31e2fc6423e80971ac451a2dfe89de9
Before this commit, the string separator was too close to the
previous label/field.
We now have the same margins as in 15.3.
Steps to reproduce:
- Sales -> Orders -> customers
- Choose any
- Sales & Purchase tab
closesodoo/odoo#102978
X-original-commit: 0510f5ed80bbffbee249e709d1df90192ee08f02
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In legacy, an m2x autocomplete would not display extra lines
received from the server inside the dropdown menu.
This commit reintroduce that behavior as it was lost in the
wowl conversion.
closesodoo/odoo#102954
X-original-commit: 1b2686aeadfac97f060a07de86e5a0eb2051eee2
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Purpose
=======
Convert the remaining legacy views in OWL. Before this PR, the list and form views are still in legacy in Project Sharing feature. The goal of this PR is to convert those views to have all views in OWL in Project Sharing.
Details implementation
----------------------
- Convert the list view in OWL
- Convert the chatter portal in OWL to be able to convert the form view in OWL
- Convert the form view in OWL and integrate the chatter into it.
- Review the assets used in Project Sharing to reduce the size of the assets since all components and views existing in the backend are not used (only the list, kanban and form views are used)
- Review the rows attribute set on `textarea` HTML element in`TextField` to be able to altered it with a props.
- Change the `FileInput` component to be able to override it to be able to use it when the route is different than the one set by default.
- Fix the `useInputField` hook to be able to use the `TextField` component without any `record` set on its props (since this prop could be optional).
task-2947516
closesodoo/odoo#102932
Forward-port-of: odoo/odoo#102130
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
In 15.3, the width was applied on `o_form_sheet_bg`.
As the form view has been refactored in 16, we have to apply
it on the new parent `o_form_view_container`.
We also restore the chatter width to the same value as in 15.3:
```scss
.o_FormRenderer_chatterContainer {
&.o-aside {
width: $o-chatter-min-width;
}
}
```
Steps to reproduce:
- Open Helpdesk on screen at 1534x657
- Open a vip support
- Unfold 'Done'
- Click on 'Ugly Chair', the chatter take a lot of space => bug
Steps to reproduce
- Open Sales
- Open a quotation
- Switch between Order lines, Other info, Customer Signature
notebook tabs a flicker occurs => bug
closesodoo/odoo#102911
X-original-commit: 3e71df358caf878409947af1619378fbfeb2be4b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit refactors the style for borderless inputs and
adds a special class to better manage where they should be used.
closesodoo/odoo#102848
X-original-commit: 6b45cd5f3fbe0986e36401308d19214b689adc45
Related: odoo/enterprise#32609
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Before this commit, the `FileInput` component can be used with another
route only if the route has the same params than the default one.
For instance, the portal chatter route does not have the same params
name and so, the component cannot be used.
This commit refactors the component to easily override the
component to be able to use it in each case.
task-2947516
X-original-commit: 8fdeea2e9918c8199724b177003f858716d7d5a4
Before this commit, the rows attribute given on the TextField component
was always 2, it is not possible to alter it without overriding the
component.
This commit adds a props to be able to update the rows with a prop
called `rowCount` and this prop can be set via `rows` attribute set on
the field.
task-2947516
X-original-commit: 110915c80c2a2578563283b1744e0e88d80ac4bb
Before this commit, when a component using the `useInputField` hook (for
instance `TextField`) and the `record` is not given in its props, the
hook will crash since it assume the `record` is always defined. However,
the props definition the `record` is optional.
This commit checks if `record` is defined in the component before using
it to be sure to avoid any crash because it is not defined.
task-2947516
X-original-commit: ebe3d00e52dd6097ce55986bc9e3bf9d79ca64cc
Before this commit when list view is in multi edit mode and there is a field
with required and readonly modifiers, the field is underlined, which is not
intended as the field is in readonly mode.
task-3000817
closesodoo/odoo#102871
X-original-commit: fa6e2bb566f05e064ff8f4df40f1f01b048ade60
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Rationales:
- having a textual display "Unsaved changes" implied to the user that they
had to save
- having buttons "hiding" behind a hover effect on a span of text was
very unintuitive
- since we don't want an hover anymore, having text buttons would draw a
lot of attentions => use icons + tootltip instead
closes odoo/odoo#102757
Forward-port-of: #102605
Related: odoo/enterprise#32570
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When there is too many options inside search view, they didn't wrap and will overflow outside the screen.
closesodoo/odoo#102812
X-original-commit: 8a63d9773b14e212618c3d0d298f0926547e1045
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Commit [1] added back the user context to every RPC called from the
legacy env when it's mapped to the WowlEnv but in doing so, overrode
the params' context keys.
This is incorrect as the params could very well have context params that
are different from the session's params for a reason.
For example, in master, after [2], editing the menus of a website
displayed in a language different from the user's will lead to incorrect
languages in the context when the page is saved. This is cause the
language in which the page is edited is passed as a context param, and
the language of the user is in the session (under the same `lang` key).
[1]: https://github.com/odoo/odoo/commit/d959638e23a92cf880049a760c42da33e5908f41
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 8cdb2293f294558c3bea4ed59a49e0f52b3d217e
Part-of: odoo/odoo#102799
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, when the day of the month was smaller than 10,
multiple days were highlighted as today on the datepicker.
Now, only the correct day is highlighted.
closesodoo/odoo#102296
X-original-commit: 0545178d5d09f659d5309069ebcae9d7162356a0
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
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>
luvi