Portal users do not have access on invoices or invoice lines. However when
viewing an online quotation in website_portal_sale some computation is
performed based on invoices and invoice lines. We therefore iterate on
invoice and invoice lines as superuser as we do not want to grant any
additional access on those models for portal users.
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.
Indeed, running the testsuite is not supported in multi-process (worker/pre-fork) mode, for multiple reasons: no multiple/concurrent execution of tests, necessity for in-memory cross-request statefulness (test cursor), etc.
We have no plan to work around these issues, as there seems to be no strong use case.
Our testsuite is mainly focused on the business/framework aspects, and not scalability/deployment aspects - which would require a much more complicated test infrastructure.
Error thrown by google request is an urllib2.HTTPError that can be read
and loaded in JSON. However in some cases the result of the read may
be void or not JSON-ready. This was causing a crash in the error
management and hid the actual issue.
This commit tries to read and JSON-load the error but fall back on
simply displaying the raw error in case of issue when handling it.
Closes#17308 .
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.
In this commit, we improve the behaviour of quick creation in grouped kanban views. The issue was that the quick create widget was removed when the user click somewhere else, even if the user added some text. For example, the problem could be seen in the kanban view for the tasks.
In this commit, we simply keep it around if there is a non empty text.
We need to ensure the account move lines we search for in case of partial reconciliation are within the period boundaries
Before this commit, when a partial reconciliation has been made long after others, the date used would have been this former move's
because of the MAX() function introduced by commit 3128e84243
Hence for one period, if that date were to be outside the period boundaries, the entire reconciliation would have been discarded, leaving the period due amount to 0, but a non-null total
This commit still uses the MAX() function, but specifies the aml date must be within the period boundaries
OPW 740793
OPW 725890
Closes#17098
The field was made mandatory in the form view since the move line name
is no longer required from saas-15 onward. However, some automatic
process might still create moves without name. To avoid blocking the
user, we make this field mandatory only for new moves.
opw-744054
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...
In multi-company:
- Create 2 companies A and B
- Set the superuser on company B
- Set the website on company A
- Define company specific sequences for SO (e.g. SOA and SOB)
When a SO is generated from the eCommerce, it is defined on company A
(thanks to 8a1b55a), but the sequence is from company B.
opw-744561
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)
The stat button "Leaves Left" is a computed field of type integer.
However, it aggregates the data of `number_of_days`, which is a float.
Since the field is not stored, we can change its type.
opw-743153
Thibault Delavallée