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
Models renamings:
- crm.case.stage becomes crm.stage
- crm.case.section becomes crm.team
Model split:
crm.case.categ has been splitted into:
- crm.phonecall.tag
- crm.lead tag
- crm.claim.tag
- crm.helpdesk.tag
Models removal:
- crm.payment.mode
- crm.segmentation
- report.crm.case
Removal of the crm_profiling module
(all these refactorings have been done in order to ease new API
migrations)
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.
it was trying to call the forme 'hide' method on the searchview. To
solve the problem, I readded the method (and renamed it to do_hide for
consistency with views)
After closing a POS session, the pos order lines are grouped by product.
Instead, distinguish products with a different discount notice to have different lines for such products in the generated account.move for better traceability.
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
When searching on the name of a product.template, search also on the default_code. Move the filter from product.product to product.template.
The field default_code is on the product.product but accessible through a related field, meaning when reading it will fetch only the first variant but searching on all variants.
Fixes#3399
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.
this change is simple, except that many actions display a form view in
'create' mode to edit some stuff (for example, most settings forms or
the 'Your session' action in point of sale).
As a work around, we use
a simple heuristic (nice word for horrible hack): the title displayed
is the title of the action if we have a single form view.
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
Raphael Collet