Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
This branch need more testing instead of doing 10 fixes. A lot of issues are occuring
when installing modules in different orders.
This reverts commit fa6e415cdb.
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
If `probability` is not being written,
`vals.get('probability')` is `None`
`None` < 100 is `True`
While it should not remove the `date_closed` value
when the probability field is not being rewritten
on the lead, but something else is.
opw-677273
The field generation is most of the time following the pattern
`field_<table name>_<field name>`
but in case of name clash (e.g. res.partner.category - id and res.partner -
category_id), the id of ir.model.field is added at the end of the external id
during the field creation.
The more flexible way to link to an ir.model.field is to use the syntax
`search=[('model', '=', <model>), ('name', '=', <field name>)]`
to avoid errors as in #12192 when the "first" external id no longer exists.
Fixes#12192Closes#12198
>In Dashboard/Your pipeline and in Sales/Your Pipeline: Remove the Direct Sales team filter.
>In the kanban view, if the expected revenu = 0, the "," shouldn't appear.
>In lead form view, remove the Opportunity header and move Probability under Analysis in Extra Info tab.
>Rename Your Pipeline into My Pipeline to match the menu entry.
When merging leads with a company set different
than the current user company,
it failed because the notification email (the message
written in the thread summarizing the merge) couldn't
read the company name (the `name_get` call on the company)
because of the multi-company record rule.
`name_get` can be safely called as `sudo`, as it does
nothing else than returning the name of the record. This is
already done for the many2one links in the web client anyway
(You can see leads from a company different than yours,
you can see the company name to which the leads belongs to,
but you can't click on the company many2one link)
opw-677986
Aaron Bohy