Since https://github.com/odoo/odoo/commit/4330ea02676a4afd88707bb463a007e7de3c8686, action_mark_won was
not api.multi anymore, which made it impossible to mark leads as won in
batch.
The problem is that we do exactly this in the demo data.
As we need to keep the rainbowman in the interface the decision has been
taken to split the method in two parts, one for the interface which
returns the rainbowman (and uses ensure_one) and the second which is a
true api.multi method.
Thanks to @tde-banana-odoo for his advice on the matter
The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: this is the 11.0 version of #26912
opw-1877663
closes#26911
Display the field date_open in the crm.lead form view
Create a new record
Before this commit, there was a crash because since the record is a virtual one
there is no create_date, hence the crash
After this commit, we make sure we select records that have a create_date, and there is no crash
OPW 1877080
closes#26499
Because of 2917b38f28 which appeared in v9.0 but has not been adapted to the new API
afterwards, the early return was out of sync with what a search returns in new API
in v9.0: search returns a list, so must our early return
in v10.0: search returns a recordset, hence the fix
OPW 1878192
closes#26474
When merging two or more leads, a traceback was generated when attempting
to merge some selection field, if any.
closes https://github.com/odoo/odoo/issues/25644
opw 1864870
On the pipeline action change the sequence of the view_ids to
change the order of the view_mode string
Put tree first instead of kanban for example
Before this commit, clicking on CRM menu app still displays the kanban
This was because the action window is wrapped around a server action that modifies it
After this commit, we recompute the view list to match what is on the original action
OPW 1863425
closes#26159
in edit_dialog added 'default_type': 'opportunity' to context.
There was a bug in specific workflows of creating a new Opportunity resulting in the Opportunity saved as a Lead.
Infected workflow:
a) Create a opportunity from the Kanban view
b) Click in create and edit
c) Save the opp
d) from this opp create a new opp by clicking on create
The second Opportunity will be saved as a Lead
related to task #1857855
Purpose
=======
Currently, if we remove the salesman on the lead, the sales team will
be replace by either the sales team of the current user or the default
sales team.
That way, by removing the salesman, we loose information about the sales
team, and that way we loose information about the origin of the lead.
Specification
=============
Don't overwrite the sales team when removing the salesman on the
the lead.
The curent behaviour of the 'phone validation' module will only format a
number to the national conventions IF possible and will never block a
user.
The term of 'Validation' isn't suited.
Before this commit, because of 9d2f48d and abea8d3 and 4ebb5efac4
closed crm.lead with late activities wouldn't show.
Aware that this is essentially a choice of non-crucial behavior, there are some precautionary arguments.
- The three commits above make the choice of having a "clean" backlog:
late activities are not polluted by crm leads that are already won
- The choice of this commit is to count activities as late regardless of the state of the lead:
The use case: Close a deal with a partner > lead is won and closed
But it doesn't mean you don't have to call the partner back in a few days to actually sign a paper, organize some sort of meeting
The argument: it is better to not miss deadlines eventhough they might accumulate, rather than forgetting about them altogether
(but you don't script something to put all your emails as read when they arrive, do you ?)
OPW 744940
When a stage on crm leads is removed, the leads appear in an
"Undefined" column in a kanban view, but this was not handled when
getting the "graph data" (eg. in version 11.0 for sales team graphs
when grouping by stage in CRM > Reporting > Sales Channels).
opw-784455
closes#21507
- Create a user A
- Create a lead, assign to A
- Deactivate user A
- Duplicate the lead
A notification email is sent to A (user assigned to the lead).
Since the user is archived, he should not receive any email since it
might contain sensitive information.
opw-778825
1. on CRM module -> Select Pipeline -> Create a column (e.g. 'Test')
2. Edit this Stage
3. Toggle on the field 'Change Probability Automatically'
4. Set a stage probability (e.g. 50%)
5. Create an opportunity on this stage, using the quick create widget of the kanban view
=> The probability of the newly created opportunity is not 50%, as it should be expected
It takes the default_probability, using a default_stage_id, which is the 'New' column having initially a probability of 10%. The stage_id is correctly assigned to the newly created opportunity thanks to environment variable 'default_stage_id', but not the probability.
We solved this bug by updating the probability of the opportunity, after creating the object. We cannot do it at the same time, because BaseObject.create parse the missing fields in an order where probability comes before stage_id.
This fix is limited to the quick creation of opportunity by means of its name only. In particular, it doesn't overwrite the input of the user in the form view.
opw-772310
When creating an acitivity generating a calendar event, if
the model is not crm.lead (ex: sale.order), the default_get
will crash since no value for res_model_id is given.
This commit removes the strange selection box based on a magic flag and
some strange methods returning a string. Instead just allow to send mass
mailing on all models inheriting from mail.thread using the is mail
thread flag.
Various addons are updated to remove the _mail_mass_mailing class
attribute used to determine mass mailing capability.
We consider people could send a mass mailing on every model inheriting
from mail.thread. It makes no sense to limit it to a given set of addons.
This commit improves the use of mail activities by allowing their
integration with the calendar. Activity types now have a category
field that can be used to trigger some specific behavior. First
specific behavior is to have activity types of meeting category.
Creating activities of this type trigger a jump to the calendar to
schedule the meeting. Meeting activities and calender events are
linked to be able to easily navigate through the document, its activities
and its meetings.
Configuration is done using a category on activity types instead of some
hardcoded "meeting" activity to avoid issues with master data and to be
able to choose which activity type should trigger this behavior.
Linking calendar.event to documents is a good idea to allow searching and
filtering meetings. It also allow to have a link to the document from a
meeting and ease navigation.
There are currently some specific links (opportunity_id for crm.lead and
applicant_id for hr.applicant) but this commit allows some generic
document linking through a res_model_id / res_id fields pair.
RomainLibert