Message are now fetched and display using javascript
to optimize performance.
Also the chatter is completely rewrite : add pager,
filter possiblity, ...
This commit is mainly technical: posting feature does
not change. Only the display with pager is new.
The goal is also to prepare frontend chatter for a
better integration with rating widget.
The mail.thread mixin is extended to manage the field
website_message_ids (display all messages that can be
seen on frontend by user (employee or not).
When fetching or posting message, a check is done to see
if we need to do it as sudo(). website_mail implement posting
messages with token or sha_in (using in website_quote).
The same verification is now done when fetching messages, via
'_special_access_object' method.
Indeed through portal users can post a message. Form used in order to
do so include a csrf token. However this one should not be propagated
to message_post because it is not a mail_message model field.
This creates unnecessary warnings.
Closes#13956 .
The _message_post_helper() method historically allowed
passing a `sha_in` signature to let an unauthenticated
user post a message on a record.
This option is unused and an alternative is preferred:
passing a `token` value that matches the value of a
given field of the record.
In light of the increasingly grim future of SHA-1
as a cryptographic hash function, we consider it
better to entirely remove this specific option.
It has been unused for a while, and a simple
alternative exists.
As a temporary measure, the feature was also
deactivated in 10.0 at 2cffcfd860
The _message_post_helper() method historically allowed
passing a `sha_in` signature to let an unauthenticated
user post a message on a record.
This option is unused and an alternative is preferred:
passing a `token` value that matches the value of a
given field of the record.
In light of the increasingly grim future of SHA-1
as a cryptographic hash function, we consider it
better to entirely remove this specific option.
It has been unused for a while, and a simple
alternative exists.
The `object_shasign` method itself will be dropped
in master.
Previous commit (3304b31938) was not performant enough for AL, so got special autorization to make a particular controller for mail.message author avatar. Avatar of message is avaiblable if current user has 'read' access right to the document. Otherwise the default avatar is one white pixel.
Add 'force_display' param for the frontend chatter to allow public user to see the textarea. When submitting his comment, he will be redirect to login page (like it was before generic chatter) in both mode (json and post mode). This required changing the error handeling of json mode : when a login is required, the user switch to post mode to allow http redirect, keeping its submitted params (rating, comment, ...).
Notification emails have been redesigned. They notably include buttons
allowing to perform some action directly from the email.
The notification creation and sending has been partially rewritten
and improved. The purpose is to lessen the number of rendering to perform
when sending emails to recipients. Recipients are first categorized into
groups. Basic groups are partners and users. The notification template
is then rendered twice, one for followers and one for not-followers. In most
cases there will be few rendering to perform. Through inheritance it
is possible to further categorize users. For example HR users / officers
that have approve / refuse buttons in their email.
A custom data structure is used to store data about buttons and actions.
URLs, follow / unfollow are added in the structure and used in the
template to render the email for a given group.
New routes are added in mail. Those allow to perform some action, like
going to a form in create mode, following / unfollowing, executing a method,
sending a signal for a workflow. Those routes are for users only and rely
on classic access rights.
A generic route for viewing records is added. It replaces the old redirect
action. According to some specific action given by the already-existing
get_access_action, the record will be visible for everybody (forum, blog)
or restricted (going on the Inbox / login / form view, according to access
rights).
The next commit will add the various inherits necessary to add the actions
in the main addons.
When subscribing a document, a partner is created based on the email address.
Instead of using the email address as the name (which is a bit too spammer
friendly), only keep the first part of the email address as a name.
Following discussion https://www.odoo.com/groups/59/13640169
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
A new generic chatter template is available in website_mail
This template allows access rights escalation when some kind of token or uuid
is available on the model or if you use the object_shasign function in the
main controller of website_maill to generate a cryptographic signature to allow
commenting on any object.
To use this chatter, you need to make a t-call to website_maill.thread in your
template after having set the following variables:
- chatter_object: the browserecord of the mail_thread object (mandatory)
- token: if you use a token system (optional)
- token_field: name of the field that stores the token on your object (optional)
- sha_in: if you use a shasign to allow public comment (optional)
- nosubscribe: set False if you want the partner to be set as follower of the object (optional)
- message_type, subtype: see message_post in mail_thread.py
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
The menu was not present in 8.0 when going back from the mass mailing email
composer to the backend. This fix adds the current action id as a return_action
query string parameter and return to the correct action.
fixes#5591
opw-629526
1. The merge of the "email_template" module into the "mail" module.
2. The send action of the mass mailing has been moved from the frontend to a cron, because it was too slow to send over 10,000 mails (the user's browser was blocked for 15 - 20 minutes). Mass mailings have now their own process in the kanban view.
3. Mails sent from the mail form are sent immediatly instead of from the mail queue (for instance, when you go to sales > customers > list view > select 2 -3 customers > More > Partner Mass Mailing).
4. Users have now the choice from which mailing list they want to unsubscribe when they click on the unsubscribe link at the bottom of the mail.
5. Mass mailings inherit from their campaign UTMs and mass mailing campaigns are linked to an UTM campaign.
6. Many little improvements
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Main modifications :
- layout: input - button when not following, links (email - archives - unsubscribe) when following
- when adding your email, update all other subscribe snippets input in the page to avoid havign to re-type it
- management of fields of the record to subscribe to, used to have access to the alias of the group
set of fields that we try to edit (body_html and body for body, email_from and email for
email-from, name and subject for subject), because t-field is not dynamic. If the model
that should be edited does not hold those fields, the mail editor won't work.
Also fixed editor not being actiated when going into the body edition.
bzr revid: tde@openerp.com-20140416105901-vavkh9erjsq4mof9
- now body_html is a right field on mass_mailing, editable using the website
- email_designer controller / template now works on everything that has a body
receiving its model and res_id as post parameters; it does not work only on
email tempaltes anymore
- cleaning of the mass mailing form view: reply_to managment option (either
replied go into the document, either there is a specified reply_to; it is implemented
using boolean fields instead of a selection because all options are not available
for all models ... models like contact or partner do not have a chatter or
shoudl be be used for a chatter-like use)
- send to all now instantiates a mail.compose.message; the mass mailign processing
is delegated to the wizard itself.
bzr revid: tde@openerp.com-20140407170346-hpklabi513xskd07
Christophe Simonis