Main addons updated :
- crm: Conversion and Won / Lost actions
- hr_holidays: Approve / Refuse for hr users / officers
- project: Assign / New (task and issues)
- forum, website_project_issue, website_portal_sale: go to the
website view
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.
The biography of established users (with high karma) can be seen
with an expanded tooltip. This gives to users that participate
some kind of reward and gratitude of their work.
- remove tags translatability
- add unique constraints
- res.partner.category is kept until we remove the parent_store test.
- hr remove tag parenthood
- hr remove unsed views and menu
During conversion to new API[1] the superuser bypass
was dropped in the computation of karma-based
permissions on forum posts.
The check still needs to be bypassed to avoid
blocking sudo() mode when the admin account
has a low karma.
sudo() mode is used for various actions done
by the system on behalf of the forum users,
and should not fail because the admin has less
karma than the user herself.
[1] See rev. 893d7fa864
Saves 2 requests per post, aka 20 requests on a full page (89 -> 68):
* don't create a new sudoed env and recordset for each post, create a
single one so prefetch can work
* don't do unnecessary sudoed access (.parent_id.create_uid without
reading any field)
* temp variables in template seems to save a few queries, not sure why
There's still a linear growth of requests wrt posts in the
page (single-post page has 56 queries), but it's a bit less terrible.
Access rights on messages are derived from the
access rights on the documents they are attached
to. Due to the karma-based nature of the forum
access rights, these do not automatically reflect
on messages, because they are not implemented as
access rules.
The check_mail_message_access() needs to be
overriden to achieve the same effect.
+ allow calling super().check_mail_message_access()
from new API (useful in forward-port)
This behavior is not the default behavior to remain consistent with
the previous behavior of the sanitizer.
website_forum: when converting a post into a comment the html is now
completely sanitized instead of parsed into plaintext. Inded comment
are mail.message, thus holding html content. Styling and classes are
removed to ensure only the basic html pattern is kept.
When a user's karma is driven to a negative value
due to repeated abuse or the posting of spam,
automatically hide all their posts from public
view.
This will reduce the effectiveness of their abuse,
and simplify moderation and cleanup.
For public-facing HTML content provided by the user,
`<style>` tags and `style` attributes should be stripped
automatically, as they can easily be abused to deface
pages for abusive users and spammers.
<style> tags were already stripped, the optional `strip_style`
for fields.html enables the automatic stripping of style
attributes.
This is opt-in because custom style attributes are still
desirable in trusted HTML fields.
post model. Indeed a post is a question, a link or a discussion and cannot be
something else.
Added constraints to avoid having posts that do not match the accepted types
on the forum; and to avoid having forums having a default post type not
matching the accepted ones.
A widget based on website share widget has been added that allows to share
questions and answers on social networks. Old posts can also be bumped
through sharing.
New fields have been added on forum model allowing to disable the old
question bump and social sharing modals.
Courtesy of RD India: Ajay Patel (apa@odoo.com), Jaysinh Shukla
(jsh@odoo.com)
Courtesy of use Merge: Damien Bouvy (dbo@odoo.com)
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
When comment is created, emails are sent with subject: "Re: False" and footer: "About Forum False".
Now, when the post is a comment, we fallback to the name of the parent (the main forum post).
on links in forum posts.
This is now done when creating / updating posts instead of updating the display
of the post. This means that old posts may contain nofollow attribute altough
the user has sufficient karma; however it is acceptable compared to the computation
we save by avoiding processing every post to display.
way links displayed in posts and answers. A nofollow attribute is
added is the author has not enough karma, adding a protection for
spammer tryign to improve their SEO.
Martin Trigaux