Default mail.alias for crm.team are currently recomputed/modified
when *setting* use_leads on the team (type changes from opportunity to
leads), but not the other way around (*unsetting* use_leads doesn't
rollback type to opportunity).
Fix this issue.
Leaves over the issue that *disabling* the global setting doesn't
recompute aliases, which it probably should.
OPW-728690
- Install a language different from English, set it to your user
- Merge two opportunities
The merge message which summarizes the operation contains the name of
the fields in English.
opw-708381
Based on odoo/odoo@ec6a6782
This commit fix opw-692280
Override from _merge_data in website_crm_partner_assign add 3 fields to
the list of fields to merge.
Before this commit, 3 fields was added at each merge and so the chatter
become very long with many duplicated field.
Bug introducted by migration new api.
There is now a single method easier to inherit to add specific behavior
for the display of access button as well as actions buttons. All addons
using this mechanism are updated accordingly.
Before migration:
'phone': customer and customer.phone or lead.phone,
After migration:
'phone': customer.phone if customer else self.phone,
So if a customer exists and that it has no phone, the phone
on the lead need to be preserved during convertion in opp.
The dictionary `_group_by_full` is replaced by a field parameter `group_expand`
that is assigned to the method name. The API of the method has been simplified
as well:
@api.multi
def _read_group_stage_ids(self, domain, read_group_order=None, access_rights_uid=None):
# the stages are given by self.ids (wrong model);
# read_group_order is the order given to read_group() on self;
# return stages.name_get(), {stage.id: stage.fold)
_group_by_full = {'stage_id': _read_group_stage_ids}
is now written:
stage_id = fields.Many2one(..., group_expand='_read_group_stage_ids')
@api.model
def _read_group_stage_ids(self, stages, domain, order):
# stages is a recordset;
# order is the order to use on stages' model;
# return a recordset which is a superset of stages
Starting from 32fb2f0940 if a lead is
already assigned to a partner instead of returning the already assigned
partner we ignore that, possibly reassign the lead and return either the
new assignment or ``False`` (if not in action=create and no partner_id
was provided).
This seems like an error which passed through and was never noticed as
the method isn't called much and only from wizards.
Either way, revert that. And remove the comment which apparently was
never updated.
In the new API, ``name_get`` doesn't normally lose sort information
anymore: the result of ``search`` (or ``browse(_search)``) is correctly
ordered and ``name_get`` sequentially resolves record names.
Thus the post-facto re-ordering mess should be unnecessary,
``records.name_get()`` will be ordered as ``records`` is.
- 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
crm.activity inherits mail.message.subtype with the field subtype_id
Before rendering "chatter.ChatComposer", the internal subtypes are fetched
on model mail.message.subtype(in function "fields_view_get").
But when deleting a crm.activity, the linked mail.message.subtype was not
deleted.
Used case:
When deleting a crm.activity, the activity still appeared in the chatter
if you log an internal note for an opportunity as an employee.
opw:670654
Activities in opportunities are now handled through a wizard and not through
the form view anymore. The wizard is called via a Log an activity button. The
wizard allows to log an activity and to schedule the next activity. It
replaces the various <next activities> / Done / Cancel link buttons on the
form view that nobody seemed to inderstand.
This reverts commit ab303435d3.
Changing a feature one week before freezing a new saas, without review,
without spec, without testing, does not seem to fit the R&D process.
This commit will be set in a branch, tested and reviewed accordingly.
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).
Xavier Morel