Issue
- Create a database with 2 users
- Open the calendar application and create a meeting for you and the other user
- In the option:
set Privacy to 'Everyone'
set Show times as 'Free'
- Send the invitation to the other user
Access Error (rule: Hide Private Meetings)
Cause
The 'calendar_event_global' ir.rule is deprecated and related ir.rules
are now in calendar module (crm.meeting -> calendar.event).
Solution
Remove rule since deprecated.
opw-2469433
closesodoo/odoo#67706
X-original-commit: c2a3fdbc42e042440695c8a3fc3e657d910d2d5c
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Right now there is a button in the CRM settings called 'Update Probabilities'.
When clicking on it probabilities of leads created after certain date
are updated. Problem with this flow is that user can click on the button by
mistake and there is no going back.
Moreover this does not trigger a save on settings and changes done by user
are not saved. This is standard behavior of config settings.
This commit improves the behavior by opening a wizard on click of the button
instead of directmy updating the probabilities. It allows users to change
fields used in PLS, change start date, or even cancel the update process.
Task ID-2355562
closesodoo/odoo#60733
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow users to configure contract recurrences and Monthly Recurring Revenues
on Opportunities they're trying to close. One short revenues are not sufficient
to cover real life use cases of CRM revenu analysis.
SPECIFICATIONS
Adds an option in the settings to activate the recurring revenue feature.
This feature is set on an opportunity to indicate a revenue that could be
perceived over time. This time indicator is set by the crm.recurring.plan
model in which the number of months is determined.
By default some plans are added in data. When using plans, revenues are
computed across the plan months.
LINKS
Task ID-2283052
odoo/odoo#54194odoo/enterprise#12423odoo/upgrade#1463
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As the crm.lead.tags model shall be used in CRM and/or Sales apps,
it has been moved to the sales_team module, which is a depedency
of the CRM and Sales apps.
As these tags becomes more generic than just "lead tags", the model
has been renamed from crm.lead.tags to crm.tags.
Tags on sale orders were already present but not visible. They are
now visible in the "Other Info" section, and optionally in sale order
tree views.
When a quotation is created from an opportunity (CRM app), existing tags
are populated from the opportunity to the sale order (Sales app).
Views and demo data of several modules have been updated accordingly.
Task ID 2191276
PURPOSE
This refactoring commit removes the crm.partner.binding mixin. Indeed it
defines a mixin for unnecessary fields, generally either redefined in
inheriting models, either not used at all. It also holds an utility method
we moved directly on crm.lead model.
SPECIFICATIONS
Code move
* move _find_matching_partner to crm.lead model;
* move action field into inheriting models, except crm.lead.convert2ticket
that does not use it;
* move partner_id to inheriting models;
* remove crm.partner.binding model and inheritance;
Improve behavior
* correctly store lead and partner many2one fields on all inheriting
models. It allows to support a default_lead_id instead of always
relying on active_model / active_id, making the wizards more generic;
* update default_get accordingly in various inheriting models in order to
correctly compute lead / partner values;
LINKS
Part of Task ID 2056759 (remove crm.partner.binding mixin)
Part of Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#44970
Enterprise PR odoo/enterprise#8307
Upgrade PR odoo/upgrade#750
Related: odoo/enterprise#8307
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
This new Predictive Lead Scoring (aka PLS) replaces the stage based probability mechanism.
It uses Naive Bayes probability computation theorem.
The lead probability is now computated automatically based on multiple criteria (= frequency fields).
Some are mandatory and will always be used, some are optional and can be activated
in the settings.
- Mandatory fields :
- team_id
- stage_id
- tag_ids
- Optional fields :
- email_state (validity of the email_from field: correct / incorrect or empty if email_from is empty)
- phone_state (validity of the phone field !! not the mobile one !!: correct / incorrect or empty if phone is empty)
- country_id
- state_id
- source_id (UTM Source)
PLS uses a start date to consider only the lead created after that date to generate the frequency table
and to recompute the lead probability. This date is also configurable in the CRM settings.
Default start date is date.todays() (at module install).
The settings for PLS are NOT company related :
PLS Fields = Many2many to a model that store only the fields allowed for PLS computation.
PLS Start Date = Date
As Date and Many2many fields are not allowed for config_parameters,
Char fields are used to store the configuration
and Date and m2m fields are used to ease the configuration by the user in the config panel.
Date and m2m fields are both computed fields based on their corresponding Char fields.
Char field for Date store a strigified date.
char field for Many2many store a comma separated string which is a list of activated fields.
Each mandatory field is used in a specific way
- Team_id : the frequency table is split for every team_id, plus once for leads that don't have a team_id.
Considering Lead A from Team 1 and Lead B from Team 2.
Even if Lead A and Lead B have the exact same attributes (country, phone, email,stage, ...),
their probability will most likely not be the same.
That's because each teams compute their leads' probability based on their own won/lost leads.
- Stage_id : if no optional fields are activated and if there is no tag on the lead,
this will make PLS work quite the same way as it was working with removed stage based probability,
as only the stage will count in the computation.
But here, instead of fixing manually the probability for each stage,
this stage related probability is automatically computed based on past experience (won and lost leads).
- Tag_ids : each tag is considered separatelly, as if the lead had only one tag.
(no link between tag on same lead is made). To avoid that a tag take to much importance if his subset is too
small, we include the tag frequencies in the frequency table only if at least 50 won or lost leads had this tag.
The frequency table is a table where all won and lost leads are aggregated by fields
(mandatory or optional if activated). For each team_id / field couple, we store the number of
won and lost leads that has that fields values.
For example: Lead A is assigned to team 1 and client comes from France and has been won.
If we consider only this lead A, the frequency table will looks like :
id | variable | value | won_count | lost_count | team_id
--------+-------------+-------+-----------+------------+---------
1 country_id FR 1 0 1
To computed the probability of a lead, we get all the records for the frequency table
that match all fields (per team_id) and we compute a won score and a lost score.
The probability is computed and normalized based on those scores
- P = S(Won) / (S(Won) + S(Lost))
Considering two variables A and B :
- S(Won) ∝ P(A∩B | Won)*P(Won) = P(A|Won) * P(B|Won) * P(Won)
- S(Lost) ∝ P(A∩B | Lost)*P(Lost) = P(A|Lost) * P(B|Lost) * P(Lost)
To overcome the 'zero frequency problem',
we do not start at 0 for the won or lost count for each variable / value combination.
It suggested to start at 1, but to avoid that a small subset take to much weight compared to
a larger one, we start at 0.1.
For example :
If we start at 1 : If team 1 has few records from France,
it can get high probability to win even if every lead where lost.
variable | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
country_id FR 1 7 1 0.125
country_id FR 198 7306 2 0.0263
If we start at 0.1 :
variable | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
country_id FR 0.1 6.1 1 0.0161
country_id FR 197.1 7305.1 2 0.0263
The more we have records for each couple, the more the computation become precise.
The allow the user to decide himself which probability should be set on the lead,
a manual probabiltiy system has been implemented using 2 stored fields + 1 computed field :
- probability (stored): Probability set on the lead, can be set manually in the lead form.
- automated_probability (stored): Probability computed by PLS.
- is_automated_probability (computed): If both previous fields are equal, the probability is considered
as automatic. and each time the automated_probability is updated, the probability is aligned.
If both are not equal, the probability is considered as manual. The automated_probability is still
updated but the probability is not aligned. The user can reset the probability in automatic mode
by clicking on the estimated probability displayed in edit mode in the lead form.
probability and automated_probability are not computed fields as they are manually computed at write and create.
The computation is triggered if one of the activated frequency fields is modified or set.
To trigger also the computation when modifying the lead values on the lead views (form and kanban),
_onchange methods have been added for each frequency field.
Also, a cron has been added to run every day to rebuild the frequency table and to recompute all active
and pending leads (not won nor lost) probability.
Task ID : 1925439
PR #33589
remove rerun cron on action lost and won
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit improves the CRM reporting by:
- adding new field on the report model
- providing new predefined filters for users
- renaming labels to be more precise
- reorganizing filter and group by
- remove wrong measure in report (probability and days
to close), as they were not correct when multiple
activity on a lead.
Main purpose is to ease finding usefull KPI for the
user, and make the activity reporting a bit less
confusing and limited.
It also now include all user messages (discussion
subtype) and note from activity (when marking activity
as done) in the reporting, so we can have a complete
analysis of action taken on the leads.
Task-1862209
closesodoo/odoo#27767
Use crm.lead instead of a the crm.opportunity.report object for
reporting. This allows to show more fields (e.g. tags_ids). The only
field not accessible in the report is #activities, but there is a
deicated report dedicated to activities.
Improved the default search. Example: when reporting on leads, you want
leads+opps by creation date (and not only leads) as an opportunity has
been a lead created too.
This reverts commit ab65a02f5a.
Before that commit "Sales / User: Own Documents Only" had access to
self-assigned or without salesperson assigned leads.
With the change, user of this group were meant to also have access to
leads with an activity to which they were assigned to.
But:
- this is a different behavior from activities on other models.
- there is a technical disability that in some case prevent to have
fully functionning access rules if based on one2many with
auto_join=True (we will try to fix this in master).
opw-816246
closes#23085
Before this commit, when the sales person (user A) of a lead assigned another user (user B) to an activity
user B couldn't see the lead in his pipeline
After this commit, he can
OPW 787935
First purpose of this commit is to limit access on activity types.
Employees can now only read activity types. Indeed defining or modifying
activity types should not be done by employees as it impacts daily work
of all other employees. Specific app-based rights are added for project
and sale managers. Those have a specific menu to configure activity
types, meaning they should also have the access rights to do so.
Also including :
* ease default computation for res_model_id of activity types: using
default_res_model in context it is possible to specify a default
res_model_id. It is useful for example to give a specific context
in configuration menus;
* add a domain on res_model_id field in order to limit it to models
inheriting from mail.thread and not being transient;
* various improvement in activity type form view to ease configuration
notably the # days renamed to planned in;
Purpose
=======
You install CRM but you don't see CRM icon (except in English, as long as sales is not installed) -> confusing
The dashboard with salesteam is not obvious & not useful for simple users: what are those channel boxes about? why don't I see all my activities?, etc.
Specifications
==============
Split CRM & Sales + land in business views straight away
Default Entry Views
~~~~~~~~~~~~~~~~~~~
- New default view for CRM: Pipeline kanban
- New default view for Sales: Quotation list
Dashboards
~~~~~~~~~~
- Move sales teams dashboard to Reporting: Sales Channels.
- Remove the upper part of the sales team dashboard
Menuitems Structure
~~~~~~~~~~~~~~~~~~~
- CRM menu
Pipeline:
- Leads (optional)
- Pipeline (default menu, default filter "My Pipeline")
- Next Activities -> to remove (now there is an icon in top bar for next activities)
- Quotations (If sale_management installed)
Customers
Phone Calls (if voip, if not yet removed because there is a BE task to use next activities instead)
Leads Management:
- Scoring Rules
- Leads Assignation
- Team Assignation
Reporting:
- Leads
- Scoring page views
- Opp. Assignement
- Patnerships
- Pipeline
- Activities
- Phonecalls
- Sales Channels
Configuration:
- Settings
- Sales Channels
- Activity Types
- Leads & Opportunities:
- Lead Tags
- Lost Reasons
- Resellers
- Partner Level
- Partner Activations
- Sales menu:
Orders:
- Quotations
- Orders
- Customers
Invoicing:
- Orders to Invoice
- Orders to Upsell
Catalog:
- Products
- Promotion Programs
- Coupon Programs
Reporting:
- Sales
- Sales Channels
- All channels sales orders
Configuration:
- Settings
- Sales Channels
- Sales Orders:
- Quotation templates
- Payment acquirers
- Delivery Methods
Settings
~~~~~~~~
- Split settings form
- Remove recommended apps section
- Remove Timesheets section
- Remove Inventory Management and move shipping connectors to Shipping section
- Remove Integrations section
- Move Docsaway option to "Quotations & Orders", right after proforma
- Autocomplete and asterix: move to CRM section
- Restructure and rename sections this way:
- Product Catalog
- Pricing
- Quotations & Orders
- Shipping
- Invoicing
- eBay (if installed)
- Remove all the "Save this page and come back here" when checking a box that installs a new module
- restructure a bit the CRM settings, with 3 sections:
Pipeline
- Leads
Contacts
- Phone Validation
- Customer Autocomplete
Integrations
- Google Calendar / Synchronize your calendar with Google Calendar (copy from general settings but don't show message "Save this page and come back here...".
- Asterisk (VOIP)
CRM module depends on base automation only to have some automated
actions as demo data. To avoid having unnecessary dependencies
automated action demo data have been removed. This allows to remove
the dependency between CRM and base automation.
First step towards cleaning and improving automated actions is to
correctly name things. base_action_rule module is therefore renamed
to base_automation. Model is also renamed to base.automation.
crm.lead model now supports activities. Filters have been added to ease
their management. Mail activities replace the old crm.activity model. All code
related to crm.activity is then removed, including views and custom widget.
Standard activities feature is now used widely in Odoo addons and replace
those custom activities.
A small update is required in website_crm_partner_assign. Now the portal user
can only update or create its own activities aka assigned to him. If he has
an activity assigned to him it is displayed in the opportunity website view.
If not editing the opportunity will create a new activity assigned to him.
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.
1/ Add a stat button with history of activities (count of activities) on
the Customer form view
2/ Activity reports: When clicking on the list view, there shouldn't have any
group by (remove the Salesperson/leads group by)
- now possible to archive lost reasons. Indeed some reasons may become
unrelevant after some time.
- updated access rights on lost reasons: manager can create / update them
salesmen can only use them
- add archived filter
Among various small fixes, some changes :
- correct computation of default sales team, located in sales_team with a
small code cleaning. Rely on this method everywhere it is necessary.
- add a configuration option to enable the use of leads in sales team;
otherwise it is hidden
- better display of alias in empty list help;
- add a menu for next activities, that are the opportunities with an action
whose deadline is near assigned to the current user;
- automatic update of aliases configuration on sales team, based on whether
they use leads and/or opportunities;
- add a wizard to log the lost reasong when deactivating a lead or an
opportunity
[REM] crm: removed unused file crm_report_view.xml, containing
strange old views, probably some old reports. Those seems to be replaced by
the opportunities and activities analysis + the various dashboards and
graph views.
won: probability=100 (on lead)
loss: probability=0 and not active
Won / Loss Replaced most complex domains (merge leads wizard...) by active=True
[IMP] Code cleaning / removing:
unused report.crm.*
merged crm.lead.report and crm.opportunity.report (one report with domains)
[IMP] Cleaned demo data:
Won / Loss, Put back "New" stage
Removed "Marketing" sales team
[IMP] Removed Multiple salesteam setting (always multiple salesteam
Always display the dashboard (multiple salesteam)
No more option in settings
[FIX] misc fixes (bad domains), type not required
to define custom light workflows on opportunities.
Activities are linked to mail.message.subtype through inheritance.
This means that the follow mechanism works for activities. When
an activity is done, a message with the matching subtype is posted
on the opportunity.
Activities are internal by default. They are only visible by
employees.
A shortcut in the 'log a note' chatter option allows to post a
note linked to an activity (subtype).
- Several Modules have been splitted into several apps
Examples :
Human Resources : Splitted into Leaves, Recruitment, Expenses, Appraisals, Timesheets, Employees, Payroll
Marketing : Mass Mailing, Events, ...
Messaging : Chat, Agenda, Notes, Address Book, ...
- Generally, the related reports have been moved in the apps, as last menu
- Also, configuration menu (no_one group) have been moved into a config root menu
exception made for the warehouse and lunch modules
- Configuration for typical frontend modules have been moved into the website settings
Related modules : Ecommerce, blog, slides, forum
- When they are present, menus like 'product' or 'customers' have been moved
ex : Customers in Sales menu, Product in POS menu
- A lot of sequences and xmlids have been added or modified in this commit
- List of apps :
1 Chat : Inbox, Channels
2 Agenda : Calendar
3 Notes
4 Address Book : The view contact is still laying in the mail module (1 app => 2 icons)
5 eCommerce : Still to define : Config + Orders Analysis + Shipping + incoming Amazon module
6 Sales : Dashboard (Sales Team Kanban), CRM, Sales (note that they are splitted into 2 submenus)
Assignation, After-Sales (Invoicing and Services), Reports
7 Point of Sale : Dashboard (POS status), Orders, Reports
8 Project : Dashboard (Project Kanban), Search (all tasks, issues), Incoming Forecasts module, Reports
Project.issue.version feature has been removed completely
9 Members : Dashboard (Members Kanban), Report, Config
10 Timesheets : Time Tracking, Approvals, Reports
11 Purchase : Purchase, Control (Products and Bills)
12 Warehouse : Dashboard (Warehouse Kanban), Operations, Inventory Control, Schedulers, Configuration
13 Manufacturing : Same menu structure
14 Mass Mailing : Mailings, Campaigns, Reports
15 Events : Events, Reports
16 Lead Automation : Campaigns, Reports
17 Surveys : Surveys, Reports
18 Human Resources : Dashboard (Departments Kanban), Employees, Contracts, Engagement (Gamification)
19 Recruitment : Job Positions, Applications, Resumes & Letters, Reports
20 Expenses : Expenses, Approvals, Reports
21 Leaves : My Leaves, Approvals, Reports
22 Appraisals : Appraisals, Interview, Reports --> Will probably be modified by the incoming refactoring
23 Payroll : Current Menu
24 Lunch : My Lunch, Manager, Configuration
25 Accounting : Same menus currently, waiting the new accounting to be merged
26 Fleet : Current menu
27 Sign : Incoming docusign module
28 No root menuitem with this sequence
29 Attendance : Attendance, Reports
Sign in/out by project feature has been removed completely
30 Link Tracker (group_no_one) : Link Tracker, UTMs
New view added : URL Shortner, which is the frontend view embedded in backend
31 Versionning : Website domain, Versions, Experiments
32 Slides (group_no_one) : Channels, Categories, Slides, Tags
33 No root menu item with this sequence
34 Livechat : Channels, History, Reports
35 Dashboards : My Boards, Configuration
36 App Store : Local Modules, Apps, Updates
Last Settings : Incoming Dashboard Settings, Sales, ...., Website Settings
General Pattern for all modules' settings :
| Module_name
|-- Settings : General Config view (checkbox screen)
|-- Record setting 1
|-- ...
|-- Record setting n
Example for Sale module
| Sales
|-- Settings : Checkbox screen
|-- Quotations
|---- Quotation Templates
|---- Report Layout Categories
|---- Contract Template
|---- Invoice Type
|-- Contract
|---- Deduplicate Contacts
|-- Delivery
|---- Delivery Methods
|---- Delivery Pricelist
Before this commit, it was only visible by the admin user.
I used the crm.phonecall.report rules as an example, but I don't
think either of those or the opportunities ones are actually
used in the case of group_sale_salesman, because the submenu
Sales of the Reporting menu is only visible to the Sale Manager.
Fixes opw 615048.
This module tracks clicks in mass mailing mails and allow the generation of trackable links in a website interface.
Modules modifications
---------------------
Refractoring of the crm_tracking_* classes in a new module.
* Extract the crm_tracking_* from the crm module into a new module "utm"
* Remove the crm_mass_mailing bridge module
* New dependencies of mass_mailing and website_links to utm.
Nasreddin (bon)