The unit price of the quote template lines is never be used anywhere
It is logical that pricelists determine the price of products and this
field is quite informative.
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.
The old api on_change_product_id function in model 'sale.order.option'
doesn't receive the order_id to compute correctly the price unit for
suggested products. The new api _onchange_product_id function has exactly
the same logic as on_change_product_id and this function receives the order_id.
Then the new one can replace the old one. But to keep the compatibility with partners
who overwrite this old function, it is kept in the code.
This bug was introduced by 5047f4e, this commit defined the product_uom_change function
which called on_change_product_id. This commit was applied in saas-6.
The onchange calls in the views have be removed because all the new api onchange are called
even if they were still there.
opw:656494
f26b94f had as goal to filter the taxes of the product
according to the company when the sale.order
was created/edited as SUPERUSER_ID
(Who ignores the record rules).
Unfortunetaly, to filter the taxes,
it used the company of the customer,
while it's actually the company of the order which
should be used.
Indeed, for instance,
partners can be shared among all companies.
It was way less simple to access the company
of the sale.order, this parameter being
not available in the on_change method signature.
This is the easiest way to solve this issue
without breaking the API / retro-compatibility.
opw-647819
In view inheritance, selecting an element based on the attribute `string` is
broken, since this attribute may be translated before the inheritance is
applied. This fixes existing views to avoid such selections.
Use the lang from the sale order's partner when updating suggested
product line. To achieve this, the onchange has been replaced by an
onchange of the new api which gives access to all the fields.
closes#7268
opw-643098
Until now, you could only sign and confirm a sale order from the frontend.
From now on, you can also pay sale orders if the 'Immediate Payment'
option is checked on the sale order.
sale_crm : prevent the creation of SO from lead form view (avoid bypassing process)
website_quote : "View Quotation" on SO form view should not be a state button, so it is now replaced by a link near the field
* add on_change_uom behaviour to quote templates lines
* fixes frontend layout issues
* use action_button_confirm instead of signal_workflow
when confirming the quote in the frontend to trigger
all events properly
* adapt prices using pricelist on onchange_template_id
on sale orders
- account: placeholder on invoice form
- sale: do not display "Default Options" menu if no option is available (added
by submodules).
- product: remove unnecessary section for uom
- placeholders Terms and conditions more helpful for configuration
- unify some partner title to avoid getting duplicates
Ravi Patel