PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
Move the meeting stat button and kanban pill from CRM to Calendar, purpose is to
allow its usage even if CRM is not installed as this makes more sense since this
field is usually related to Calendar.
Increase query number limit in company leave test, in order to take into account
the newly introduced query in Calendar.
UPG-PR: https://github.com/odoo/upgrade/pull/2423
Task-2514473
closesodoo/odoo#69846
Related: odoo/upgrade#2423
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since e86f892a7b
We have the possibility to display a "lost" and a "won" ribbon on the crm.lead
kanban view.
In this commit, we change things around a bit:
- The "WON" ribbon was removed.
Since it was redundant with the stage anyway and not very useful.
- The "LOST" ribbon is now always displayed in the kanban view.
And not only when coming from "duplicate leads".
In addition, leads displayed when coming from the stat button on the
res.partner form view now also shows lost leads (active_test=False).
This can be helpful for the end user because he wants to know "all the deals
that are in progress/lost/won with this specific contact".
Task-2349526
closesodoo/odoo#67693
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When clicking on the stat button "Meetings" on a contact:
- before dac91bc18 (November 2019): only meetings with participant
matching contact name are shown
- after dac91bc18 (November 2019): all meetings are shown => this was
because the view was used to create new meeting, so it makes sense to
see other meetings and not have a conflict.
- after 16206d72 (August 2020): only meeting of the contact are shown
- after 7449c8a6 and d11fb611 (November 2020): more complicated logic
that will also show partner events, and child partner events.
Since August 2020, when you create a new event, since we are showing a
list of IDs at the time the button was clicked, the new event will not
appear unless you go back to the contact, then click on "Meetings" anew.
With this changeset, we still show a list of IDs, but add an alternative
to also show the events of the current partner (that should be in the
list of IDs, but will match new events).
opw-2374021
closes#61490closesodoo/odoo#61690
X-original-commit: eb6e03908bfb6ed8bbe231da2a4422ec2e149834
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create an opportunity for CH1 and a subscription for CH2
Bug:
The count of opportunities in C was displaying 0 instead of 2
opw:237344
X-original-commit: d11fb611fed3a8541d03b7d3e49973ae7c16a768
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create a meeting for CH1 and a meeting for CH2
Bug:
The count of meetings in C was displaying 0 instead of 2
PS: set() is used to avoid to count several times the same event for a partner.
If for example CH1 and CH2 attend to the same event, only one event must be counted for the
parent C
opw:2360155
X-original-commit: 7449c8a6643477742616bf236f2f2c90aec68581
Co-authored-by: nim-odoo <nim@odoo.com>
- Go to CRM > Settings and activate Leads
- Go to CRM > Leads and create 2 Leads with a different phone number
- Select the 2 created Leads and in Action menu, select Send email
- Make sure that "Lead/Opportunity: Mass Mail" is selected as template
- Send it
- Go to Contacts
2 Contacts have been created from the Leads, but both have the same phone number.
The issue comes from the override `default_get` of `res.partner` in crm module.
It is using `active_id` from context to fetch the Lead to populate Partner data.
This cannot work when several Leads are selected as the same `active_id` is used
for all of them.
opw-2333819
closesodoo/odoo#57638
X-original-commit: a84dcfb9475051082c6103f81bfa231ea50ed157
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Create a Meeting for Contact X
- Go to Contacts and open Contact X
The Meetings smart button shows 1, but when clicking on it,
all user & partner meetings are displayed.
opw-2320299
closesodoo/odoo#56753
X-original-commit: 70f441a7ee3d46f6ba25cf56529a972b9e7ab29e
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Create a Contact named "Alpha"
- Create another Contact named "Mister X" with "misterx@alpha.com" as email
- Go to CRM and create an Opportunity for Mister X
- Go to Contacts and open Alpha
The Opportunities smart button shows 0, but when clicking on it,
Mister X's Opportunity is displayed.
The Opportunity smart button displays a "crm.lead" view with a filter on partner_id.
The filter applies an "ilike" with the Contact's name on several fields of "crm.lead",
including "email_from".
As Mister X's email address contains Alpha's name, its opportunity is wrongly retrieved.
opw-2320299
closesodoo/odoo#56667
X-original-commit: 547cc14d7fc4f39a00bf7a05b781c1edfa050cf6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements.
Purpose is to improve lead_count performance. Some people claim to gain a lot
of queries: from 90 to 30 SQL queries to read 39 partners. Hard to reproduce.
LINKS
Task ID 2196182
PR odoo/odoo#44662
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
When clicking on stat button "Meetings" on a partner, just highlight the
partner meetings as is done for similar stat button instead of having
a domain that hides other event (so when creating meeting, we can take
into account other existing meetings).
A similar change with same reasoning has been done for "Meetings" stat
button of hr.applicant records.
opw-2131494
closes#40812closesodoo/odoo#40900
X-original-commit: 957e7eb77ed18e4a1c14ef4ef55bd54503c56f44
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
PURPOSE
Allow auto install of all SMS-based feature. Move partner onchange formatting
directly inside phone validation.
SPECIFICATIONS
Move the onchange on the phone field of contact model directly inside phone
validation to have it available in all SMS based applications.
LINKS
Task 2061765
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Commit f60825b439 moved phone validation addition on res.partner model
from a specific module to crm directly. However the inherit from the validation
mixin class was forgotten, leading to a crash when changing phone from the UI.
closesodoo/odoo#34545
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit moves phone validation from bridge module to crm directly.
This commit prepares the PLS feature (see next commits).
PLS needs the phone state to evaluate the probability to closes a lead.
So as crm will depend of phone_validation, the content of the bridge
module is moved in crm module.
Task ID : 1925439
PR #33589
- When merging leads that creates a partner, an error could be thrown
due to the `res.partner` `default_get` method that reads values from the
lead that creates the partner.
The issue is due to the fact that the `crm.lead` record is merged (and
unlinked), trying to read it will cause an error since the records
doesn't exists anymore.
This fix checks that the `crm.lead` we are trying to read from exists.
closesodoo/odoo#30895
Functional
==========
Sales teams become sales channels. Their dashboard cards now include a graph
displaying customizable data for managers (comparable to those in accounting).
By default, you now have the following sales channels (non-demo):
Direct Sales (with installation of crm or sale)
Sales Channel type: Sales
Works same as before, what's changed is:
- their cards display one big button directing to the start of their
workflow
- the links on the right-hand side have been reworked, and are only
displayed when there is at least one item requiring attention.
- 'More' tab remains unchanged.
Website (with installation of website_sale)
Sales Channel type: Website
Differences lies in the links displayed in the dashboard card:
- it displays abandoned carts, awaiting payments and payments to capture
Default Channel linked to all sales made from the eCommerce.
Point of Sale (with installation of sale and point_of_sale
-> auto-installs pos_sale)
Sales Channel type: Point of Sale
Linked to pos.configs and their pos.sessions and pos.orders.
- only links to their linked pos.config dashboard and open sessions
- can't use opportunities, lead or invoicing and can only display
pos.order data in the graph.
Default Channel linked to the default pos.config.
Technical
=========
- Add a channel type: sales, pos, website that have different actions/settings
- Add a graphs to the kanban cards in the sales/crm dashboard, configurable in
the form view in the new dashboard page.
- Rename sales teams to sales channels, rename and add default and demo sales
channels
- Change dashboard links depending on the channel type and add a related
computed fields on crm.team
- Rename strings and improve channel form view.
- Leads are now checked by default once activated for 'sales' type channels
- Disable checking "leads" without using "opportunities".
- Hide invoicing and invoicing target depending on channel type.
- Move currency_id to sales_team
- try to make better use of recordsets (and recordset APIs)
- remove pointless decorators
- remove redundant ensure_one
- make 'stage_find' a private method returning a recordset
- etc ...
Rather adding a group on the view to avoid Access
Error, than adding a try/except catching the
exception for opportunities and mettings count on
partner form view
- remove backward compatibility method `case_mark_won` and `case_mark_lost`
- change signature of `find_stage` method, by setting team_id optional, since
we can get if from `self.team_id`
- remove unused methods in crm_lead.py
- remove unsed code in base_merge_partner.py
- remove unused method in res_partner.py
Thibault Delavallée