Creating custom fields would crash on a model that has a related field without
string. The crash was caused by the field not being set up, and method
BaseModel._field_create() violating a non-null constraint on the field string.
This has been fixed by setting up fields before updating ir_model_fields.
Deleting a custom field could also cause trouble when that field is inherited
in a child model. In that case, the registry was simply no longer consistent.
The fix is to reload completely the registry.
The modification of custom fields was not reflected on field objects. The fix
applies changes on fields before updating columns accordingly.
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
Some prices, as standard_price, being a property, are company dependent. Therefore, when browsing as superuser, force_company is mandatory to get the property of the user company
[FIX] account: Preserve analytic account on tax lines which are on same general account as invoice line
After careful analysis, I'm now convinced it is a good thing to preserve
the analytic account on taxes line which have the same general account
as the invoice line.
This is the best default case and will save time for users,
while leaving the flexibility to adapt the analytic account on
taxes manually.
[FIX] account: Error when manually adding analytic account in the generated tax lines on an invoice
fixes#374
fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822
The fix considers invoice tax lines with different analytic account
are equivalent for the purpose of checking if the list of tax line
is complete.
Caveat, this changes the structure of keys in the dictionary
returned by account.invoice.tax's compute method, I suppose this
is ok for the master branch.
Make sure the constraint on IBAN format is checked when either the state or the account number is changed.
'iban' field was not modified so the check never triggered and could enter invalid IBAN
Fixes#3426
Duplicate product filter "To Purchase" and "Can be Purchased". Same search
criteria and same name, so removing one doesn't affect people who were
referencing it (e.g. with search_default_* key in context). Left the one
named "Can be Purchased" because consistent with the equivalent sale filter
"Can be Sold".
Fixes#2718, closes#2864
When using this code as is, the 'ids' variable throws an exception for not
being defined. In the new API, 'ids' is no longer given as a function variable
but as a variable within 'self'.
close#3406
Without this, the unit price is visually set to full, the discount column is not visible, but the actual price used in computation is the discounted price, very misleading !
opw-617036:
In my current timesheet, if you add a a required field on the timesheet ids lines, and add data in the summary tab, it was possible to validate the timesheet lines while requried fields were missing.
When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move.
This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed.
This avoids trying to update the stock.move with a uom at False. opw 616844
When creating a new account.move.line, the computation of the default values should accept both `id` and `(id, name)` format.
The key partner_id may be containing a tuple so browsing should only be done on the first element of the tuple.
Fixes#3386
This is a workaround for an ORM limitation. A stored function field is
not updated when it should if the "source" field is also a stored function
field
The store recomputation method failed as the search was made comparing id of account.move.line to the account.journal values. Search was returing no result most of the time (opw 615554)
Fixes#2454
Raphael Collet
Arthur Maniet
Will Stott
David Monjoie
Denis Ledoux
Martin Trigaux
Frédéric Van der Essen
Stéphane Bidoul
Jeremy Kersten
Sheth Sunny
Alexis de Lattre
Thibault Delavallée
Christophe Simonis
Xavier Morel
Paramjit Singh Sahota
Leonardo Donelli
Richard Mathot
Simon Lejeune
Adrien Peiffer
Nicolas Bustillos
hiekmann
Mohammad Alhashash
Géry Debongnie
Julien Legros
Somesh Khare