- Activate multi-company, create companies A and B
- Set 2 companies on a user
When a message is sent (for example, thanks to the chatter), the
notification email always contains the logo of the same company,
whatever the company of the user or the company of the object.
This is a complement of commit 7a03f9ce93, applied to notifications.
Closes#20088
opw-772405
*im_livechat,rating.
Emojis are now encoded in unicode characters in messages. This
allows to copy/paste messages including emojis, ensures that
emojis are properly displayed in mail interfaces (at least those
that support unicode, e.g. GMAIL, counter-example: outlook), and
allows the user to directly use emojis of its smartphone in mobile.
This commit also adds several new emojis.
PR #11095
The goal is to prepare the removal of
'portal' module.
- demo portal user is moved into base
- 'is_portal' field on res.group too
- remaining security rule are moved to base too
- mail template is moved to website_portal
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
* Limit company image to match buttons size and avoid badly
sized image
* Add a margin below internal note notice because it currently
overlaps with actual email content
* Avoid having signature direclty included in message by
enclosing body in a div
Purpose
=======
External links in the data sometimes open in the same tab, the users loses times as he has to come back (and looses the context).
Specification
=============
Any external links in data (planners, settings) should open in new tabs.
The purpose of this commit is to handle code execution only in server
action and delegate schedule management to ir_cron model.
ir.cron model now inherits from ir.actions.server. Fields model, function
and args are removed as well as the logic to handle them. There is no
more code manipulation and evaluation in ir_cron, only a call to the run
method of ir.actions.server.
Cron form view use server action form view as primary view. This way
automated actions use the same base form as server actions with
cron details added.
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo for reviewing.
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
This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.
New models are
* mail.activity.type: used to categorize activities. Each type is a different
kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
available for all models using activities; or specific to a model in which
case res_model_id field should be used.
* mail.activity: an actual activity to perform. Activities are linked to
documents using res_id and res_model_id fields. Activities have a deadline
that can be used in kanban view to display a status. Once done activities
are unlinked and a message is posted. This message has a new activity_type_id
field that indicates the activity linked to the message.
This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.
Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.
There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.
Next commits will aim at integrating activities inside main Odoo addons.
Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.
Change color #a24689 to #875A7B
Commit https://github.com/odoo/enterprise/commit/8ac1c19fac7615fecd51e670f798d13158a4e53c
changed the odoo interface violet by changing the main LESS variable
but forgot there was many direct occurences in XML/HTML/... (for
example for the mobile browser color).
Even if it's community the odoo interface violet is used at many places
(module description, XML demo data, ...).
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.
Handle bounces using bounce alias directly in mailgateway. Previously bounces
were used only in mass mailing to update campaign statistics. Now the
mailgateway tries to find data from standard delivery status emails. This
data is used to update state of emails sent to customers, to display it in
the Chatter. It is also used to increment the message_bounce counter on the
bounced partner and bounced record, if any and if the field exists.
Previous more generic code that detect bounces is kept. This code is more specific
to standard delivery failure notifications by parsing its content.
As we will soon improve the sanitizer we will be able to sanitize email
templates body. However this implies some cleaning in the templates to
be sure mako is not considered as invalid html / xml and therefore removed
from the template body.
Currently no access button is displayed if the email is a discussion and has
no contextual actions like creating a new document, or setting the responsible
of the document. However it leads to emails being sent without access button.
This can be extremely frustrating and make the notification email quite
impossible to use efficiently.
With this commit when an user has access to a document the link to the document
is always displayed in the notification email.
When posting a comment after an answer in the forum, a mail
was sent to each subscriber with 'Re: False' as title.
In fact the title has to be 'Re:' + the name of the parent
record of this message.
When a mail is sent from the post, a link to access the subject
of the forum must be included in the mail.
opw:679073
When there are no available action buttons on the email (as Follow, View Task,
Convert to Opportunity), i.e. when the user/partner is not an employee, and
when the message subtype is 'Discussion', send a plaintext mail instead of
a formatted one.
Use case: Strange to receive a mail like this when you're on a lead and you
receive formatted mails.
Quote detection is now done in the sanitizer itself. It tags nodes that are
inside quotes (signature, text quotes, email quotes). The purpose is to remove
html_email_clean and have all the html cleaning / sanitizing inside a single
function. When a node is tagged, data-o-mail-quote is set on the node.
This attribute is added in the whitelist of valid attributes for the
sanitizer.
[REM] Support of shortening messages. The read more / read less will only
display or hide detected quotes and signatures. Shortening messages above
a given amount of characters is not supported anymore. Indeed it adds much
complexity to the sanitizer without adding much value to the result. The
primary purpose of the sanitizer is indeed to remove noise and unnecessary
content.
[TESTS] a lot of test are not necessary anymore, as read more / read less
display will be moved in the front-end and as the shortening has been
removed.Tests have therefore been cleaned and simplified.
[DEMO] mail: small demo update to include a bit quote detection
When editing an email template with the wysiwyg,
the `<` and `>` operators are automatically converted
to `<` and `>`, even for the Jinja2 conditions,
therefore breaking these conditions, and the render
of the email templates.
We avoid to use these operators in the email
template, so users can customize the notification
email template without having an advanced
knowledge on how to edit an email template containing
Jinja2 code.
Besides, the line return at the end of the email template,
just after the `% endif`,
is done on purpose as well: the wysiwyg adds automatically,
at the time of this revision,
`<p></p>` at the end of the email template source, but
this cannot be added on the same line than `% endif`,
otherwise this is considered as Jinja2 code, and it's not.
opw-659113
- vertically center date and messages separators in threads
- remove notifications in DM and livechat
- order mail demo data so that messages appear ordered (they are ordered by id)
- make sure that DM are pinned (they weren't on the receiver side)
- don't display DM until a message has been sent
- validate message body
- undo snackbar fine tuning
- fix Firefox scroll bug on sidebar rendering (the scroll position was often
lost when the sidebar was re-rendered, seemingly because the width of the
thread changed for a brief moment)
The template used for notifications is updated. The general layout
is now
header: logo -- action buttons, contextual actions
separator
body
signature
Sent by company using Odoo
- remove / udpate some paddings. Indeed some part of the notification emails
are badly aligned.
- postprocess the notification email to remove the content coming from odoo.
This ensure that action buttons present in some emails are not forwarded to
other people, notably customers. This is done by adding a div holding the
whole notification emails, with a summary = o_mail_notification. A summary
is used instead of a class or id because some html clients (like gmail)
strip classes, ids, ... summary seems to be kept in several clients.
Christophe Simonis