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>
Take the following QWeb snippet:
```
<div t-field="product.image" itemprop="image" t-options="{'widget': 'image'}"/>
```
When the image is rendered, the `itemprop="image"` remains on the
`<div>` tag, it is not set on the `<img>` tag.
We add the support of the `itemprop` option, so it can be added to the
`<img>` tag:
```
<div t-field="product.image" t-options="{'widget': 'image', 'itemprop': 'image'}"/>
```
opw-2076934
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>
In an onboarding situation, the company doesn't have a logo
make an invoice, send and print, print
The document layout editor's layout opens, because nothing is set up
on the company
Click Save
Before this commit, it was impossible to make the invoice print
because each time the document layout was displayed
After this commit, the invoice prints when clicking on Save
There is no default external layout for main_company
Also, the heuristic used to evaluate whether a company
has been set up, onboardingly speaking, has changed.
Before we used the existence of the logo, after we check if
a layout has been setup. When saving the document layout
modal, a report layout is written on the company
So, practically, the document layout modal only appears once
when trying to print invoices (or other documents)
closesodoo/odoo#37137
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.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>
en_US may not be activated as it is possible to create a database in
another language using the database manager.
When trying to install a chart of account, the tax return entry tried
to format a date at the installation of the module, with no lang in
the context. The fallback was made on en_US but an error is raised if
that language is not activated.
As it is a very common scenario to retrieve a language from the
context, add a generic tool method to do it.
Replace and closesodoo/odoo#37629closesodoo/odoo#37568
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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>
Fixes#33254:
* was in mail despite using mail.channel (which breaks if mail is not
installed, and web doesn't depend on mail)
* changes to sudo() broke previous behaviour (of having odoobot
message the admin, we ended up with the admin messaging themselves)
so fix that
* also get the channel and message with the user's context, otherwise
since we're during the login procedure the context could be as
little as just the lang from the browser and apparently channel_get
automatically creates a translation which would break if the
browser's lang is not installed in Odoo
closesodoo/odoo#37580
Signed-off-by: Xavier Morel (xmo) <xmo@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>
* base, web
Google now recommends a TTL of one year for static contents. We used to
use 1 week in almost every case. This commit increases that value to one
year for safe resources, like assets bundles which contain a specific
hash in the URL which changes if the bundle is recomputed anyway.
Note: this commit refactors the code so that both the one week and one
year durations are defined in http.py and used by others apps. Loading
the library "locale" file used to be done with 10-hours-cache, this has
been increased to 1-week-cache by using the http.py STATIC_CACHE var.
closesodoo/odoo#37402
Signed-off-by: Quentin Smetz (qsm) <qsm@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
fw-bot