| Age | Commit message (Collapse) | Author |
|---|
|
This is a simple renaming without adaptation.
|
|
|
|
This was introduced as a fix for grouped list views' headers while we
should have added the 'o_list_number' class instead... which is the
case now. So the oe_number rule became useless.
See https://github.com/odoo/enterprise/commit/a2ce226a2a085b26174cdfd32922517dff39658c
See https://github.com/odoo/odoo/commit/5d13a2f431e1c96e075b04d0eb07d98b912a6547
See https://github.com/odoo/odoo/pull/23966
|
|
|
|
|
|
In list view, the carret was not correctly positioned in empty cells (i.e.
handle widget in readonly).
This rev. ensures that the position rules are only applied if the cell is not
empty.
Fixes #23984
|
|
1. Added the ability to navigate within the List view using UP and
DOWN keys.
2. By defaults, the focus should be set on the search input field.
3. From the search input field, using the DOWN key, the focus goes
to the list
4. From the search input field, using TAB key, the focus goes to the
create button
5. From the create/import buttons, using TAB or DOWN key goes to the
first row of the list, then UP and DOWN keys moves the focus from
item to item in the list.
6. When on a row, hitting ENTER opens the view of that row.
Also in this commit
1. When on the first row, hitting the UP key does nothing
2. When on the last row, hitting the DOWN key does nothing
Not included in this commit
1. Memorize the position on the list when opening an row, than
restoring when going back to that list
2. Navigation on grouped list using the keyboard
|
|
Adapt tests and classes
|
|
|
|
(#23719)
* [FIX] web: Make accessible with keyboard the delete button on o2m fields
Currently, the delete button in one2many fields (trash icon) is not
reachable when using the keyboard, because it's neither a link, nor a
button or any other interactable HTML element, but a `<span>`.
This change causes that button to be an actual HTML button keeping the
same appearance, so it may be reached when using the keyboard.
* [FIX] web: Modify test to expect button instead of span as o2m trash icon
Since buttons to delete records in o2m fields (the trash icon) were
changed from `<span>` to `<button>` to be able to access them with the
keyboard, the test need to be modified so it expect the new element
type and doesn't break.
|
|
In many2many lists, the remove record from the widget is a trash bin.
It is confusing, as people feel they are deleting it when they are
only unlinking it.
So in many2many, we propose to change the trash icon by a 'X'.
This icon appears in many2many relations and in many2many widgets:
even though hr.expense.sheet defines the expense lines as a one2many,
it uses a many2many widget, so we use a 'X' instead of the trash bin.
To avoid ambiguity, we decided to rename 'delete' to 'remove'.
|
|
|
|
|
|
|
|
Before this commit, m2o external button was always floating outside the
m2o main DOM element, on the right. This induced problems when using the
m2o outside of views (like in Odoo Studio). Now, the m2o design is made
so that this button is inside the m2o, except in form views where we
expect the button to overflow in the tables' right paddings.
|
|
- Tags' text were able to overflow their cell to the right
- In-edition elements were sometimes hidden by other rows' content
|
|
- List view: sortable icon, do not force position to right
- Mail: do not vertically reposition systray's icons
- Form view: oe_subtotal_footer, minor design imp
|
|
|
|
|
|
Tested with enterprise new design.
|
|
Minor changes to allow better design.
|
|
Make sure '.o_invisible_modifier' table-cells are forced back to
`display: table-cell` to keep correct alignement. Indeed using the
`initial` value forced them to `inline` instead (creating some
obvious visual bugs in some cases).
|
|
In an editable list view, the translation icon would display incorrectly
(out of place) for translatable char fields. This can be traced back to
two reasons, compared to saas-15:
- We now use tables instead of divs for list views
- The translate icon would have inline css that would override its
positioning with top and left attributes
This is fixed by adding top and left attributes to translate buttons
inside a field inside a table cell using CSS classes
|
|
... in group headers, and in footers.
|
|
Before this commit, numbers in list views were right-aligned
depending on the widget they were using (float/monetary). Now, the
input text alignment is inherited from the parent which should
solve the problem.
|
|
An invisible cell should be visible in the list renderer otherwise
the cells are not correctly aligned anymore.
|
|
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
|
|
Before this rev., there was no pager rendered in groups that
contain more than 'limit' records.
|
|
This commit comments some LESS files to help the user to understand
for what their content is used (preparing the LESS editor feature).
|
|
|
|
Forward-port of https://github.com/odoo/enterprise/commit/8a55b3f9f7a7524583effb8198c03ebf695131bd
There are multiple problems with the editable view list. It should be
solved once and for all in the work-in-progress master.
This commit fixes a bug with readonly checkboxes. When a field is
readonly, the table cell gets the "o_readonly" class which changes
its style and behavior. When entering edition, the cells are hidden
except the ones with this "o_readonly" class so that their style are
not affected. The "o_readonly" cell content however was hidden thanks
to a "color: transparent;" rule to let the form readonly field show
the value. The problem is that checkboxes... are not hidden with this
"color: transparent;" rule. Also, the "o_readonly" class is not toggled
during edition while the readonly status could be... so the right fix
would be to get rid of this "o_readonly" class and let the inline form
handle the behavior, but this would affect style and possibly break
unknown behavior.
This fix adds rules to handle the checkbox case correctly.
|
|
|
|
84a650e33aadb29661121410813e3de37a5ad3e9
|
|
Fix and issue is similar to odoo/odoo@1f06cc416
When clicking on delete icon before saving current list row edition (by
clicking outside the editable field), it could lead to traceback in some instances
because the deletion and saving are done concurrently.
closes #627
opw-695743
|
|
When positioning an element in an editable list view, that element is
temporarily forced to display: block thanks to the class o_temp_visible
The rule is written in LESS thanks to:
.o_list_editable .o_temp_visible { display: block!important; }
which is ok for normal invisible form fields because it is written as
.o_form_view .o_form_invisible { display: none!important; }
which has the same priority but is defined before the o_temp_visible
rule, so the display is properly forced to block.
However, for some reason, there also is the rule:
.modal .modal-dialog .o_form_invisible { display: none!important; }
which has a higher priority than the o_temp_visible rule.
This is why appearing invisible fields in editable list view in modals
are at a wrong position.
The solution introduced by this commit is the safest: adding a new
rule to force display block!important on the selector:
.o_list_editable .o_temp_visible.o_form_invisible
|
|
This is triggered by the interaction of the `-webkit-overflow-scrolling` [1]
rule that is set on the top of the modal (div.modal) and the fact that inputs
elements are displayed over the table with an absolute positioning (that's
how the editable lists work).
Indeed, the `-webkit-overflow-scrolling` rule creates a new stacking context [2]
and is inherited by all the children of the modal (and so on), resulting in this
situation:
.modal
/ \
... (new S.T.) ... (new S.T.)
/ \
... (new S.T.) ... (new S.T.)
/
.o_list_editable (new S.T.)
/ \
.o_form_view (new S.T.) .table-responsive (new S.T.)
/ | \ \
input input input table (new S.T.)
This explain why the input are not visible: actually, they are displayed
behind the table. In this case the document order is used to know which
div should be in front of another div[3], that's what rev odoo/enterprise@304b790004511badeb664621fc9e483aff35ff9f [4]
tried to change. However, this was not enough for iOS 9.3 / iphone 6
because, for some unknown reason (but probably due to the fixed position
of the modal that seems kind of broken on safari mobile), the inputs where
still displayed under. Note that the fix was ok for ios 9.3 / ipad air 2.
The fact that `-webkit-overflow-scrolling` creates a new stacking context
at every node seems odd, unfortunately removing the rule result in a non
scrolling div at all.
The fix is to explicitely tell the input to appear over the .table-responsive.
This is done by sharing the same stacking context under the common parent
between the form and the list view: .o_list_editable. For that, we prevent
the creation of a new stacking context under .o_form_view by reseting the
`-webkit-overflow-scrolling` to "auto" and we set a dummy z-index to the
inputs element. As they are the only one to have a z-index in this dom
range, they will always appear on top of the table.
With this solution, the `-webkit-overflow-scrolling` is still inherited
correctly and the div is still scrollbale.
This fix unveils another issue with the editable list: if the screen is
too small resulting in an horizontal scrollbar, the table in itself is
scrollable but the inputs aren't.
opw 683169
cherry-pick of odoo/enterprise@35f285e50a760e4ad59d7a2e484c0006b602c2e8
[1] this rule allow a smooth scrolling of the content of a div on iOS
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
[3] https://www.w3.org/TR/CSS2/zindex.html
[4] This commit has been reverted with odoo/enterpise@287cff02c789876c5e24725df0350afe1b664cbb
and never forward-ported to saas-10.
|
|
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
Mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
|
