Before this rev., there was a race condition when the user did
some changes on a form view (triggering an onchange), saved and
clicked on the breadcrumbs to leave the form view (before the
onchange returned). As a consequence, the dialog telling the user
that there are pending changes was displayed. This mostly occured
on the main_flow_tour since the removal of an unnecessary check,
and could be reproduced manually on a slow network.
Basically, the check if there were pending changes was done too
early (before the view was actually saved).
This rev. fixes a concurrency issue in the kanban view spotted by
the Project tour and the removal of the delay in the tour system.
Let's assume the following scenario in a kanban view grouped by a
many2one field with at least one column and with the quick create
feature enabled:
- quick create a new column
- before the column is actually created, click on CREATE in the
control panel to create a new record
Before this rev., the record quick create widget was opened
directly, but as soon as the column was created, the view was
re-rendered, and the quick create widget was lost.
This rev. forces the column to be created (and the view to be
re-rendered) before opening the record quick create.
Before this commit, if a user tries to group a kanban view by a date or
a datetime interval, then tries to drag and drop a record from one column to
another, then the web client crashes. This is actually an invalid
operation, and is supposed to be disallowed. There is already some code
that properly handle the situation. However, the field attribute was
not properly read in the case of fields of type date/datetime.
Related to Issue: #1911975
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#30029
The week_start has been added as an option since commit 27b30daea5.
This stores as a database parameter the day starting the week, [1.. 7] starting
on Monday, while the calendar options expect to get Sunday as 7 % 7 = 0.
As a result the week number would be shifted.
Commit c72403d2ba solved the issue,
this commit adds tests for it.
opw 1916666
closesodoo/odoo#29838
On a form view of model A, if a many2one field (model B) has a [tree|form]_view_ref in the context
(to display a custom 'Search More...' tree view dialog for example),
when clicking on this field to display the model B form view, the context key *_view_ref is passed
when loading subviews (model C) making them crash because the view ref corresponds to the model B.
After this commit, '*_view_ref' keys in the context are dropped when loading subviews
closesodoo/odoo#29022
While dragging kanban record which have a cover image set, the kanban view
creates extra space, which makes it difficult to properly target a
position.
This is because of a jquery.ui issue for sortable when helper=clone is used.
In that case, then jquery.ui sortable will create a clone of current element
after hiding it. Note that jquery.ui tries to get height to current dragged
element after making it hidden(display: none) and display: none, so the element
does not return actual height and hence it gives innerHeight which considers
height of the image also and extra space is generated.
An alternative solution is to add start event in sortable option and
1) show ui.item
2) get height of the element and
3) hide ui.item, which gives proper height of the current dragged element
But removing helper=clone will also fix the issue and is not actually required.
Note that some special care had to be done to prevent the click from the
drag and drop operation to actually open the record.
Related to task: #1865788Closes: #25734closesodoo/odoo#29642
Before this commit, it was not possible to sort
the rows of a pivot view while in comparison
mode. This fix makes it now possible. Note that
in comparison mode, a click on a header of type
"measure" will sort the rows according to the
column values coming from the data of interest.
closesodoo/odoo#28411
Support for string attribute on fields in pivot view was added in 24f7c7ce7f
In some cases, the field is not stored and read_group method is
overridden to allow its use in a pivot view. Such a field does not
appear in the measures dict trying to set the string attribute, leading
to a client crash.
With this commit, the string attribute is set after the non stored
fields were added to the dict.
closesodoo/odoo#29393
Before this commit:
While user was opening first time line chart graph, at that time undefined
label values were not being converted into undefined string due to misplace
code. So it was giving traceback error
After this commit:
Code has been moved to proper place.
Joint work with msh-odoo
Issue-ID: 1882328
closesodoo/odoo#29306
The pivot view may sum fields that are not really summable:
unsigned values (e.g. in the case of refunds)
values in different UOM, currencies (any different units really)
Which causes confusion when these fields are displayed.
We add support for the string and invisible attributes in the pivot view,
so that a field can be given a more informative name or hidden altogether.
opw 1909046
closesodoo/odoo#29144
related to: #28446
On a pure list view, click on a column to sort the records by that field.
Save the filter as favorite
Reload, now apply the filter
Before this commit, there were two issues:
1. The order of the list was never propagated to search view, which couldn't save
the filter with its attribute "sort"
2. There was no mechanism to load the attribute sort from a loading Filter
After this commit, those two issues are corrected
Unfortunately, complex search view flows are not testable in v11.0
OPW 1906968
closesodoo/odoo#28766
Before this rev., the following scenario didn't work:
Open manufacturing order and click on Produce button (note that
bom product should have Serial number enabled) then add quantity
in Done field in o2m and press Record Production button in wizard,
it will produce UserError and after then if you change Lot number
field in wizard's o2m then the many2one value doesn't get selected.
This occured because the renderer wasn't updated after the RPC fail
and thus still got an outdated version of the state.
The issue raised after commit: 02eef78bbd which was done to remove
useless rpc call, it's OK to remove rpc call but let's keep
updating renderer.
Related to task ID: #1852715
Co-authored-by: Tejas Shahu <tsh@odoo.com>
On a form view (of model A), define a many2one (model B) with a [form|tree]_view_ref context key
In that view, have a x2m field (model C) with a different [form|tree]_view_ref context key
Before this commit, the second load_views (i.e. on the model C) crashed because
the wrong context key was sent to the server, which returned the view to which the _view_ref points
i.e. the view of the model B
After this commit, we clean the context of subviews loading, because those keys are only useful for the python
and one shot. Hence, there is no crash
OPW 1903780
closesodoo/odoo#28260
When creating a SO line and clicking on search more for product_id
Before this commit, every user had the button "Create" to create a product.product
After this commit, only user in groups that actually can create a product have the button
OPW 1910371
closesodoo/odoo#28924
When creating a record in a grouped kanban view, it tries to add
the record to the first column but if no column exist, it fails
to find the first one and raise an exception.
This PR correct that bevahior by checking it exists a column and
fallback to the view form when it does not.
opw-1902851
closesodoo/odoo#28262
Rev. 42e1efded5 aimed to disable the quick create feature when
grouped by date(time) fields, by only enabling it for char, boolean
and many2one fields. However, the selection case is quite important
and must be handled as well. This is what this rev. does.
Task 1878254
When a kanban view is grouped by a char or a boolean field, and the
quick create option is enabled, the correct default value for the
grouped field (i.e. the value of the column in which the record is
created) should be given (either in the context if that field isn't
in the quick create form view, or as a default value in that form
view otherwise).
Before this rev., it wasn't the case, as it was only working when
grouped by a many2one field.
Task 1878254
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
In Firefox, the input behavior and visual representation (navigation, caret
placement, value selection, etc.) was broken when using a datepicker (easily
reproductible on date and datetime widgets).
This was due to the `focus` event being stopped on the input, which doesn't
seem to be correctly supported by Firefox.
The deleted code was supposed to toggle the picker when the field was clicked
(see odoo/odoo@89093a1) (toggle on click and disable focus) but the lib
correctly supports on focus without extra code.
This also fixes the fact that the datepicker was not open on focus (only on
clicked). In some tests where the field was the first in the form view, it is
now correctly autofocused.
Forward-port: not useful from 12.0 because the code has changed with BS4 and
this has already been applied in odoo/odoo@6692919 and odoo/odoo@c63630d.
Closes#23438closesodoo/odoo#27657
Before this commit, when clicking on a link in a kanban
record having `href` that is set, it was opening the record
and accessing the `href`.
The intended behaviour is to not open a record if any children
component of the record contains either a click event or is
a link with `href`. The former was correctly handled, but not
the latter.
This commit fixes the issue by preventing opening the record
when clicking on a inner link with href from a kanban record.
Closes#24664closesodoo/odoo#27529
Commit:
https://github.com/odoo/odoo/commit/818c18e55d0718286ff5bf332186a10f4d7a58ef
Updated the resequence logic in a way that was almost falser than before.
The added test however did work by coincidence, as index values were equal to
the sequence field values.
To be sure that we synchronize with what happens on the server, we do a read
after the resequence.
Additionnally, we take into account the result of the server resequence return;
if it is false, it means no resequencing happened, so we should not do a read.
opw 1867049
closesodoo/odoo#27184
Have a many2one, click on search more
Open the filter menu of the search view
Add custom filter
Click to select a field
Before this commit, the whole dropdown closed
After this commit, it doesn't
OPW 1911337
closesodoo/odoo#28969
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we don't convert the moment into a Date,
and we directly format that moment into a string
OPW 1903224
closesodoo/odoo#28689
The progressbar widget is not supposed to be displayed in non grouped
mode. Before this commit, this situation resulted in a traceback. For
example, if the user has an activity on the subscription model, and
tries to open it, it will open an ungrouped kanban view.
With this commit, we check first that the kanban view is in grouped
mode, before loading the progress bar data.
Some tests were skipped these last months. This is a slippery slope.
The best time to reactivate them is the moment they were skipped, the
next best time to reactivate them is now. So, this is what this commit
does.
Three kinds of tests were skipped:
- 3 password tests
- 2 kanban progress bar tests
- one keyboard navigation test
Password tests
--------------
When the auth_password_policy addon was introduced, two tests in web/
were skipped, because they would fail when the auth_password_policy
addon is installed.
Since then, a commit was done to change the way the password field works
(commit 5bbbd25edf). With this commit,
the password field is no longer an 'include', but a new field widget.
This means that the skipped tests no longer fails.
Kanban progress bar tests:
--------------------------
In saas 11.2, the 'archive all' feature was removed, but it was readded
in saas 11.4. The tests had to be slightly adapted to make sure they
use the proper css selectors.
Keyboard navigation test:
-------------------------
It is now a functional decision not to allow moving from one cell to the
next by using left/right arrow, so this test is no longer valid.
closesodoo/odoo#28685
This commit fixes two tests that became meaningless after tweaks
in production code:
- form_tests: use two char fields, as integer fields can't be
unset since rev. c62a4edcb
- pivot_tests: the button is disabled since rev. 4f4f111, but
simulating a click with jQuery bypasses the disabled attribute
This commit also removes unecessary overrides of mockRPC. Those
overrides existed because the attachments part of the sidebar
used to make a search_read RPC, but this has been removed at rev.
1dbb555.
closesodoo/odoo#28650
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
Before this commit, we tried to hide some labels depending
of the available size of the graph.
However, it doesn't worked when the graph is updated.
A much simpler solution is to use the scale’s automatic tick
generator implemented in D3.
So, in this commit, we realized that 'tickValues' is unnecessary
because data are passed correctly (see 'svg.datum(data);') and
labels are defined in 'ticksLabels'. There is nothing else to do.
We had to remove the skipped test because 'renderEnd' is not triggered
for line chart. We need to update nv.d3.
We already tried to fix this issue in the following commit:
https://github.com/odoo-dev/odoo/commit/c4937132a38873761fa0ac0b41c983b917cb52f1
Documentation:
https://github.com/d3/d3-axis#axis_tickValuesclosesodoo/odoo#27828
Reason: This feature currently has unfixed bugs, does an unnecessary RPC and
was functionally replaced by a button inside the chatter in commit
7f97c9f and the menu inside the debug manager in commit d12b88315.
This commit disables the JS part of the document module to prepare
for the complete removal of the whole module and the MOV of
the indexation to base.
Closes#27613
* generic strenght meter widget which can be included in various
places
* password field, taking over the isPassword special cases strewn
throughout the codebase, this should probably become an actual thing
in core /cc @ged-odoo, the meter is opt-in as most uses of
`field[@password=True]` are passwords & secrets for third-party
services or external servers for which a meter would not make sense
* separate override of the ChangePassword wizard which isn't a regular
view for some reason
* direct implementation for signup pages (create user & reset password)
Skip/comment/remove existing testing of @password fields: the policy
replacement/augmentation needs to make an RPC call and does not
support readonly use (because it doesn't seem to be used anywhere so
that made sense?); and there currently is no way to augment or
override/replace existing tests, so the tests will either fail when
auth_password_policy is installed (current situation) or fail when
auth_password_policy is not installed (if updated to be compatible
with APP).
In comparison mode with no data, we render two empty pie charts even
if it's not an embedded view.
The non content helper is still used when there is no comparison.
Aaron Bohy