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: for 10.0 up to not including 11.0 which is fixed by #26911
opw-1877663
closes#26912
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
- 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
The previous code when "Manually Assignation of Incoming Emails" sale
config was set always set the alias prefix to "info" even if another
value had been previously saved.
opw-745174
closes#17305
When making a quick create for a crm.lead record, the field user_id is set
with its default value (introduced by aa44700dcc)
But the date_open('Assigned') was not set.
When creating a challenge with goal="New opportunities", the new opportinities
are counted with date_open. But when creating an opportunity with the quick create,
it was not counted as date_open was empty.
opw:742751
The filter on activity_date_deadline has been added during a fix, see
28c158cd13
It's incorrect for the computation of the 'Won in opportunities'
because it excludes opportunities not having activity_ids.
Furthermore, the way to compute the 'won' amount is not equals to the
filters when clicking on the button. Then, we need to keep only
opportunities standing in a kanban column having a probability of 100%.
opw-742489
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
Partially an incorrect forward port of 27b6451. Moreover, the shortcuts
"exp. closing" and "overdue" use the action
`crm_lead_action_activities`, which filters by default
`activity_date_deadline != False`. This should be used as well when
counting.
opw-725666
The mass-mailing App suffered from severe issues due to its inability
to detect and handle duplicates "at the email level", and the absence
of any global blacklist system, leading to lack of user trust.
Mailing-lists typically include multiple records with the same email,
and it is critical to avoid sending them the same email several times.
A related problem is the unsubscription of an email that is present
in other records (duplicates). Opting out the first email should
automatically blacklist it for other records as well.
Ideally we should have a global blacklist table in order to
share the unsubscription requests globally across models (Leads,
Partners, Mailing-list contacts). It would also allow importing
it from other blacklist systems. (TODO for master)
This commit introduces a partial solution, made of several
small changes:
- In mail.mail: double-check that an outgoing email has the
correct status (`outgoing`) before sending it. This allows
adding emails in the queue and cancelling them before they
actually get sent.
- In crm.lead: force predictable recipients for mass-mailing,
by always using the email of the lead rather than the email
of the linked partner when there is one. This simplifies the
computation of the blacklist and seen list. Other areas in
the codebase already assume as much.
- In mass.mailing:
+ Before sending out a mailing-list batch, compute the
blacklist (all opted-out emails) and the seen_list
(emails who previously received this mail) to make
sure we only ever target valid recipients.
+ While delivering the mass-mailing, any email targeting
an address that is in the blacklist or "seen list" is
canceled before being sent. The corresponding statistics
entry is considered "not delivered".
Also updates the "seen list" continuously.
+ When a mass-mail belongs to a campaign with the
"unique AB/B testing" flag, the "seen list" is
common to the whole campaign, as an extra safety.
+ Auto-delete mass-mailing test messages sent with the
test wizard, to avoid polluting the mail_mail table
Note: this fix uses a simple regex for efficiently extracting
the blacklist in pure SQL from different models, and doing so,
assumes that each record only holds a single email
(no comma-separated adresses). This should be sufficient for
most cases. The regex:
([^ ,;<@]+@[^> ,;]+)
Currently there are several issues with this configuration box
* default_<field> does not generate automatically ir.values anymore.
Defining default_model does not work since it is not linked to an
existing <field> in current model sale.config.settings. Checkbox
value is therefore not saved and lost at reload;
* box label is not clear as user may understand unchecking it drops
all aliases or email support. This is not the case as it is only used
to define an alias creating unassigned leads. This is a rare use case
where leads assignation is done manually;
* checking / unchecking the 'Emails' box does not have any effect on
default info alias. This is counter-intuitive as user asks to remove
the feature but it still works in background;
This commit fixes those issues by
* correctly setting the checkbox value in an ir.config_parameter so that
it is not lost anymore at reload;
* inactivating info alias by default;
* adding onchanges so that values are reset when unchecking checkboxes;
* updating string and displayed label and helps for the 'Emails' section;
* putting that Emails checkbox in advanced mode as it is a rare use case;
- 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
This commit improves crm.team compute methods and adds auto_join on:
payment.transaction: field sale_order_id
sale.order: field order_line
Also move the dashboard_graph_type field in invisible in the kanban view to
avoid triggering the computation of the graph when it's not needed.
DO NOT FORWARD-PORT: a different patch will be made for the master branch
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
split fields_view_get() and used an abstact mixin class in place of of FormatAddress
[IMP] base: added a m2o field (ir.ui.view) on res.country to decide the layout of the form view to input addresses.
Christophe Simonis