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
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
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
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
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.
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.
Christophe Simonis