Before this commit, a JS widget would be instanciated for every `.js_follow` on
the page.
Every widget would then perform a RPC to know if the object was followed.
That would be an issue if there was too many `.js_follow` on the DOM.
Eg: on the forum tag page (/forum/1/tag), there might be unlimited tags. This
is where the biggest issue is ATM, on Odoo.com we have over 5500 tags,
which performs 5500 RPC.
Your browser will most of the time just crash.
This commit improves that behavior by sending only one RPC to get the tags info
in once.
With 5000 tags, there was 5000 RPCs, now there will only be one for the tags.
Also, each RPC were doing 8 requests each, so this will bring requests from
40.000 to 80.
Fixes#45576closesodoo/odoo#46278
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.
In this commit we
* remove unnecessary code examples in gamification about followers: using
that model as example of code for goals is probably not a good idea as it
is technical;
* rewrite routes called by JS are simplified to better match JS
implementation;
* introduce computed fields to fetch related partner or channel name,
email (partner only) and active status;
LINKS
Task 1933771
Task 2078313
closesodoo/odoo#39808
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Without this, it will crash since self.env does not exists in a controller.
Using request will still crash later since `check_followers` does not exists.
Introduced with 957c99abd5
Found while working on task-2152191
closesodoo/odoo#42509
X-original-commit: 70e4a716feda7acb7385a98ac51ab40dabc3f50e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
`self` is a controller, not a model, thus we use the request to get the
environment.
opw-2160614
closesodoo/odoo#42350
X-original-commit: ac456d8d12bfc26addb3f097aa5552176f6fb765
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Purpose: make some methods from mail.thread mixin private and update their
naming if necessary. Some methods prepare data for business flows and deal
with internal information. Public methods should either use of give some
access to those methods. Computation itself should be keps internal.
In this commit we put message_partner_info_from_emails as private. As it is
used in discuss JS we define a controller that controls access to this method.
It explicitly checks for related document access rule and rights before
calling the private method.
Some addons are updated accordingly to the method change.
Related to task ID 1911679
Linked to PR #29483
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
Romain Derie