Better display of contacts, simplified contact creation, use default image
for shipping and delivery, and various fixes and improvements in the
form view.
Main impacted addons :
- account: add a bank_account_count field and stat button that replaces the
2many field
- base_vat: remove the button to check vat, as there is already a constraint
and removed and unused import
- payment: add a payment_method_count field and stat button that replaces
the 2many field
Simplify contact / addresses management. Contact now use the same
address as their parent. Invoice, delivery and other contacts
have their own address. Default contact is removed; the default
is now contact.
As contact automatically use the company address, and other types
use their own, use_parent_address field is removed, leading to
some simplification in the address management.
Also add company_type field, to have a selection field instead of a
boolean one when display company / person choice. This is an interface
field build on the is_company field, to create the minimum change
and avoid disturbing the logic based on is_company. When migrating
to the new API, its implementation will be cleaned.
The website_crm module doesn't depend on website_sale, so the
salesteam_id field may not exist on website in contactus.
There is clearly a strange overlap with the website salesteam
between website_crm and website_sale, as indicated by the xml_id's.
The previous version didn't crash when the xml_id was not found,
though, while this one would always crash when you try to use
website_crm without website_sale, so I prefer to revert it.
A proper fix would be to set the salesteam at the level of the
website module, but I'm not sure it would make sense considering
that it wouldn't be used at all unless you happen to install one
of those two modules.
In the meantime, I'm reverting afc9507f3a.
1. A menu with `/page/website.***` should be flagged as `active`
if the current url is `/page/***`. This is a retro-compatibility
patch for c9d41679fb, so the
menu is marked as active without having to rename it, by
removing this `website.` thing.
2. If you defined two menus with as url `/page/test` and `/page/test2`
Both menus were flagged as `active` when you browsed the url
`/page/test2`, because it started by both menus urls.
Fixes#3059Closes#3070
In the top menu bar, the `active` class is set when the
menu url matches the page url (the url in the browser url bar)
A while ago, we made so all urls
`/page/website.***'
were automatically redirected to
`/page/****`
Therefore, if the menu url still contains this `website.` prefix,
the active class wasn't set on it, while it should.
Fixes#3059Closes#3070
The fields are properly reflected for base many2many fields. Moreover, the
code has been improved to remove a custom many2many field whose table is still
used by another field.
Onchange methods have been added:
- When name, model and comodel are chosen, propose table and column names.
- When table is modified, propose column names if the table is already used by
another many2many field.
When ordering results on a many2one fields, results are ordered by
order of the target model. The code was wrongly assuming that this
`_order` attribute only contains `_classic_read` fields (that can be
directly read from the table in database). Now correctly generate the
"ORDER BY" clause using the current table alias.
`res.users` can now be sorted by name.
The dataset implementation has been improved to handle the result of a `read`
on ids that are already modified in the dataset: the lists `to_create` and
`to_write` are updated properly.
Use `field.convert_to_onchange` to format the output of method `onchange`. By
default it behaves like `convert_to_read`. This is useful for the many2one
case, as the client automatically receives the display name of the record.
For the *2many case, we return a list of dicts values, in recordset order, with
all the known fields in the view:
[{id: 42, name: "Existing record"}, {name: "New record"}, ...]
Each dictionary contains the values of all known fields in the view. The
client is responsible of determining which fields are dirty by computing the
difference with former values.
Since the method `onchange` now uses `field.convert_to_onchange`, the method
`field.convert_to_write` has been simplified, as it no longer needs its extra
parameters `target` and `fnames`.
Raphael Collet