* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
- Install Invoicing
- Multi company Set up with no common contact book
- Create & validate an invoice with user A in company 1
- Change to company 2 with user A
- Connect with user B in company 1
- Send & Print the invoice
An error is raised on the template rendering because user B cannot read
info from user A.
opw-1928676
closesodoo/odoo#30649
opw-1916935
Before this commit, when a next activity was closed, the message said
that the action was performed by the assigned person.
Now, the message say that the action was performed by the person who
closed the activity.
closesodoo/odoo#29678
Do not use the model `_description` field which cannot be translated. Use
the `display_name` of the corresponding model instead.
Moreover, `<t t-esc="'%s' % model_description or 'document'"/>` gives
`'None'`, while `'document'` is expected.
This adds a query to some tests, which is expected since `display_name`
requires information stored in the DB, while `_description` is defined
at the Python level.
opw-1908420
Feedback should be the first part of the message without title
to make it more concise.
If the activity has a note, the note should be displayed
but after the feedback.
We can also remove the field feedback that was not so useful
since it was only written just before unlink. Feedback is now
passed as another parameter to the template.
Task: 1918392
closesodoo/odoo#29605
As activities are created using the current user there is no need anymore to
have another field to store the activity creator. We can therefore remove
create_user_id and replace its use by the magic create_uid field.
This commit is linked to task ID 1856417 and PR #27619.
In a multiple company account, when a parter is doesn't have a
company, the mails he revieved have "Send by using odoo" as footer.
This PR correct that by setting the footer to "Send using odoo" when
there is no company.
opw-1894825
Some people do not understand the old forgotten langage coming from R'yleh
sub-city of Helk'Yizrk. Let us use standard naming then.
closesodoo/odoo#28196
Purpose
=======
display_name is equal to doing name_get()[0][1]
Replacing name_get()[0][1] by display_name could be good for 2 things:
- Uniformization of the code
- Probable optimization if name_get is used inside a for loop on a recordset (as the values will be prefetched and put in the cache).
TaskID: 1849250
closesodoo/odoo#26341
The mail template mail_template_channel_send_guidelines should only be used
from send_guidelines action. Anyway, with mail_template on activity
and all demo done to show this mechanic on contacts,
trying to render this one will generate a traceback. This fix
transforms the mail_template to qweb view so that it won't be available in
mail template.
Flow
====
Have one model field responsible of telling when the sales order has to be signed or paid to avoid inconsistencies.
The general rule is: sign & pay are only used upfront to confirm a sales order. If a sales person starts to modify (confirm) it manually, we don't need those features. Especially at that point pay should be done with invoices.
Modal
=====
For the sign, we want to force refresh the page to update its state, and thus we need to show the confirmation message on the reloaded page.
For sign and pay, we changed a bit the structure of the text in the modal to allow to translate it more easily. Also fixed the payment selection by moving it into the body instead of the footer.
For the reject modal, we want the feedback field to be required, so we can see in the chatter by who and why it has been rejected.
Misc
====
Moved remaining bits of code related to preview/pay/accept/decline from sale_management into sale, where it should have been in the first place.
Sales Order:
- Improved status/contextual alerts.
- Hide discount from small to fix responsive.
PR: #26801
task-1876864
remove sales help
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes#25629
When someone assigns an activity to another user it is a good idea to
notify this user a new activity has been assigned to him. This is done
using the message_notify method that sends a notification either in the
Inbox either by email depending on the user preferences.
This commits is linked to task ID 1854820. Closes PR #25265.
Purpose is to avoid having '/' in record name. This is generally considered
as being an URL and leads to a specific display in most email readers. In
this commit we therefore remove '/' by '-'.
A use case is the name of payment receipts.
Font sizes in light notification template are also standardized to 13 and
11 px to better match the chatter layout. Emails are still bioutifoul.
This commit is linked to task ID 1843376 (and 1868112) and to PR #25349
(and #25889).
This commit introduces a new notification template. Its target is to be used
when sending payment-based templates like 'Send by email' for sale orders,
invoices or purchase orders.
Purpose is to separate the template content (payment information) from the
payment button (Pay and sign online) when sending those documents by
email. Composer and chatter should not hold the button. It should be added
only in notifications emails.
Technical solution is to have a somewhat-generic template available in mail
to be used in some specific actions. Another solution is to hide the
button but it breaks if people edit or remove the hidden content when
editing the mail in the composer without knowing it. As the button is
mandatory in those actions we choose to have it added by the notification
email.
Future commits will gradually use this template in some addons.
This commit is linked to task ID 1860049 and PR #25824.
----------------------
Summary
----------------------
The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.
Here is a short summary of the changes that have been made:
1. New coding guidelines
- snake_case to camelCase
- prefix private attributes and methods with '_'
- jsdoc on most methods
- one class per module
2. Rename/Merge some classes
- 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
- 'chat window manager' is now included in mail manager
- 'thread' widget now named 'thread widget'
3. New model abstraction for mail objects:
- modules 'mail.model.*'
- modeling:
0..1 0..1 * *
ThreadWindow <------> Thread <-------> Message
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread: the superclass of threads.
- ThreadWindow: the window component of a thread.
- Message: mail objects representing messages.
- Thread With Cache: threads that can be used with search view (Discuss app compatible).
- Document Thread: represents the thread part of a chatter.
- Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
- Channel: mail objects representing channels, including livechat.
- DM: special kind of Channel for 1:1 communication in the backend.
- Support Channel: special channel for im_support module.
This new modeling approach let us easily add features on all threads, such as the
possibility to put any thread in a small window.
----------------------
Known issues
----------------------
[Already Present in Master]
1. When the Discuss app is in the background with 'Inbox' as the selected
Thread, when clicking on a document thread preview in the messaging menu
of the systray, the rainbow man appears.
2. When a document with the chatter is in the background, when receiving an
inbox notification from this document thread, the document thread is
automatically marked as read, which removes the notification right away.
3. Sometimes, opening a DM window from the "blank" thread window does not work.
4. Reply-to feature on Inbox is not working: no message is sent in the document
thread.
5. On the first login of admin user with demo data, the inbox counter is wrong
(it displays 6, instead of 3).
Explanation after investigation:
> On page load, it fetches the correct number of Inbox messages (3),
but the server notifies of 3 needaction messages right away,
so it wrongly assumes these are new needaction messages.
> Not possible for web client to detect that these messages should not
increment the Inbox counter while keeping same API.
6. Notifications for new document thread messages only work when the user sets
'handle with Odoo' for the Notification Management in the preferences.
> due to notifications on the longpoll bus for document thread
messages that come from needaction notifications.
> requires server-side changes to send notification on the longpoll
bus to mentionned user.
[New]
7. When receiving a message on a unjoined channel, thread window flickers
('open' > 'close' > 'open')
Explanation after investigation:
> JS logic:
a) On auto-join, ask server to join the channel and get channel infos.
b) The info tells the channel is not detached, but JS code makes decision
to detach it, and tells server the channel is now detached.
c) From (a), server notifies on longpoll bus the state of channel, which is
not detached. The web client thinks that the window state of the channel
has been changed somewhere else, and the channel is now closed.
d) From (b), server notifies on longpoll bus the state of channel, which is
detached. The web client opens the thread window of this channel.
> The flicker didn't occur before refactoring because the web client was only
updating the model of channel when it receives the longpoll notification.
> Server behaviour on 1st longpoll notification is necessary for cross-tab
synchronization for channel window state.
> New design implies that model and view should be synchronized, hence the
issue now.
> Solution: remove server-side thread window synchronization and replace with
client-side synchronization.
----------------------
Hacks
----------------------
The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:
Modeling for messages:
AbstractMessage
/ \
/ \
LivechatMessage Message
- AbstractMessage: message compatible with the thread widget.
- LivechatMessage: message used by im_livechat.
- Message: message used with the mail manager.
Modeling for thread windows:
AbstractThreadWindow
/ \
/ \
LivechatWindow ThreadWindow
- AbstractThreadWindow: behaviour share between all types of thread windows.
- LivechatWindow: window used by im_livechat.
- ThreadWindow: window used with mail_manager.
The reason for these hacks are twofold:
1. Use the thread widget in the frontend and livechat external lib bundles.
2. Do not have a dependency with the mail manager in the frontend and external
lib bundles.
* increase logo size, because big logos are necessary;
* correctly set cellpadding / spacing to 0 to avoid loosing some pixels
when having several embedded tables;
* remove summary mail_notification as it should be used only to some
customer-specific part of emails;
This commit is related to task 51122 (and PR #24052).
Purpose of this commit is to allow moderation on incoming messages in
discussion channels. On some channels on which moderation is required
messages should be in a pending moderation stage. Moderators can accept
or refuse messages as well as always allow or ban messages coming from
a given set of emails.
Channels now have an option to be moderated. Moderators can be added on
channels. They have access to a specific UI in Discuss to see and take
action on messages waiting for moderation.
Concerning mail.thread message that are pending moderation are not notified.
It means nobody receives a notification about them. Moderation process calls
the notification once the message is validated.
Various features included in this commit :
* a model is added to store the decision about emails, allow or ban;
* access rights are updated so that only moderators can modify moderation
fields on message;
* specific bus notifications are send to moderated people as well as to
moderators on incoming emails as well as when a decision is taken;
* options are added on channels to send explanations to moderated emails;
* options are added on channels to write and send guidelines explaining
why and how moderation is performed;
* a reminder is send daily to moderators with remaining messages to moderate;
* discuss UI is adapted and a new channel is added below Inbox and Starred
giving access to moderation tools;
* chanenl UI is adapted allowing to moderate directly inside channels;
This commit is linked to task ID 29521. Closes#21921.
Purpose is to avoid mixing various data types in the same generic mail_data
file. We already have 2 crons and the upcoming moderation feature will add
some more. Let us put them in their file to ease the finding.
This commit is linked to task ID 29521.
Activities are quite personal and linked to daily jobs of people using it.
Being notified of all activities is therefore not considered as default
behavior and should be a choice done by users. Subtype linked to logged
activities is now not followed by default anymore. It is still configurable
through subscription widget or parent subscription (project/task for example).
This commit is linked to task ID 1824141.
This commit adds a new QWeb layout mail_notification_light. It is a new
lighter template using more modern styling. Its purpose is to be used as
a basis for all future templates used in notification mechanism (chatter,
sale orders, ...). During some time all templates will exist separately.
Future commits will gradually improve or add various notification
mechanisms. This new template will gradually be used more often in order
to replace old ones.
Thanks to @est-odoo for its in-depth testing of the template.
Notification emails now use QWeb to be rendered instead of jinja-based
mail.template since 2f7593761c. Part of the notification emails was not working
anymore since its syntax was still using jinja. This commit fixes that.
This commit also removes strange ';' that should not be part of python code
as well as an unnecessary variable propagation.
Various modules use another template when sending notification emails
for some specific case. For example sending sale orders or invoices
using the 'Send by email' button encapsulates the content in a layout
different from the base one.
As all modules basically uses the same copy-and-pasted template we choose
to define another email template directly in mail.
In this commit we change notification templates used to render
notification emails from jinja-based mail.template to pure QWeb
templates.
There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
template people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This commit does not change the functional purpose and layout of the
templates. Behavior should be the same before and after this commit.
Notification emails contain a link allowing to follow or unfollow
documents directly from the notification email. However there are
several issues with this button
* it require people to login to follow or unfollow documents;
* it is not linked to the email;
* if the customer does not have a login it is not possible to perform
the action;
* there is no confirmation step;
This commit removes the follow / unfollow button in the notification
emails. Indeed as people have the "Access document" button there is
only one more click to perform in order to subscribe or unsubscribe.
Concerning customers adding a complete control of the follow mechanism
would be costly in term of code and access rights checks. We therefore
decided to remove this button.
It also allows to simplify a bit the notification process as there
are less parameters to take into account when grouping recipients. It
allows to lessen the number of required template rendering when sending
notification emails.
Using xml type it allows to have a cleaner view of the content in a classic
code editor. This commit also fixes some xml-related invalid stuff that
does not impact the notification email rendering.
- 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
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.
Christophe Simonis