The `upgrade_boolean` widget should display an `Enterprise` label next to it.
There is however an issue when a `label` is specified for this field. In this case,
the `Enterprise` label should be placed next to the field label (and not the field
itself).
The easiest solution would have been to instantiate the field widget with its label,
but this can't work because the field widget is instantiated before its label.
We thus re-render the widget after its label creation.
KanbanColumn instances are saved in an array in the renderer. The quick
create widget is always put in the first column found in this array.
Unfortunately, the array elements' order was broken after some
operations where column(s) are rerendered (like moving records).
The server postproccess the view to add attributes on many2one fields, i.e.
`can_create` and `can_write`, according to access rights.
These attributes are parsed by the client as string but should also be parsed by
the many2one when evaluating them.
The mock server has also been adapted to set these attributes.
Move a record from one column to another in a kanban grouped by a selection field
leads to a traceback.
A selection field value is composed of a tuple ('value', 'String') and the write
command must send the `value` and not the `String` as it was done before this rev.
Clicking on a cell that contains a button (but not ON the button) leads to
a traceback (see "Scrap" button in Stock Operation for example).
This is due to the fact that a button is not registered as a widget so it can't
be activated.
This commit ensures that the next line is selected if the last column is a
buttton.
When selecting a partner in the reconciliation widget, using the SelectCreateDialog
(Search More), the partner wasn't correctly displayed.
This was due to a difference between the change format of the many2one ; when using
the dialog, only the `id` is sent (while the `id` and `display_name` are sent when
using the many2one dropdown).
These two behaviours are now standardized and both now send `id` and `display_name`.
It has the advantage of sparing some `name_get`s called by the model because the
`display_name` was missing.
This change implies some refactoring where the SelectCreateDialog was used.
Before this commit, the xml attributes defined with 'context.get(key)' in the
subviews not inline were not evaluated correctly. This was caused
by the loss of the one context in the '_loadSubviews' method.
This commit fixes this issue and modifies the mockserver in order to be able
to use the parameter 'viewOptions.context'.
Before this commit, when an event had only a date, the event
was set to midnight.
This commit sets the event as all day event if the field used as start date
is only a date and not a datetime.
Before this rev., it was not possible to move a record (in the same column)
at the top and then move another record above it.
There is special class `o_updating` added on record being edited to avoid
moving them. This class is normally removed afterwards when re-rendering the
record.
When resequencing, the record is re-rendered so the class won't be removed ;
this is why it shouldn't be added in the first place (same behaviour as saas-15).
The server response to an `onchange` on a one2many is a list of
commands. In case of one2many update (command 1), the server
returns all fields (and not only the modified ones).
When saving the record, this is the client responsability to
specify which fields really changed.
Before this commit, all fields were sent at `write` and not only
the changed ones. This was causing issues when the user couldn't
write on the field ; an error was triggered even though the user
didn't change anything.
To fix this, we only tag as changed (in the datapoint `_changes`
attribute) the fields that have a different value after the onchange.
In an embedded editable list view with the widget `handle`, resequencing a
record and try to edit it afterwards won't work. The selected record isn't the
correct one, as if the resequencing had no impact.
To make this work, the list datapoint needs to be ordered by the field with the
widget `handle` ; if it isn't, resequencing the records won't change the x2many
data order but the list view expects the same order.
In an editable list view with the widget `handle`, resequencing a record
and try to edit it afterwards won't work. The selected record isn't the
correct one, as if the resequencing had no impact.
A small refactoring has been done to fix this because the resequence logic
was placed in the ListController (but should logically be placed in the model).
Several views are using the resequencing ; the code is thus now placed in the
BasicModel.
The list renderer state is then updated after the resequence.
The resequencing and the line edition have been placed in a common mutex to
avoid problems when the user tries to edit a record while the resequence rpc
isn't finished yet.
Setting ir.values for computed fields is useless as the function onchange
in models.py will set to False all the computed fields with a modified dependence.
opw:767942
Before this commit, the scroll was reset to the top of the calendar after
an event quick create.
This commit fixes this by defining the get/set localState for the calendar
renderer in order to keep the scroll and calling 'reinitView' from the
fullCalendar lib instead of always calling 'render'.
Before this commit, we did not really handle gracefully editing a
one2many with many records. The main issue is that if the user was not
on the last page, creating a new record added it to the last page, which
is confusing and actually a bad idea for records with required fields.
This fix requires a way to track the current changes (because we do not
display the current state of the form view: the new record is displayed
in the first page, but is actually added at the end of the dataset).
Note that this probably does not solve all issues with pagination. This
is a quite delicate problem. We will add tests and fixes as needed.
... sometimes.
When a dialog is destroyed, the last opened dialog (the one which
is just below), if any, is focused. This allows to close it
directly by pressing ESC. For an unknown reason, this was done in
a setTimeout (delay 0).
The problem is that the setTimeout made some JS tests fail
randomly, when a test ending by closing a dialog was executed
right before a test using a many2one inside a dialog. When this
happened, the second test failed sometimes because its dialog was
focused (because of the previous test) while waiting for the
autocomplete dropdown to open, triggering a blur event on the m2o
input, and thus making jquery autocomplete aborting the search,
and the opening of the dropdown.
Use case:
- a tax of 10%, computation method: percentage of tax included
- a account_reconciliation_model with an amount of 90%
- make a statement of 1.31 (or something weird when it comes to digits)
- reconcile it with a counterpart
- prefill that counterpart with the account_reconciliation just created
- push on reconcile
Before this commit, the amount that was computed was not rounded, resulting in making unbalanced account_moves (by 0.001)
This was invisble since the display of monetary is rounded
After this commit, the rounding is done according to the currency's parameters and produces correct move_lines
OPW 751881
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).
Before this rev., it crashed when the user typed a date (actually,
the last character of a date) in the search view (e.g. in
Accounting > Customer Invoices).
Make sure '.o_invisible_modifier' table-cells are forced back to
`display: table-cell` to keep correct alignement. Indeed using the
`initial` value forced them to `inline` instead (creating some
obvious visual bugs in some cases).
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).
The problem occurred in form view, in edit mode, when the user
did some changes in the form, and then clicked on 'Log or schedule
an activity'. When validating the activity, the fields mail_activity
and mail_thread were reloaded but all changes were discarded in the
process.
This rev. ensures to reload the requested field without discarding
the changes.
The barcode mechanism is supposed to handle commands PAGER-FIRST
(go to first record referenced in the pager) and PAGER-LAST (go
to last record). Before this rev., it wasn't the case.
We needed to add an option 'notifyChange' to the updateState
function of the pager, to ensure that the form is correctly
reloaded when the pager cursor is manually set (by the barcode
handler) on the first or last element.
Christophe Simonis