Allows the quick create on m2o in list views
Before this commit, when entering a new value in a many2one in a list and
exiting the cell through a click, the quick-create modal appeared for the
duration of the mousedown.
Now, the modal remains and allow to edit the new many2one value
Task 2076380
closesodoo/odoo#38289
X-original-commit: c00f84eb0a176b8d23927080078eb02dc2e5d806
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We don't want the browser to fill inputs in the backend.
Most of the time this is useless but sometimes it is
even problematic. For example, focusing an input in a
modal can trigger autofill not only in the modal but
also in the whole page. If there is an input outside
the modal and it is recognized by the browser as a
candidate to fill, bad things occur.
For that reason, we set the attribute autocomplete to
"none" by default for input elements.
Note that "off" does not work all the time because
the browsers sometimes decide to ignore it.
Task ID: 2076730
closesodoo/odoo#38039
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This reverts commit 08108486d5.
+ Fix the url that add a useless ending / and so a useless redirection.
There are no problem of mixed content or anything else, if you configure nginx
and launch your server in proxy-mode as specified into the documentation.
closesodoo/odoo#38196
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit adds a test case for the recently introduced 'records_draggable' option in the kanban
view.
Initial test was not written because of social app rush before 13.0 release.
'records_draggable' feature introduced by 869a5b83a5
Task#2082068
closesodoo/odoo#38166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The feature that allows res.lang's first day of week parameter
to be the reference point of web calendar
has been introduced at 27b30daea5
A few other came on top of it to fix a few things
Before this current commit though, only Fullcalendar was
rendered using that initial value, nothing was done
to actually fetch the right data
After this current commit, we fetch data from the server
according to the range displayed by the calendar
OPW 2072872
closesodoo/odoo#38131
X-original-commit: 0bd82ef6489f3ea1da26fb6ee337b15e3f13d4e5
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since bb37077610 (apparently), trying to regenerate the assets through the
crash manager result in a traceback.
Indeed, utils was not defined.
closesodoo/odoo#38129
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, invisible filters were rendered by
QWeb but hidden in the filter menu. This used to break
the keyboard navigation in the filter menu.
Now we don't render at all those filters since they were
completely useless anyway. This fixes the original
problem.
Task ID: 2057012
closesodoo/odoo#37567
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Backport of 64f6e50d0c, with a test!
Closes#27109
Purpose
=======
If the model on a reference fields is not modified from the interface
by the user but by the server, the selection is not correctly
recomputed on the interface.
Specification
=============
By calling super first on the '_reset' method, the new model
is taken into account when resetting the selection.
closesodoo/odoo#38109
X-original-commit: b5b992d9c4e85c224ded795ff9ce14d1608b3ed6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Open a search view modal ("search more" on a m2o)
Select a filter that will make records fall to zero
The modal will shrink
Trigger the opening of a dropdown (Filters), and make sure
that there are many many menu items there (many filters)
Before this commit, the dropdown was bigger than the modal
which had a scroll bar,
however, the dropdown itself was not scrollable properly
So, clicking in it to select a menu item will fail when scrolled
all the way down, because elements did not actually followed the scroll
After this commit, the dropdown follows the scroll, and it is possible
to use it even way down
We use a behavior of bootstrap 4 itself:
FIX: https://github.com/twbs/bootstrap/pull/24976
ISSUE: https://github.com/twbs/bootstrap/issues/24251
OPW 2076337
closesodoo/odoo#38080
X-original-commit: c3273b7a1c0c09aeef23df4ba4be8d68fd46a6f3
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Changes the behaviour of many2ones when their value is changed via a form dialog.
Before this commit, when editing a m2o with a form dialog opened by an external button,
the field triggered an onchange with its old value before reloading its widget.
This caused the edition in list views to display outdated information when
saving multiple records.
Now, the reload is executed first, then the onchange occurs so that the value is
the newly updated one.
Part of task 2078807
closesodoo/odoo#37576
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The button to apply a custom group (Group By -> Add Custom Group ->
Apply) was unreachable when using the keyboard.
Remove the unnecessary attribute `tabindex="-1"` probably added for no
apparent reason.
closesodoo/odoo#37982
X-original-commit: 373c69bca366180601b760f05f219a4698e3c014
Signed-off-by: Luis González [Vauxoo] <luisg123v@users.noreply.github.com>
This commit removes some historical overflow-x properties needed
for old kanban views.
Steps to reproduce:
* Open Project App
* In kanban view and with one element, click on "more button" (3 dots)
* This menu will be truncated at the end. (BUG)
Task ID: 2058510
closesodoo/odoo#37727
Original-signed-off-by: Romeo Fragomeli <rfr@odoo.com>
X-original-commit: f4031c62f97fa170b74b0d13a0856b7d58ed4da6
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit avoids the swipe feature when we are moving/resizing an event.
Task ID: 2071605
closesodoo/odoo#37715
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
* website_sale_comparison
The Bootstrap sanitization introduced with BS 4.3.1 was disabled with
https://github.com/odoo/odoo/commit/36caf5fc16b5a95a0bf37f08f0caf974683b2df6https://github.com/odoo/odoo/commit/ee94decd30c4514d5bc410b1652bc6464bb600aa
This commit re-enables it by default but extends it to accept more
common tag names like tables and buttons. If a specific tooltip or
popover must accept custom tags or attributes (such as data-* attributes
required by a related JS), they must be supplied through the whitelist
BS parameter explicitely (see example with website_sale_comparison in
this commit).
Note: data-oe-* attributes are also whiteListed by default.
We cannot disable sanitization because bootstrap uses tooltip/popover
DOM attributes in an "unsafe" way.
closesodoo/odoo#37631
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this commit, the "renderer with search panel" have a max-height
of 100% but no min-height. Because of this, it is possible that the
list view optinal fields dropdown would be smaller than the "renderer
with search panel" container. Since this particular container has to
be in overflow: auto (see the comment on the line above the change),
it hides the overflow of the optional fields dropdown.
This commit sets the height of the "renderer with search panel"
container to 100% such that it does not truncate the optional fields
dropdown. The bug was observed on the General Ledger menu of Accounting,
and the change does not look to change anything other than correctly
displaying the optional fields dropdown without truncating it.
closesodoo/odoo#37660
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, m2m fields were not updated when multi editing
in a grouped list.
Now, the fields are updated no matter how many levels of groupBys
are applied to the list.
Part of task 2078807
closesodoo/odoo#37589
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
o_control_panel have this layout:
+-------------------------------------+
| PADDING |
| +----------------------------------+
| | breadcrumb o_cp_searchview |
| | o_cp_left o_cp_right |
| +----------------------------------+
+-------------------------------------+
As you can see, there is a padding on the edge of the widget.
In Odoo 12.0, before the control panel refactoring (odoo/odoo@40dd121938)
the search view was a widget by itself (addons/web/static/src/js/views/search/search_view_mobile.js).
Note that in this case, once the following condition:
"ev.target === this.el" was reach the normal behavior
was executed.
But now the search view is embedded in the control panel.
There is a side effect: clicking on the padding of the control panel
triggers the "_onOpenMobileSearchView" and the condition is always true.
Therefore we try to open the search more even if it doesn't exist.
But anyway, the search view (full) shouldn't be opened when we click on
the control panel.
After this commit, the listener is scoped to o_toggle_searchview_full,
to avoid this side effect.
Steps to reproduce:
* Open any app with a control panel (e.g. accounting)
* Select a record (e.g. an invoice)
* Click on the padding of the control panel (BUG)
closesodoo/odoo#37587
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
only activate multi-edit on list with specific attribute.
When the attribute multi_edit="1" is set on the tree view the user
can select a/some records and it will activate the multi-edit
with confirmation dialog (even for a single record).
Also, on-change are not applied when using multi-edit
closesodoo/odoo#37525
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Create a simple subclass of AbstractAction (a client action), with
property hasControlPanel set to true. By default, the name of the
action should be displayed in the breadcrumb. Before this rev.,
it wasn't the case, as it displayed 'Unnamed' instead.
Bug spotted when doing an exercice for the JS smartclass.
closesodoo/odoo#37465
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, there are no hooks when dragging a field over an
editable listview. This was caused by wrong computation of column
width in studio mode.
This commit isolate the computation of column width, so that studio
can override it and make the correct computation.
Task-Id 2057829
closesodoo/odoo#36959
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
1/ Write a form view with a o2m field that has its own inline tree view
(no other view exist in db for the target model)
2/ Open that view in a mobile environment
3/ Instead of having a list view, you get a kanban view. No luck for
you, since the default kanban generated by `models.py` is an empty one,
your records are *invisible* \o/
From what I can tell, the previous condition made no sense:
```
if (there is a list view and a kanban view) <-- this seems absurd
then (use the list mode)
elif (there is no list view but a kanban view)
then (use the kanban mode)
else (use both modes)
```
The first condition seems absurd: it *actively* ignores a kanban view
if there is one. Even better, the list view whose existence it checks
is never there: it checks for a `tree` when it should be checking for a
`list`. In short, the first condition was *never* met, and you ended up
either with exclusive kanban mode or with both modes - even if you had
no existing kanban view for the target model...
This commit moves the normalization of `tree` into `list` before
attempting to process the x2many field's subviews. It clarify the usage
of `tree` vs `list` (cf. only use `list`) which prevents weird edge
cases like described above.
closesodoo/odoo#36237
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
Go to Accounting > Accounting > General ledger. The view is grouped
by account. There is a layout issue as the first column (date) is
positionned after the group names, leaving a large blank space.
This is because the date field is considered as an aggregated field
(for sorting purpose, in python), but the JS can't (and we don't
want to) display it. This rev. ensures that such field types are
completely ignored by the JS, s.t. they do not impact the layout.
closesodoo/odoo#37113
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
*:board,hr_skills
Hold on tight, this is a tricky one.
Allows *any* readonly list view (only plain lists, not x2manies) to
become partially editable when checking records.
This means that once checked, a record line acts just like it was
in an editable list. You can click on it, edit any of its values as long as
they're not constrained by readonly modifiers, and save them on the fly.
Clicking on an unchecked record will have the same effect as before:
it will open the record, regardless of the other selected records.
You can also check multiple records and edit them all at once by
changing the value of one selected record (just like standard multi edition).
Keyboard navigation is also allowed between selected records (TAB and SHIFT+TAB
to navigate and ENTER to save).
/!\ If a list is only made of records having all of their fields locked by
readonly modifiers, checking a record and clicking on it will do absolutely
nothing. This is to keep consistency with the rest of the specs.
Task 1967602
Setting 'overflow: hidden' on the (hidden) textarea used to compute
the (visible) textarea height ensures that there is no vertical
scrollbar, which would lead to a not so precise computation of the
height. The bug could be observed in sale.order form view, in the
order line x2many (description field), and had been introduced by
ef46378cd3.
Changed the information dipslayed by the confirmation modal in multi edition
in list views.
Before this commit, the modal simply showed a one-line message with the amount of valid records.
Now, there are 3 elements:
- If all of the fields cannot be changed, a first line warns the amount of valid records.
- A second (or first if all fields can be updated) line ensuring that the user is aware of
the occuring changes.
- A table displaying the affected field and the updated value (readonly widget with the new value).
Part of task 1967602
In an editable list, select a very long value in a many2one...
Before this commit, the table stretched as much as it needed to to
display all of the columns content.
Now, the largest columns are trimmed in order to keep the table
as wide as the list container (meaning it won't overflow anymore
unless there is a huge load of columns).
Also ensured that values trimmed by this feature are followed
by an ellipsis.
Task 2068261
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, resizing a column would cause the
list to develop a mind of its own and to grow/shrink random
columns according to its own will.
Now, resizing a column does not "freeze" the list anymore and simply
gives a static width to the resized column.
When the content of an autocomplete dropdown (e.g. many2one field)
was long, the dropdown could overflow the page. For instance, this
was the case of the intrastat_id many2one.
Task 2068261
Let's assume an editable list view with at least two rows. Before
this rev., the column widths were re-computed and frozen each time
a record was switched into 'edit' mode. As a consequence, if the
user clicked on a row, and then on another one, column widths might
slightly change.
Task 2068261
ClassNames 'oe_read_only' (resp. 'oe_edit_only') can be used in
x2many lists to hide columns in 'edit' (resp. 'readonly') modes.
However, before this rev., there were two issues:
1) Having such a className on a <button> tag didn't work well as
the 'display: none' rule didn't apply on the body cell (it only
applied on the button). Same could be observed on <widget>
nodes.
2) Having more than one invisible column (with those classNames)
didn't work either, because the footer cells weren't hidden.
We didn't notice it with one invisible column, because the
footer contained one cell less than the header and the body.
Those two issues could be observed on the mrp.bom form view.
Task 2068261
Before this commit, editing a record e.g. in a form
view and toggling the home menu would cause the discard
warning to be displayed twice when going to the home
menu (in enterprise) and then once again when going to
an other app. This is now fixed.
Task ID: 2043027
closesodoo/odoo#37301
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
* web, theme_bootswatch
Improvement of https://github.com/odoo/odoo/commit/02a321cffb2da60a86b960e75c445e37094567b4
- Clarify the name of the support font (to distinguish it from standard
and google fonts and avoid confusion with Noto Sans and Noto Serif).
- Make sure the support font is added and can be added for all font
definitions in odoo scss files thanks to a scss function.
Could be backported in 12.0 if judged necessary.
Part of https://github.com/odoo/odoo/pull/37293
The new export feature forgot to filter out the action buttons that can
be displayed in the list view. (see odoo/odoo@5c4544f)
This lead to javascript trying to get fields on the model like
`action_validate` which obviously doesn't exist.
closesodoo/odoo#37261
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
The format of `many2one_reference` was not introduced when the new field type
was created, which leads to errors when the web client is trying to display the
value of such fields.
Since the value of this field is an ID, it is decided to display it like an
integer, which is consistent with previous behavior: the fields that are now
`many2one_reference` are still stored as integer and they were already displayed
as integer before.
closesodoo/odoo#37216
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit fixes:
- body of a email.template in a small field
- translation of website_description of a product does not show the
source of the translation
- translation of website_description of a product shows the full
content for the current language
HTML fields are typically fields with longer of content.
If the field is an HTML field, it should be displayed in a textarea,
like the text fields.
Most of HTML fields are split in meaningful chunks of content (using
xml_translate or html_translate method).
For these fields, the source must be displayed.
Also sort the entries on the source to have a consistent order
closesodoo/odoo#37215
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When having a long systray (icons from different apps, mode debug,
multi-company...) the resize of the window can trigger a crash for apps
that have not too much top-level menus (e.g. Contacts).
This also happens when loading those apps.
Steps to reproduce (on an iPad, portrait):
* use a Runbot with all modules installed (12.0+)
* activate "debug mode"
* ensure that the menu/systray bar is quite full
* open the "Contacts" app
=> traceback with a "cannot call getBoundingClientRect of undefined"
error
The reason is that the resize's callback iterate over the systray/menu
items to find which one should be folded behind a "more" ("+") menu
item.
Sadly in some cases (combination of screen width, systray size, app's
number of menus) it can lead to a traceback.
This commit ensures that when looping for menu items, we don't try to
reach an non-existing item.
closesodoo/odoo#37245
X-original-commit: d7bae0329990171710acf2d9c0d4d9579cba2c0e
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
From the settings activate:
- Multiple Sales Prices per Product
-- Prices computed from formulas
- Discounts
Create a pricelist with discount policy "Show public price & discount to
the customer", set the price calculation formula:
- Rounding: 10
- Price discount: 10%
Modify the sale order xml list view adding 'digits="[3, 2]"' to the
discount shown in the sale order line.
Create a sale order with such pricelist and on the so line put a
product with quantity 1 and sale price 4190 (VAT 19% included in the price).
The discount will not display the requested number of decimal digits (2)
in list view, but it will when editing the field.
The cell formatting is done calling the appropriate function (formatFloat),
which search the digits option from the 'options' parameter or from the field
definition. The latter stores the default digits coming from
the DecimalAccuracy settings, which, as side effect, alter the behavior
of the discount calculation.
https://www.odoo.com/web#view_type=form&model=project.task&id=2069939&active_id=2069939
When passing into edit mode the field is created as widget, parsing its options
which have 'digits', instead when coming back in list mode it is "just a
float field" rendered directly from the list_renderer which no options,
so the formatFloat will look at the field definition
https://github.com/odoo/odoo/blob/12.0/addons/web/static/src/js/fields/field_utils.js#L172
Adding the correct parameter to the dictionary passed to formatFloat
during the list rendering is a possible solution, because it is the
"closest" point in which parsing the parameter is possible without
touching higher level code or forcing the creation of a widget (adding
widget='float' as xml parameter).
closesodoo/odoo#37167
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Add the following in a PDF report:
```html
<p>
<blockquote>
<ol class="loweralpha simple">
<li>Item that explain terms</li>
<li>Another item that explain something else</li>
</ol>
</blockquote>
</p>
```
- Print the report
Wkhtmltopdf crashes with the error:
Wkhtmltopdf failed (error code: -11). Memory limit too low or maximum
file number of subprocess reached. Message : b''.
This is a known issue:
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/4115
Actually, since this CSS is only used for Wkhtmltopdf reports, we can
simply remove the CSS rule causing the problem.
Closes#37034Fixes#37033
opw-2073195
closesodoo/odoo#37155
X-original-commit: 8d08893172ae8c0f3ad1f1af6ab9514aa30bf843
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since fbbfa6d it's not longer possible
to write a date without separator (e.g., 0102 for 01/02/2019; 121298 for
12/12/1998; 02042018 for 02/04/2018), or a date without year (e.g.,
01/02 for 01/02/2019) in the datepicker widget.
In this commit we have decided to be as permissive as tempus dominus
that call moment.js with strict false. This allows moment.js to deduct a
date from a string in a more versatile way. This also allows a more
versatile autocomplete in the search views.
opw-2070464
opw-2070931
closesodoo/odoo#37095
Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Changed the way the header selector behave when the selection changes.
Before this commit, the header selector was only checked when clicked and
was unchecked as soon as any other record was unchecked.
Now, the header selector reflects the current visible selection:
if all of the other visible selectors are checked, it will be checked.
Folded records are not considered visible, thus only records from active groups
and from the current pager will be taken into account.
closesodoo/odoo#36522
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
fw-bot