The point of this warning is to help a view developer realize that
his view is not loaded at all. However, console 'error' and 'warn'
are observed by the runbot clickall tour as meaningful errors
regarding a build resulting status. It makes sense, but it is an
issue for community modules which have a gantt view that only
exists in Enterprise. We don't want to create a bridge module
for each and every module which uses a view that only exists in
Enterprise, so we need to live with this warning. Since its
purpose is for developers only, they can read the log and notice
the error even if we use console.log rather than console.error,
and that will not alter the result of the runbot clickall tour.
closesodoo/odoo#33814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since JS refactoring of ActionManager at 32b8cec536, the /apps/<app> controller
was not working anymore as the refactoring dropped the support of `sa` as URL
state.
closesodoo/odoo#33679
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If an error is raised when saving a calendar event, the transaction is
correctly rolled back. However, the view is not refreshed and the
incorrect information is displayed.
We simply reload in all cases.
opw-2002186
closesodoo/odoo#33028
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When an error is raised server-side, the complete traceback is displayed
in the JS console. This traceback can be very useful since it might
contain information not recorded anywhere else by default. For example,
access errors due to record rules or SQL constrains do not have their
traceback displayed in the UI or recorded in the log [1], but it is
logged in the JS console.
However, the information is logged in the JS console as a stringified
version of the `result.error` object. The final result is a long and
non-formatted string which is unreadable.
We replace by a new format more convenient for technical teams. The
error is now formatted as:
Error code
Error message
Error data message
Error data debug
This will hopefully give a better starting point for debugging purposes.
[1] SQL constrains tracebacks are only recorded in the log in debug
mode:
https://github.com/odoo/odoo/blob/ec792da72b92b22349b6f325e53fd37d953c7db3/odoo/service/model.py#L122closesodoo/odoo#33650
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Invisible fields in form view and group reserve space.
This looks bad with many invisible fields in a form.
Fixes: #29505 and #28370closesodoo/odoo#33598
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In an editable view when editing a row, then apply or remove any groupby or
filter the control panel buttons are not updated.
When record is in edit mode in editable listview and applying groupby then
control panel buttons 'Save' and 'Discard' buttons are always displaying, this
issue occurs because when applying or removing filters control panel buttons not
updated i.e. _updateButtons not called.
With this commit button are updated when _update of list controller is called,
_update of list controller is also called from search.
Task-1967278
closesodoo/odoo#33572
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
In 11.0 091c86c21 introduced the unselection of lines when line are
resequenced to solve some issue.
There seems to be a related issue in the following use case if:
- the one2many has a handle field
- the lines have same sequence (eg. adding 2 o2m lines on new record)
- there is an invalid o2m line (eg. empty line and required field)
- without blurring, a valid line is moved
then this happen:
- the sequence of lines are computed
- the invalid line is removed
- the computed sequence of lines are applied
=> this break next onchange, because we try to apply an onchange to data
that does not exist anymore (the invalid line).
With this changeset, the invalid lines are discarded before sequences
are computed so the computation is still correct before being applied.
Without the change, the added test fails with:
5. one onchange happens when lines are resequenced (expect: 3, res: 2)
7. one onchange happens when a line is added (expect: 4, res: 2)
8. onchange worked there is 2 lines (expect: 2, res: 1)
opw-1966589
closes#33591
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
toggle full width of calendar not working, this is because getItem of
localstorage service now returns parsed value, AbstractStorageService now
return JSON.parse(value)
this commit fixes that.
task-1975004
closesodoo/odoo#33570
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
For many2many_tags widget 'o_tag_color_0' class apply box shadow, in form
view it looks good but in kanban view, it does not look good so I have
removed box shadow from kanban view.
Before this commit in kanban view when no attributes are used in the field
at that time tags will be in box-shadow but after this commit even if no
attributes are used in the field, tags will be without box shadow.
Task ID: 1963188
Closes: #33503
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
backport of 12.0 535da9e (in pr #30239) since video loader was in 11.0
opw-1928512
closes#32983
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The calendar should send to server:
- for an all day event (all_day field on view): the date in UTC (ie. if
we are on 22 august 2018 on UTC+2, not send 21 august 2018 22:00)
- for a datetime event not all day: the UTC datetime corresponding to
UTC (for 03:25 with UTC+5 timezone, we send 22:25 the day before)
- for a date event: the date in UTC (ie. same as all day)
The current code was alright for datetime, but there was a missing case
if the start_date was a Date field (eg. project task calendar view uses
a date_deadline Date field) and not a Datetime field.
This changeset apply the same behavior as an all_day event to a calendar
with a start date that is a Date field.
Note: the issue happen since 11.0's 03d74f4 (26th march 2019) that
solved a similar case but for datetime (a datetime event at 8:00 with
timezone UTC+9 would be moved the previous day when drag and dropped on
the month view).
opw-1969876
opw-1971106
opw-1971019
closes#32796
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Following https://github.com/odoo/odoo/commit/ddf2d2dd666c6e3fa2b6b7f943575657a42d6d8b,
the card bodies received a background color.
The 'row' class should not be used on a 'card-body' element but if it is
done, our custom bg color would overflow the card. As a fix for those
cases (normally only one at the time this fix is made), remove the
background color.
opw-1946124
closesodoo/odoo#33710
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Install the 'Maintenance' app
- Create a maintenance request, set a day and a duration of 6 hours
- Go the calendar view, month mode
- Move the maintenance request from one day to another
The duration is changed with a non-sense value.
In month mode, the hours are not represented in the calendar so it is
not possible to compute the `date_delay`. Moreover, when a record is
moved from one date to another (`_onDropRecord`) in month mode, there is
actually no point recomputing the duration; the `date_start` is enough.
Note that `date_delay` is used (at the time of writing) in 2 views and
absolutely not tested.
opw-1984637
closesodoo/odoo#33193
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Following f4fbaf1efa
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closesodoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This rev. disables Popper.js 3d transformation for positioning
bootstrap dropdowns in navbar, as this transformation causes a
rendering issue on webkit-based browsers (the text in the dropdown
is blurry).
See https://github.com/twbs/bootstrap/issues/23590
Note that it has already been disabled for the other menu dropdowns
(user menu, debug menu) by rev. 5373db1.
Another solution would have been to override the default value in
our bootstrap.js extension file, but for dropdowns that aren't in
the navbar, the dynamic positionning could be interesting.
Fixes#33096closesodoo/odoo#33174
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Arabic customers are complaining the Lato font is very odd looking for
Arabic scripts. Furthermore, since #32312 Noto is used as the prefered
font to display arabic scripts.
The classes are used by the "Company Tagline" configured along with the
template in use in the general settings.
opw-1946109
closesodoo/odoo#33141
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Open a record with a chatter (ie an opw task), add an attachment, enable
debug mode and click on "Set Defaults" in the debug tools, traceback.
The `message_attachment_count` field is a special view added by the
chatter on the form view. This field exists on the view but is absent on
the list of field listed by the XML file. Setting a default value on
that special field is not supported.
opw-1972372
closesodoo/odoo#33044
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Fine tuning of 5ef86ef6c874ab4dc78402493d05b2460c69e7f6
Steps to reproduce:
Set a custom language settings for date by switching the %m and %d.
Create a sales order
Current behavior:
Invalid date error boxes was raised two times
fixes#33408
opw:1998971
closesodoo/odoo#33415
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Install discuss, change the general setting in dev mode to disable the
"Show Effect" checkbox. Change the preferences of the user to let odoo
handle notifications. Ask another user to ping you on a chatter then go
to discuss and click the "Mark as Read" button. Traceback.
The `notification_manager` agent has been replaced by another agent in
07cd24b1ec, the code has been updated to use the new agent.
opw-1986844
closesodoo/odoo#33363
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to reproduce the bug:
- Go to any field Date
- Enter wrong date
Bug:
A traceback was raised.
Now a warning is raised and the wrong value is removed.
opw:1974747
closesodoo/odoo#33362
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Backport of 7bc53ac30e.
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
closesodoo/odoo#32647
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Commit 42530b02fe was fixing a bug in reports that were using the standard
bootstrap fonts instead of the changes we made in $font-family-sans-serif
To solve this, 42530b02fe replicated the change in the file
web_editor/static/src/scss/bootstrap_overridden.scss
which is imported in report_assets_common **before** web._assets_bootstrap
This was solving the issue for the report but had also the side-effect of
changing body font-family in enterprise as the bootstrap_overridden.scss file
is also used in web_editor._assets_backend_helpers and
web_editor._assets_frontend_helpers
42530b02fe had effect only on enterprise where the desired font is Roboto/Noto
Create a new bootstrap_overridden (6th of the name) file only for report
closesodoo/odoo#32902
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, a domain that had been written in order to be
JSON parsable, would trigger a JS crash when activated in the UI
It happens when adding custom filters through the edition of the search view with studio
This was because, Odoo developers write, in the XML of a search view
domains python style: `[('field', '=', 'value')]`
When parsing the view in JS, this doesn't get altered by `xml_to_json`
Then, the search view code evaluates it python style
This commit considers that behavior fortunate, but not really clear or conceptually correct
But, when customizing a search view with studio, the domain is written by the code, in JS
JSON parsable format `[["field", "=", "value"]]`
This should be supported too, as so many customizations may have been done before hand
After this commit, both expressions are supported by the filters menu
OPW 1957297, 1960732, 1965649 (at least)
closesodoo/odoo#32690
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a timesheet uom per Day
Have a language with a different number format than English
Click on grid cell to change its value
Before this commit, the value was stuck on the highest value in range
This was because the parsing of the value into float was not taking into account
the real format of the float
After this commit, it works in all languages
OPW 1964657
closesodoo/odoo#32581
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The basic font-family offered on Odoo do not support a large set of characters
and rely on the system fonts for non-latin languages
On a system without specific fonts installed, the characters were replaced by �
For Hebrew, the system sans-serif font (at least on Windows pc) was too small.
Rely on the unicode-range range CSS descriptor to load a font only for a
specific range of unicode code.
https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-face/unicode-range
This way, the fonts are ignored for English text (and you don't have to load
the fonts of every possible language).
Add Noto fonts that covers many charsets.
There is an heavy version for many charset and lighter ones for Arabic and Hebrew
More ranges can be added later
Serve the fonts on our CDN to avoid shipping several MB of fonts for everyone
but lazyload it when needed.
Fixesodoo/odoo#32228Fixesodoo/odoo#21781
In an editable (main) list view with modifiers depending on the
record id, add a new record. While the record isn't created yet,
the modifiers were correctly evaluated. However, they weren't
re-evaluted when the record was saved (thus getting an id), and a
reload of the view was necessary for the modifiers to be correctly
applied. With this rev. they are now correctly re-evaluated when
the record is saved.
closesodoo/odoo#32483
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Before this rev., navigating with shift-tab didn't produce the
expected result when there were readonly fields on the way. For
instance, pressing shift-tab on a field:
- to the right of a readonly field: the focus was kept in the
current field, whereas it should have been moved to the first
editable field to the left of the readonly one
- in the editable first cell of a row, with a readonly field in
the last column: the focus was moved to the previous line,
which is ok, but on the first editable cell of it, whereas it
should have been on the last editable cell.
@KangOl this commit needs to be forwardported up to saas-12.2, not
later (the code slightly changed in saas-12.3, and we did another
version of the fix).
Since f4fbaf1efa the structure of checkboxes has been improved, now we
have something like:
```
<input type="checkbox" id="checkbox-18" class="custom-control-input">
<label for="checkbox-18" class="custom-control-label">​</label>
```
With the first input invisible (whilst before it was visible and the
clickable element).
This cause an issue in an editable list view:
- we have a boolean readonly field in a cell
- we are on focused on a line (not in the boolean field cell)
- we click on the boolean field
=> the check mark is toggled
This is because when we switch cell, we try to activate the widget of
the other cell. Before f4fbaf1efa this issue did not happen since the
browser do not generate a click event when clicking a disabled checkbox.
With this changeset, a disabled FieldBoolean is not focusable as is the
case for other fields, so we can't "activate" it.
Without the fix, the added test fails with:
[clicking disabled checkbox did not work]
opw-1958433
closes#32652
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- when refresh a kanban dashboard page which contains graph, there is some extra div appends to the graph.
- so if svg is there in the dom, no need to append it again. simply use the existing svg
Related to Issue: 1943483
closesodoo/odoo#32279
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
When a report with header is displayed in iframe with layout
"Background", part of the header maybe outside of the page.
For example on /my/invoices portal show of an invoice, the max width
report iframe can set at 210mm (+/- 793.7px normally), the header in
background layout has `min-width: 900px` so is wrongly centered and may
have content outside of shown page (eg. company tagline).
The same issue happen when using HTML rendering of the report in
backend, but depends on the viewport width.
This may be the expected configuration when printing (wkhtmltopdf should
unzoom if something was too large to fit) but not when displaying html
directly.
opw-1915807
closes#32373
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- This issue occurs after the upgrading latest bootstrap library
While there is an action with data-toggle="collapse" on anchor tag and also any parent function which returns false, it will prevent the click event from bubbling to parent elements.
Hence, It will not call the click event in bootstrap library, and configuration panel will not be removed unless you refresh the page
- so, removed return statement as no need to return anything from the event function.
Related to Issue: 1943483
Xavier Morel