On the 6 June, the rate from EUR to USD change
in demo data. This cause problem in test, when
comparing amount.
We choose to not used currency rate defined in
demo data and that are time-dependent.
The import_module() method does not need to be public,
so let's mark it private. It's not called by anyone
except import_zipfile().
After 76cd8d2558 it would
fail anyway because addons_path would not be prepared by
import_zipfile().
Before this fix, if the start field is readonly, the user could not create
an event. With this commit, it is also ensured that the context sends the
right default values to the view
with the new views, we removed the many2many_kanban widget on many2manys, since it is the default behaviour anyway, but we also removed it for a few one2manys. And this is a mistake, some one2manys have to behave like many2manys.
(PR #17190)
Previously, when an update operation was performed, the list of
ids in the x2many field was emptied beforehand.
It kinda worked in lots of cases where one would expect it to
fail because in thoses cases the widgets send link_to commands
along with the update one, thus re-adding the removed line.
Now the behavior is more consistent accross the board. We start
with the current list of ids and apply the requested changes.
Otherwise some changes can create rpc errors that are silently caught
and never seen as long as, out of (un)luck, the end result is the same.
Tests which need to create a server error can just simulate it using
the mockRPC mechanism.
When the user writes something in a Many2One input, after a short
delay, a name_search RPC is done with the value written in the
input, and results are displayed in a dropdown. Then, if the user
clicks on the input, the dropdown closes. If he clicks again, it
should do again a name_search RPC with the value of the input.
Before this rev., it was doing it with the empty string.
Suppose that we have a many2one which is set (has a value) in
a form view. Before this rev., if the user unset the value (by
erasing the input content in edit mode), and then reset the same
value, the input remained empty, and the old value wasn't actually
reset.
Problem occured with checkboxes in editable lists: when pressing
up, down, right or left with the focus on a checkbox, in addition
to navigating in the requested direction in the list, the page
scrolled (if there was a scrollbar of course). This was because the
event wasn't 'preventDefaulted'.
When creating a new record where the ´domain´ widget is set in the view
with an associated model but this model field has no value, an rpc
(search_count) was done on an unknown model, that causes a traceback.
To avoid this, the rpc is not done if the model is not set.
Keys 'graph_mode', 'graph_measure' and 'graph_groupbys' can be
specified in the context and must be used by the graph view to
determine the default mode, meadure and groupbys. Before this rev.,
those keys were simply ignored.
Function 'set_value' of datepicker had been renamed to 'setValue'
by commit 5f13b7f. There were still a call to that function that
needed to be adapted in the search filters, so it crashed when
trying to add a custom filter on a datetime field.
It would be nice to add a test for this, but the code of the
SearchView cannot be easily tested yet.
In some cases, the parentID was not properly set, which is a problem
when we need to evaluate the parent in a context.
Note: I also added a better error explanation in the mock server, to
make it better for the developper to see what is wrong.
Clicking multiple times on 'Create' (in main list views) or 'Add an
item' (in o2m lists) might create invalid rows (i.e. rows with
required fields unset).
Creating a new record requires two sequential RPCs: a default_get
and an onchange (only if there is an onchange of one of the
record's field). When clicking twice to create a new record, that
sequence of RPCs is done twice in parallel, after unselecting the
current row (i.e. saving it if it is valid). However, in both
cases, there is no line to unselect yet (as both operations are
done basically simultaneously). When the first onchange returns,
a first new record is added to the list. When the second returns,
the second one is added and takes the edition, leaving the first
one, invalid, in the list.
This rev. ensures this doesn't happen by preventing concurrent
record creation.
... before saving a line.
Suppose that we have an editable list with one required field
(e.g. many2one) with an onchange. We add a record and select a value
for the many2one. Before the onchange returns, we click again on
'Add an item'. If we don't wait for the onchange to return before
unselecting the row (i.e. before saving it), a confirm dialog asking
if the changes can be discarded opens, because the line isn't valid
yet. This could easily be reproduced on the sale_order form view,
with some throttling.
This rev. ensures that we wait for the onchange to return before
saving the line, and thus before creating a new line.
In a slightly too naive way, we apparently tried to improve the
parse_float method while rewriting the new views. This was done by
using a regexp to match all occurences of a thousand separator.
The way the regexp was built was fine, until the thousand separator is a
'.', which, if used as a regexp, matches all characters. Also, sadly,
'.' is not so rare as a thousand separator...
When creating a vendor bill from a PO, the payment term configured in
the PO was lost due to function _onchange_partner_id.
When creating a vendor bill, the field payment term was invisibile if
there was no payment term set on the vendor.
opw:744714
When a ´default_order´ is set on an embedded view for a x2many field,
the sort was only applied server-side, after saving the record. After
adding a record in a x2many, the records were thus not correctly sorted.
We reintroduce here the client-side sort after the x2many modification.
With the new views, the attribute autocomplete on input was no
longer supported. We simply reintroduce its support in this commit.
The basic attribute values are 'on' and 'off' but one may want to use a
random string.
Note that an input with type='password' is a special case: the autocomplete
attribute should always be set to 'new-password' to remove autocompletion
(autocomplete='off' doesn't actually remove the autocompletion).
When clicking on 'Save & New' in the form view dialog, a new default record
is created. The parent was not correctly set in this record, which causes an
error if `parent` was used in context.
Only the validity of a date was enforced but the date could also be
wrong in other situation (required so must be filled, validation
attributes, ...).
opw-744273
closes#17329
Before this commit, error was giving on browser console when we open seo wizard which is due to the wrong (this) was passed when initializing Configurator
So in this commit, we passed correct this, to get rid of the error.
(PR #17260)
Quick creation of attributes in the bom line of the bom form does not
make sense as it won't be related to the product (and would need to
create extra variants, ...)
closes#16924
Because read_group can not handle non-stored fields well,
we fall back to the similar implementation as for the stock
valuation report. This allows only one non-stored field as a measure in
the graph. Then it is more logical to show the total margin as that is
what the module is meant for.
The previous code when "Manually Assignation of Incoming Emails" sale
config was set always set the alias prefix to "info" even if another
value had been previously saved.
opw-745174
closes#17305
Default value is out_invoice aka an invoice of type sale. However here
we would like to test invoices of type purchase. Otherwise extending
tests for specific purchase-related invoice code is not possible. This
is done using the magical context key type.
Closes#15886
Jérome Maes