When there is no handle field, there was an unnecessary margin-left. When there was a handle field, the margin-left wasn't the correct way to align it.
PR: #26566
Task: 1869469
* mail, calendar
- Fix traceback when clicking on a tag without color field (introduced
in recent changes)
- Properly allow to delete tags on firefox (a button obviously cannot
contain another button)
Closes https://github.com/odoo/odoo/pull/26547
Thanks to @hbh-odoo
doc:
* fix incorrect doc comments (documenting params which don't exist)
* correctly quote non-refs
* fix role label syntax (backticks must be escaped)
* add newline to fix warning
JS doc parser:
* fix handling of already-resolved objects
* fix handling of non-string properties (e.g. foo[0] at module toplevel)
* don't blow up if subject of .include call can't be resolved (just ignore)
Others:
* add translator support for ``problematic`` node (apparently used for
some refs by recent Sphinx)
Before this commit, when we applied two or more groupbys in line
graph, the groups displayed on the X axis where shifted to the left,
and the first one wasn't displayed at all.
related task: #1848289Closes: #25037
Let x_1, ..., x_a, x_{a+1}, ..., x_{a+k}, x_{a+k+1}, ..., x_{n} be a record
sequence ordered by its 'sequence' field.
Suppose the reordering occurs between elements x_{a+k} and x_{a+1}.
If the subsequence x_1, ..., x_a is ordered, then it does not change.
This is also true of the subsequence x_{a+k+1}, ..., x_{n}.
The resquence function makes exactly this assumption, and only sends the server
the subsequence x_{a+1}, ..., x_{a+k} to update its 'sequence' field.
The update of x is done as follows: it is index + offset, where index is the
position of x in the subsequence, and offset is the 'sequence' of the first
element of the sequence (i.e. x_{a+1}.sequence).
It is easy to see that we need another hypothesis: that the sequence numbers are
unique. To show it, suppose that the sequence of x_1, ..., x_a is 0, then all
x_{a+1}, ..., x_{a+k} have sequence 1, and lastly all x_{a+k}, x_{a+k+1}, ...,
x_{n} have sequence 2. Then after the call to the server resequence, the
subsequence x_{a+1}, ..., x_{a+k} would have sequence numbers 1, 2,..., k.
Since the x_{a+k+1}, ..., x_{n} subsequence have 'sequence' value 1, this would
obviously be incorrect.
We fix the reordering of the data in the js frontend to be consistent with
what is done by the server.
Note that this is only pertinent for sequences of reordering moves, since
otherwise the data comes directly from the server.
opw 1867049
Since in hr_timesheet, we are binding 'timesheet_uom' widget
on existing one (and it might change according to the session
info), we came to the case a formatType is different from the
one of the widget in the registry. Then, the AbstractField
fallbacks on the field type as formatter. Example;
timesheet_uom widget is blind on float_time, but their keys
are differents in field registry, so the formatter will be
'float' and not 'float_time'.
This commit override the formatType determined by the
AbstractField for the float_time widget.
Related to the bug: 1874270
Purpose
=======
Keyboard shortcuts working on BlockUI and can cause some issues when used.
Specification
=============
It should not work and should not be display while some process is being executed.
- add function to remove the "accesskey" attributes to avoid the use of the
access keys while the blockUI is enable.
- add function to reset the "accesskey" attributes when the blockUI is disable.
- add condition to avoid the "Alt" key to reattribute access keys.
Rev. 241704536d highlighted a bug in the Kanban RecordQuickCreate
widget, when a form view is used inside the widget.
Let's assume a quick create form view with a char field. The user
fill in this field and press 'ENTER' (without focusing out). The
record is about to be created. But first, we have to ask all fields
to commit their value (through 'commitChanges'), in case they
wouldn't have yet. The char field thus notifies its parents of its
new value at that moment. The form controller handles this request
in its '_applyChanges' function, but this is done in its mutex (to
prevent overlapping onchange RPCs). Unfortunately, this leads to a
deadlock as the quick create form controller already executed the
'commitChanges' request in this mutex.
Actually, there is no need for the quick create form controller to
execute the 'commitChanges' request in the mutex, as it is already
properly mutexified upstream. This rev. thus remove the use of the
mutex at that spot.
Note that before rev. 241704536d, the bug didn't occur because the
'commitChanges' function of InputField didn't return a deferred,
and thus the mutex was unlocked directly.
To be complete, let us mention that there are still some
concurrency issues with the quick create widget (like multiple
records creation on double clicks or double 'ENTER' keypress).
Those issues will be tackled in a future commit.
Task 1878977
Before this fix, the list grouped did not render correctly when
the list was not selectable and there was 1 or 2 fields (the sum in the
footer was not aligned on the correct column)
Also fixed the fact that the group pager was not displayed if the list
had only 1 field and it was grouped
The odooBounce (previously openerpBounce) function has been fixed many
times over the years. Each time breaking the layout a different way
after the backend was redesigned.
It is time for the proper fix: no more JS animation relying on jQuery,
instead: a CSS animation. Let's try a bouncing outline instead of a
bouncing button for a change.
The following line is necessary to prevent the scrollbar to appear on the textarea on Firefox when adding a new line if the current line has just enough characters to completely fill the line.
This fix should be fine since we compute the height depending on the content, there should never be an overflow.
TODO ideally understand why and fix this another way if possible.
Task: none
PR: none
-Some tests where moved without addapting the path to them:
path is now update and tests fixed.
-A picture was removed in commit 4dce6cc98b but
still referenced in template website_twitter_snippet.
-A test was missing a data leading to the wrong path to image beeing loaded
Since we correctly compute the height of the field, we don't want to let the user resize it vertically.
This was already working on Firefox because it doesn't require the field to be in the DOM to read the resize attribute, but Chrome does require the field to already be in DOM.
Task: 1869469
PR: #26518
Before this commit, a textarea inside a one2many would only have the correct size after focus or on change.
When we select a line, we want all of the textarea of the line to have the correct size even if they are not directly focused.
Task: 1869469
PR: #26430
Before this commit, a textarea would not resize when its value changed if the event was different than "input" or "focus".
This commit fixes it by also listening to the "change" event, and by triggering it at appropriate times.
PR: #26430
Task: 1869469
The box-sizing property was not correctly taken into account.
- content-box is the standard behavior: border and padding are added after the height
- border-box needs attention: border and padding must be included into the computed height
Task: 1869469
PR: #26430
In a one2many, pressing ENTER or TAB from a required input (of type text or char) that is on the last editable column of its line would fail to navigate to next line.
The issue was that the validation of the required field would happen before the change to its value was actually applied.
This commit fixes it.
PR: #26430
Task: 1869469
The pdf_viewer widget has been moved from mrp to web in rev. odoo/odoo@a7b521f
but the corresponding style was still in the mrp module. It's now put in the
right place.
Closes#26449
- tab not showing: fade animation was causing the issue.
- redirection to home: button instead of anchor to avoid
redirection to target href
Task #1878160
This rev. allows to navigate, in mobile, through records in form
views by swiping.
We also moved mobile-specific tests involving a form view to the
mobile test suite, since those tests became async because of the
lazy loading of the swipe lib (in the mobile suite, that lib is
already loaded).
Related to task #34727
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Before this commit, we had two different errors when data was
unavailable:
The first one is generated by Odoo: "No data to display, try to[...]"
The second one is generated by nvd3: "No Data Available".
We always want the same message.
So now, we always make some checks before rendering
the graph by calling _render.
Before this commit, a crash occured when you tried to load
a bar chart without any data.
Example in Purchase -> Reporting.
Since this commit 3d2ca810, we do some data processing without
checking if data exists.
To fix this, we have to always makes some checks before rendering
the graph by calling _render.
Currently, to remove link of x2m field from any record, sometimes there's no way.
For example, if we are on mobile and open any Quotation, it's linked quotation lines
are automatically converted in kanban, and there is no way to delete a line from
that quotation. However, in some of the manually designed kanban, there is special 'x'
for removing / unlinking x2m record, for example, Contacts of Partner.
This commit makes the behavior more consistent. During edition (mobile and desktop), if
a view dialog is opened on click of x2m field, it will have one 'Remove' button (based
on user rights) on right side of dialog footer, allowing users to delete / unlink the
record. Moreover, in mobile, the modal is opened fullscreen, with sticky header and
footer.
Related Task# : 31641
Closes PR #15857
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Before this commit, `testUtils.unpatch` was incorrectly
unpatching a class' properties.
That is caused by restoring the properties on the class
function itself, instead of the prototype of the class
function.
This commit fixes this issue by restoring properties on the
prototype function of the class on `testUtils.unpatch`.
You:
- open a grouping in a list view
- check a line of this grouping
- open another grouping
=> all checkbox are unchecked
With this commit, 0982ceaa is improved so the selection is only reset
when the list has been reloaded.
opw-1865736
closes#26213
Hiral Bhavsar