In order to sort lunch order by date desc, the commit
9ab9da235f modified the
json structure (dict to array) of serialized 'previous_order'
field, without changing js code.
The previous order field should respect the new order, so
using OrderedDict does the job !
The previous code loading the tooltip data was sending a null value
to read as id, which resulted in an access error. This behavior was
not observable in the tests because of b8c1571 which was meant to
allow giving inexistant ids to mockRead but also ended up accepting
falsy values, which was not true to the actual server.
In addition, the title of the column was wrong for unset m2o, it
displayed false, the value of the field when unset, rather than
the default "Undefined" title.
When I introduced this line in 374295b, I was working on the form
view and didn't realize I would be breaking the editable list view.
The _setMode function only updates the buttons when given the id of
a record. Since I was working on a form view at the time, I didn't
need to give a recordID to make it work since the default ID of a
form view is the id of the record itself. However, in editable list
view, the id of the view is a list of ids, so the buttons would not
be updated in this case.
When the show_address option is enabled, the display_name of a
partner becomes a newline concatenated version of his name and his
address, so the internal value of the widget is this conglomerate.
However, if one uses a keypress that does not change the value of
the input in edit mode, say ESC for example, the keyup handler of
this widget will compare the value in the input with its internal
value. If the internal value is still the conglomerate, which is
the case if the user hasn't changed the input content since
switching in edit mode, we need to trim it to compare it to the
actual input value, which is the "standard" display_name, ignoring
the magic show_address feature which is only used in readonly.
When creating a new record, the numeric field default value should be 0 in order
to avoid manually setting mandatory fields to 0.
This behaviour has been removed with the new views but one wants to restore it.
The `mockRead` function has also been adapted in this commit because the server
returns 0 for unset numeric fields.
Before this fix, a traceback occured when we clicked on the translate icon
in a form dialog.
The `translate` event wasn't stopped and was thus handled by the dialog's form
controller and by the main controller.
Before this fix, multiple records were created if you clicked
on the quick create of a many2one in a modal.
The 'mutexify' event wasn't stopped and was thus handled by
the dialog's form controller and by the main form controller.
The module `crm.voip` alters the focusable behaviour of the phone
widget by overriding the `canCall` method.
We thus disable this test if the module is installed.
Rev. https://github.com/odoo/odoo/commit/c5f8f35747b4ca9633c664d6be74614c5ce22fcd
introduced a regression: the input of widgets 'email' and 'url' was not correctly
focused anymore with tab navigation.
The method `getFocusableElement` on their common parent (`InputField`) has not been
correctly overriden because `_super``was not called in edit mode.
Before this fix, it was possible to set the widget 'pad'
on char fields but it only worked if the current model
inherited from 'pad.common'.
In the other cases, it crashed on closing Studio.
As there is two models only (project.task and
note.note), we decided to remove the possibility to set
this widget in Studio.
opw-745997
During the formating method, the country code
was compared to the country phone code. Indeed,
phonenumbers python lib return a `PhoneNumber`
object having a `country_code` attribute
refering to the country_phone_code, and not
the country_code (like odoo means).
Consequence: changing the country on a lead
did not make the phone validation work.
Thus, it was required to give both code (country
and country phone codes) to the phonenumbers API,
in order to make a correct verification.
When refusing leave, we can not remove linked timesheet,
since they are attached to the leave.
We need to first detach it, then remove the timesheet
entries.
Also, add a test about the removal of linked timesheets.
The tab navigation was only working in edit mode. Entering a readonly form
view with input fields was causing a traceback.
As the default browser behaviour has been overriden with custom navigation,
we need to specify which widget can be focused (e.g.: url, many2one, etc.).
In an empty kanban view, when moving a freshly created record from
the second column to the first one, then moving it back again in to
the first one, the record was mysteriously duplicated.
When moving the record, it should be removed from the old column.
In this case, the second column was not found (and thus the record
not removed) because the iteration was on `parent.count` (which is
the count of records in this datapoint (1 in our case)) and not
parent.data.length (the number of columns).
The mock server had to be modified in order to test this behavior
since it used to throw an error for invalid ids, while the actual
server just ignores it and continues forth with the other ids.
Previously, the button was completely invisible when no icon
was given, which is a regression from saas-15 where the string
attribute is used to write the button label.
Field widgets must format and parse values according to the widget
type, not to the field type. For example, if a monetary field is
inserted in a form view with widget="float", the field's value must
be formatted with the float formatter, not the montetary one. This
wasn't the case before this rev.
Commit 9966e4b added calls to preventDefault() on the keydown event
for left, right, up and down arrows, to prevent the page from
scrolling. However, it also prevents the cursor from moving inside
the inputs. Since the initial issue only concerned checkboxes, this
rev. moves the preventDefault() calls from AbstractField to
FieldBoolean.
Inspired by d7939282e9. Without this you
end up with a URI with a length of over 50000 characters. The default
template doesn't actually use any fields on pos.config so we could
theoretically get rid of everything. But because it's easy enough we
just get rid of relational fields and the customer_facing_display_html
field itself which make up the vast majority of the URI.
It is still possible to have negative and positive quants in the same
location because of returns: if you send something to the customer that
is not there and you return it, you will still be able to reserve the
returned goods to send to another client.
Before, if you would do an inventory adjustment, it would not take into
account these returned quants and their negative counterpart, which made
them difficult to get out of the system.
This fix takes them into account by creating two movements for one
inventory line: move the positive counterpart to the inventory location
before getting back from this location the same quantity.
This way, even if you have 0 as quantity on hand but you have those 2
quants, it will eliminate them. (if you are increasing the stock, part
of the process might have done it automatically already).
Test cases contributed by @jir-odoo
Cherry-pick of be9dce625c
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
Jérome Maes