Before this commit, only the routes which began by '/web/image' were
mocked (simply ignored). This forgot the case were it is a full URL
(http://www.test.com/web/image). Now, also mock the static images
routes (for .png and .jpg).
This rev. fixes several issues with the sorting of dataPoints of
type list in the BasicModel.
First, only 'static' lists (i.e. x2many lists) must be sorted
client-side, and results of search_read RPCs must remain unsorted
as they are already retrieved sorted from the server.
Second, editable and non-editable x2many lists don't behave the
same with respect to sorting (we reproduced in this commit the
behavior of saas-15). With editable lists, the edited rows are
unsorted, except if the user explicitely ask for a sort (by
clicking on a column header), until the form view is saved. With
non-editable lists (as for x2many kanban), the sort is performed
directly when a record is created or updated (as the edition is
done from a dialog).
This commit adds a feature to the widget Many2ManyTags for kanban
views. When a tag is clicked, records are filtered on the given
tag, in addition to the active filters in the search view.
When an onchange modifies an x2many field, the line on which the user
works remains in editable mode and the cursor is returned to the same
position.
The second argument of create command is a reference used to reactivate
the edited line.
Prevents false positive error in tests.
Issue: If an error occurs that the view remains visible, then other tests that use a pointer or focus can not be performed. Errors occur because the new views are introduced afterwards and are therefore not always visible.
The problem occurred on form views with an x2many field with a
default value containing CREATE commands, i.e. when opening such
a form view in create mode, the x2many field is pre-filled with
some (non-existing yet) subrecords.
If the user then edited those subrecords, and then clicked on
'Save' to create the main record, an 'UPDATE' command was sent
alongside the 'CREATE' one for the x2many, and the id of the
'UPDATE' command was a virtual id (as the subrecord didn't exist
yet), and it crashed.
This could happen in MRP:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- click on Produce: the many2many already contains a subrecord
- edit the lot field of that subrecord
- click on 'Record Production'
When the external button of a many2one field is clicked, the
related record is opened in a dialog. When the user clicks on
'Save' in this dialog, a 'reload' event is triggered to reload the
parent view (the one in the background), as the display name might
have changed.
However, when there is another many2one field in the opened dialog,
and if its external button is clicked, there are 2 opened dialogs,
and thus 3 nested form views. If the user clicks on 'Save' in the
third one, only the direct parent view must be reloaded (the one
in the first dialog).
Before this rev., the 'reload' event wasn't stopPropagated, so it
was handled by the view in the dialog, and by the one in the
background, which produced a crash.
This could happen for instance in Sales Order, edit a sale order
line, click on the external button of the product, in the dialog,
click on the external button of the category, edit some field and
click on 'Save'.
Closes#19052
Before this rev., when the user pressed 'TAB' in the last cell of
the last row of an editable list with attribute create="0", a new
line was added to the list, thus totally ignoring the attribute.
Now, it goes back to the first cell of the first row instead, as it
was before the new views.
Closes#19053
Before this rev., when the value of a field with widget='domain'
was false, the search_count RPC made to display the number of
records matching the domain crashed, and the widget displayed that
the domain was invalid. This rev. adds a fallback on [] when the
domain is false.
In grouped list view, when a pager is clicked inside a group, a
'load' event is triggered to reload the data with the new offset.
The event is handled by the list's controller.
However, when the list is in the modal, the event must be stop
propagated by the controller of the modal, so that it doesn't go
up to the controller of the view displayed behind the modal. It
happens for example by reproducing the following steps:
- go to Lunch
- add a line
- search more products
- group by vendor in the modal
- unfold a group
- click on the pager (the group must contain more than 80 records)
Before this rev., it crashed because the controller of the form
view tried to handle the event.
Before this commit, a list containing a handle widget would only display
the handles associated with non-zero integer values. This is due to the
fact that unset fields are hidden in Odoo, while a field is by default
considered 'defined' if its value is truthy.
We override the isSet method for the handle widget to always return
true. This tells the handle widget that the associated integer value is
always defined, thereby ensuring that the handle will always be shown.
The field 'display_name' is automatically added to the list of
fields to fetch when fetching a record. Before this rev., its
value was also sent alongside the fields in the view for onchange
RPCs. It shouldn't: only the fields in the view should be sent.
It produced a weird bug in the res.partner form view: open a
contact (company), add a sub-contact, save -> the display_name of
the contact was then '' (and 'Contacts' was displayed in the
breadcrumbs instead of the display_name of the opened contact).
This is because 'display_name' was sent to the onchange, which
returned '' as value (because of another bug python side). So as
it's value changed, when saving, the new display_name was sent to
the server (even if this field was actually readonly).
Before this rev., we also always fetched 'display_name' when
fetching list of records (read or search_read). This wasn't a bug
per se, but it might be a computed field, and it isn't necessary,
so we stop fetching it in that case if it isn't in the view (as
it was done in saas-15, before the new views).
We added 2 colors to the custom colors scheme for tags and cards' colors
but we did not adapt the possibility to set them properly in kanban.
Also adapt the related test.
This option has been removed with the new views but was used in barcode.
The form renderer was also dealing with some part of the autofocus
but this should only be handled by the controller.
The logic is now only in the controller and a test case has been added.
Since the new views, most of the barcodes feature was
broken. This commit re-enables the support of commands like
'edit', 'save', 'cancel', 'previous' and 'next'.
Also changed javascript event handler to jquery event handler to
make barcodes testable in phantomjs.
Before this commit, it could happen that a x2many field was considered
invalid, which prevent triggering onchanges, even though each of its
required fields are properly set. Here is such a scenario:
We have a one2many field something_ids in a form view, with an inline
tree view, which contains a field X. The field X is required on the
model, but marked required="0" in the inline view.
In that case, we incorrectly evaluated the required modifiers: since the
attrs did not contain the required attribute, we fell back on the
field_get value, which is true in this case. But this is not correct,
the fieldviewget already computed the actual modifiers and took into
account the fact that it was overridden. We need to only look at the
modifiers.
Before this rev., the button box wasn't displayed on new (not saved
yet) records. This wasn't the case before the new views.
This is a problem in lunch, as the lunch.order form view is opened
in create mode, and the balance is displayed in the button box.
Before this rev., keys like pivot_measures, graph_mode..., were
correctly took into account at first load of Pivot or Graph view,
but not at reload.
Those keys are particularily useful when a user saves a research
to its favorites. When such a favorite is selected, the view is
reloaded and the interesting information is in the context.
The former implementation of the Pivot view used __count__ as
magic field to display the number of records in groups. However,
in filters defined in xml, __count is used instead of __count__,
so it crashed when such filters were activated.
With the new views, we made those filters work by using __count.
However, if a user saved filters using __count__ at that time as
favorite, activating them in the new views produces a crash as
well.
This rev. adds a compatibility layer to ensure that the pivot
view handles both __count__ and __count measures uniformly.
The reference widget is also meant to be used on a char field, not only on a
reference field.
The rev. https://github.com/odoo/odoo/commit/a4e30a1b43d0b9acd76508d9e6c466cd1dbdffab removed
the use of `field_utils.format.many2one` and replaced it by `_formatValue` to
support this use case.
The replacement wasn't complete as some occurences was remaining (in reset),
which led to traceback when the widget was reset (impossible to create an
External Identifier anymore).
Also, the reference `_formatValue` wasn't correct as it was displaying the
record `display_name` and not the reference field value ; this only makes sense
for the External Identifier as its display name is the reference field value but
it doesn't make any sense for other reference field.
Last but not least, this commit implements the `onchange` and `default_get` for
the reference field.
- When you move an all day event to a scheduled event,
the default duration should be 2 hours instead of 1 hour.
- Before this fix, it was not possible to drop an event
to an all day event
- In week mode, an all day event was displayed over two days.
This commit adds an 'Edit' button to the record quick create in
grouped Kanban views. When this button is clicked, a name_create
RPC is performed and the created record is directly opened in a
form view in edit mode.
In general (e.g. read, search_read), values for many2one fields are pairs
[id, display_name]. The default_get is an exception, it only returns the id,
so we need to manually perform a name_get afterwards. In the case of
list views, those name_get RPCs are batched.
Before this rev., the code in charge of it didn't handle the case where the
many2one value was false, so it crashed when it happened.
This rev. deals with this use case and a test case has been added.
Before this rev., the events in Calendar views (month mode) weren't
correctly displayed: the last day of the event wasn't displayed as
being part of the event. For instance, in leaves, a leave of 3 days
from the 16th of Augustus until the 18th was only displayed over
the 16th and the 17th.
Moreover, when an event was created from a Calendar view with
option all_day=False, the default start and end dates weren't
correctly computed according to the user timezone, which could lead
to the creation of multiple days event whereas the user clicked on
a specific day. For instance, with timezone GMT+2, when clicking on
the 18th of Augustus in the Leave Calendar view (month mode), it
opened a dialog for the creation of a 2-day leave from the 18th to
the 19th.
This rev. fixes those two issues.
With the new views, we stopped using the browser timezone to
display the dates in Odoo, and we used the timezone defined on
the User profile instead. When loading the webclient, the
timezone offset was put into the session and used to display all
dates. This wasn't a good idea.
The given offset was computed for the current time, meaning that
it may be incorrect for specific dates (e.g. with the daylight
saving, the UTC offset of today is not the same as 6 months ago).
Moreover (but less likely), as the offset was stored in the
session, it wasn't recalculated afterwards. So if the offset
actually changed during the session (e.g. from or to daylight
saving time), the displayed dates were incorrect until the user
reloaded the page.
With this rev., we don't retrieve the offset from the server
anymore and we use the browser timezone again (like before the new
views). However, we keep the computation of the offset (on the fly)
in the session, so that it can be mocked in the test environment.
Before this rev., all date fields values were off by one day as
soon as the user timezone was negative.
With the new views, all dates manipulated by the JS are moment
instances in UTC, and when being displayed, they are correctly
formatted in the user locale by applying the timezone offset.
However, this should obviously not be done for date fields as
when no time is specified when creating a moment instance, it
defaults to 00:00:00, so applying a negative offset always leads
to the day before.
Remark:
It happens that datetime fields are displayed as a date (e.g.
purchase order line form view). In that case, the offset is
applied on the displayed date.
As its name indicates, the SelectCreateDialog is meant to select and create,
not edit.
If the view is editable, clicking on an element will edit it instead of
selecting it. For this reason, the view is set in `readonly` even if the view
arch uses the attribute `editable`.
Before this rev., you couldn't select a "Close Reason" when closing a
subscription (in "Search More").
Since rev. https://github.com/odoo/odoo/commit/ebd17217c4e7e9ff06d97028de64fb2fc44d6266
the attribute `_editionViewType` has been introduced to use the modifiers from the correct
one2many view type.
This attribute wasn't correctly populated if multiple one2manys were imbricated. The
first view type (form in the test case) was set for the second one2many even though
the view type was list. This was due to the `visitChildren` function use that browses
through all levels (and not only the first one).
To reproduce the bug before this rev. you could try to create a new survey, add a
question (one2many) then select multiple choice and add an answer (one2many editable).
In grouped Kanban views, the list of res_ids of the displayed
records may change for several reasons:
1) 'Load more' is clicked for a column
2) a record is moved from a column to another
3) a record is moved inside a column (resequence)
4) a column is moved
5) a column is (un)archived
6) a column is (un)folded
7) a record is created/destroyed directly from the Kanban.
When this happens, the environment must be notified of the new
list of res_ids (the order matters). Before this rev., this wasn't
the case. As a consequence, when a record was opened in a Form view
after one of the 5 operations above, the pager could display
unexpected values.
Note that before the new views, cases 2, 3 and 4 weren't handled,
and case 7 already worked before this commit.
The problem occured when opening a record from a grouped list or
kanban view. In the opened form view, the pager was sometimes
incorrect. This was because the list of ids wasn't correctly
updated when groups were opened/folded.
Before this commit, it was not possible to copy the contents of a
multiline text field in read-only mode in Firefox without losing all
line breaks in the process. This is due to a bug affecting div tags
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1390115) in Firefox.
This commit ensures that the text in a text field is surrounded by a
span (as opposed to div) tag.
Note that spans were used in saas-15, so we are in fact simply undoing
the change to divs introduced by the new views.
As mentioned in
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49,
a resize after the first render is necessary to prevent overflow issues
with fullCalendar. As changing the date would rerender the calendar, we
also need to trigger a resize then.
From this revision onwards, a resize event is triggered every time the
calendar has finished rendering its events.
Unfortunately, I was not able to write a meaningful and successful test
(I encountered PhantomJS-specific issues). I also removed the test for
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49
because it always passed regardless of whether the fix is applied.
The traceback was caused by an occurence of this.dataset, which was left
out in the new views refactoring (this.dataset has been replaced by
this.record).
Sometimes, a default_get returns a create command for a one2many,
with a dict of values containing value 'false' for a many2one. This
is strictly equivalent to the case where the many2one field isn't
in the dict of values, but we have to handle both cases, and before
this rev., we only handled the latter one.
This happens for example in Sales > Leads (must be activated in the
Settings) > in the list view, check several leads > in 'Action',
click on 'Forward to Partner' > crash.
The value for one2many fields returned by default_get may be a
list of commands, or directly a list of ids. These cases were
correctly handled. However, it seems that the value can also be
false, and when this happened, it crashed. For instance, go to
Sales > Leads (must be activated in the Settings) > in the list
view, check several leads > in 'Action', click on 'Convert to
Opportunities' > crash.
Let's assume the following situation: we have a one2many field
displayed as a list in a form view. The list isn't editable, so
when a subrecord is clicked, it is opened in a form view in a
dialog. In this form view, there is a relational field X that is
not in the list. In the main form view, there is a field with an
onchange. When its value changes, the onchange returns a new
value for the one2many: a command 5 (delete all), and a command 0
(create) with a dict of values containing a value for X. However,
as X is unknown as long as no subrecord has been open in the dialog,
the value for X can't be processed (we don't know the type of X,
so we don't know how to process the value).
Before this rev., when this happened, we discarded the value of X.
This caused an issue for example in the Quotation form view (with
website_quote installed):
- create a new Quotation
- set PartnerShip Contract as quotation template -> the onchange
returns two 'create' commands for the order_line one2many
- click on one of the two subrecords in the one2many -> error.
This rev. ensures to keep changes on unknown fields. We keep them
unprocessed, and once the form view is opened, we process and
apply them.
qsm-odoo