| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Action action_sale_config has been moved to sales_team addon at
odoo/odoo@fa6e415.
|
|
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 fa6e415cdb23ce9494487ed672792186157b40e0.
|
|
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.
|
|
- Restructure the menus this way:
Sales Flow
Pipeline
Proposal
Deployment
Incoming emails
Customers
Products
Prices
Reporting
Customizations
- Add a short intro about leads in Incoming emails (why using leads?
first contact, contact forms) -> in incoming email menu
"There are several ways for your company to generate leads with Odoo CRM.
One of them is using your company's generic email address as a trigger
to create a new lead in the system. In Odoo, each one of your sales teams
is linked to its own email address from which prospects can reach them.
For example, if the personal email address of your Direct team is
direct@mycompany.example.com, every email sent when a new prospect
contacts you will automatically create a new opportunity into the sales team.
That's the easiest way to integrate Odoo with third party apps.
|
|
|
|
|
|
apr request
|
|
|
|
In installation script or documentation
Fixes #10052
|
|
|
|
Typos, unclear, rephrase, harmonise terms.
Thanks Transifex reporters!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Missing spaces, typos, rephrase unclear text
Courtesy of Eric Geens
|
|
|
|
Courtesy of Eric Geens
|
|
|
|
Courtesy of Eric Geens
|
|
Courtesy of Eric Geens
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wet let the dom as it is used by the planner implementation. Hide all
the titles of the end pages.
|
|
|
|
|
|
|
|
for channel-related stuff. mail.channel views as well as timeline views
and actions have been renamed. Now the names follow the guidelines and
will be used in the upcoming refactoring of mail and chat.
|
|
- clean the planner style
- add specific class per planner crm (avoiding collisions)
- create .o_planner_white_box class used in all planners
- add planner for project module
|
|
This commit impact crm, website, website_sale and web_planner modules because it
- add planner for website and website_sale
- improve planner notebook by setting texterea and input size to 100% and using col-md-* class
- split js code into common part (used in backend and frontend) and backend part (only for backend)
- adapt some tour, since every page will have the planner modal in its DOM, the tour selectors msut be more accurate
- introduce some style fixes and adaptations
- ...
|
|
|
|
conventions.
|
|
- Make planner accessible only for erp manager and admin. Portal and employee are not concerned by planners
- Clicking on link redirect to module installation form if module not installed
- Add 'is_module_installed' method to display note if module is (not) installed
|
|
|
|
Planner is like web Tips : a data in a module.
- Rename planner.planner to web.planner
- Rename files according to guidelines
- Remove planner_crm module
- Make CRM depends on web_planner, and add its planner as crm data
- Remove duplicate less style
- Add 'active' boolean field on planner (to disabled them), and create planner backend views
|
