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.
To display author avatar to public user, using the /web/image url with res.partner returns the placeholder since public doesn't have access. Using the url on mail.message will display the avatar according to the access right defined on res_model/res_id of mail.message. However this executes mush query to fetch the avatar image (1 per message, against 1 per partner).
Maybe this wasn't a bug, but since it is a regression, this deserves to be fixed ...
* make CSRF protection the default on all non-SAFE methods
note: there currently is no way to call a CSRF-protected endpoint
without a form-encoded entity-body as that's the only place we get the
CSRF token from.
* simple CSRF token generation: just use the HMAC'd session id, no
generating a new random token per session then HMAC it
* use constant-time equal function to avoid timing attacks
* assert that a database secret is configured before hashing/validating
the CSRF token
* opt-out database manager from CSRF: The super-admin password serves
the purpose of a CSRF token in the database manager screens.
There is no request database to obtain the
secret and generate a CSRF token.
Transform POST param into GET param when redirecting to login page can cause security issues. Now, instead of displaying textarea (even if public user) and the redirect to login page keeping written comment, we display the login button with a redirection to the page to comment.
The redirection happen before commenting, avoiding to remenber param such comment text, rating, ...
To post a comment, the user must:
- be connected
- have a token
- or have a sha_sign
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, ...).
How great is it to get Odoo (almost) 9.0 (almost) translated?
Clean .tx/config file
Regenerate .pot files
Fetch current translations from Transifex (10% completion)
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
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
Introduced by 9abf7a2010
When clicking on the many2one edition button of the field "email_registration_id" in the
"event.event" view form, the return action id was not available in the action.
closes#8147
opw:647698
Replace deprecate controllers like /web/binary/image, /web/binary/saveas...
Use ETag for all content with 'unique' option to cache the content if the content is never changed.
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
Due to the fact the background color was hardcoded, it
wasn't possible to edit the colors of the button link
with the website editor wysiwyg
opw-646655
model has been renamed to mail.channel to prepare the slack modeling.
In future commits the mail.group model will be merged with the channel
model from im_chat. The first move is to rename mail.group into
mail.channel to have a model that will unite both features.
renamed to mail.channel.
At this point no model has been renamed; only files have been moved.
n mail, mail_group files have been renamed to mail_channel. The
website_mail_group addon has been renamed to website_mail_channel.
Some internal references have been updated (templates, linked files).
to mail. The only use was to update a method of publisher_warranty.contract
model that is defined in mail.
This code has been moved to the bridge module between website and mail
aka website_mail.
Dependency to share has also been removed.
The css of a mail is inlined as best as possible for the mail sending.
Previously, if there was a selector like .ch[onclick="ga(this,event)"]
the simple splitting would split in the middle and get one erroneous
selector (which then would trigger an error).
With his commit, rules containing " or ' are ignored.
opw-643548
Odoo Translation Bot