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)
For an unknown reason, in some case, urllib doesn't work while with urllib2 it works.
Since we don't have the opposite case until now (work in urllib and not urllib2), we
considere that it fixes the issue.
this commit closes#14636
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
By the way Lois Rilo lois.rilo@eficent.com is now integrated in the
Eficent corporate CLA and does not require a personal one anymore on
the same email address.
Related to #15886
Don't pass default code to child accounts to avoid raising wrongly the constraint: duplicate key value violates unique constraint "account_account_code_company_uniq"
Courtesy of Stefan Rijnhart (Opener). Was PR #16804
With this, when you import a bank statement that contains lines that had already been imported, the start balance of the statement is automatically recomputed.
Courtesy of Alexis de Lattre (Akretion). Was PR #16144
Authorship should go to https://github.com/joray . However as he did
not sign the CLA and does not seem very active the patch is applied
to benefit from the improvement.
Closes#16294 .
Description of the issue/feature this PR addresses:
The Tax ID field is validating NOxxxxxxxxx as format, but the format is actually NOxxxxxxxxxMVA if you are in the VAT registrty.
Current behavior before PR:
Valid tax numbers for Norway are rejected.
Desired behavior after PR is merged:
The format NOxxxxxxxxxMVA is accepted, along with the old behaviour of NOxxxxxxxxx.
Description of the issue/feature this PR addresses:
The production routing is ignored when creating previous movements
Current behavior before PR:
When you create a production that does not have a routing established in the BOM, and you set a route manually, it is ignored when creating the previous movements
In view dialogs (e.g. click on the external button of a many2one
in edit mode), the attribute $buttons of the form controller is
undefined (the buttons are rendered by the dialog directly). The
code that (de)activate the buttons to prevent concurrent clicks
made the assumption that $buttons exist, so it crashed when it
doesn't.
Closes#16366
Steps to reproduce the problem:
- create 2 company
- create 2 different sequences 'payment line', one for company
- create a payment order for company A and insert a line
- create a payment order for company B and insert a line
Get SQL error saying The payment line name must be unique
Closes#17274
Without this, the Configuration > Accounting > Journals shows
the Bank Journals view. And the type column is missing.
This align with what is done for the form view.
When duplicating a quotation with a template, the order date is set
to today's date. But the validity date was duplicated which was wrong.
Now the validity date is computed according to the template and not duplicated.
opw:744671
For example: open a draft quotation, click on 'Confirm sale',
before this rev., the record was reloaded twice (each RPC done to
load the data was duplicated). This was actually tested, but the
tests didn't mock well the behavior of the ViewManager, so they
couldn't detect that those RPCs were done twice.
For historical reasons, when the pivot view was rewritten, we lost the ability to understand the measure and col_group_by keys from the context.
It was actually a deliberate decision, because we decided that it was not possible to properly handle the colgroupbys in the search views, so we replaced that mechanism with pivot_col_group_by and pivot_measures keys exported by the view, when necessary.
Sadly, we did not properly remove the outdated keys from the xml files. So, with this commit, we reintroduce those special keys, because 10.0 is a stable version. Note that this will be removed in master.
(PR 17119)
Suppose that there is a many2many list (non editable) in a form
view. When one of the many2many subrecords is edited (from the
form view in a dialog), it is saved directly when the user clicks
on 'Save' in the dialog.
Before this rev., if the user clicked on 'Save' in the main form
view after editing a m2m subrecord, a 'write' RPC was done, whereas
there were nothing left to save (as the subrecord had already been
saved).
Suppose that we have a form view with a one2many list (non
editable) containing a record. In edit mode, the user clicks on
that record to edit it in a form view (in a dialog). In this form
view, there is an x2many field that isn't in the list. Before this
rev., it crashed when the user clicked on 'Save' in the dialog
after editing the value of the x2many.
This was because the basic model didn't use the correct fieldsInfo
in that case (it use the fieldsInfo of the list view instead of the
one of the form view, and the x2many field isn't in the list).
Also ensures that the record is correctly saved even if editing the
x2many is the only change done, as this wasn't the case before.
Closes#16801
When a warning is set on partner profile, _onchange_partner_id method in
the invoice returned the message before assigning account_id,
payment_term_id, fiscal_position_id. hence, those fields come with empty
value.
Martin Geubelle