update can view, to remove deleted post from sitemap and make controller unavailable for lambda user.
Only Admin, and users with enough karams can continue to see them and undelete them.
Code introducted by commit f39e535 was ignoring the value.
Now, we change the logic to always have True as value regardless the operator.
!= False become = True ...
Add filter in domain converter to remove some posts in sitemap.
Avoid to add in sitemap some pages that could not be read
by public user due to a karma restriction.
A partner can be associated to multiple users.
The condition checking the partner
user has enough karma should therefore
handle it. The previous condition expected
a singleton (only one user for the partner).
With the condition before this revision,
a partner with multiple users could
simply not post new questions on the forum.
opw-667894
If a tag with an empty name was existing in database, the controller /forum/forum_id/tag
return a server 500 because tag.name[0] from an empty string raise a traceback.
The links present in forum messages are parsed to integrate "nofollow"
attribuate in it.
In case the content of the link contains some special char (e.g. <a>foo)bar</a>)
the regex fails as it interprates the content as an invalid expression.
Better message management, linked to the validation feature added in v9
- post a "new post to see" message only when the post is validated
- post a "new post to validate" message when the post has to be validated.
This message is sent only to followers having sufficient karma.
Remove forum creator as follower of the forum. Indeed this means that generally
the website admin will be follower of all posts of this forum. Which is
probably not really necessary.
As this method is overided in several modules, the mix of new and
old API makes it difficult to handle. Indeed in some cases we
receive the expected dictionary, sometimes in a list, sometimes
in a list of list, due to api.one decorator.
This is a change in the method API, however it is currently completely
buggy. Moreover this method is used internally and should not be
used as an external API. Lastly, this method is new from v9.
The read_group collating user badge counts is extremely slow when
there's a large number of users (possibly even slower than 8.0's naive
approach), replace the whole thing by a single SQL query seems to yield
pretty significant (~2 orders of magnitude) performance improvements on
the computing function resulting in ~1 order of magnitude improvement
for the page as a whole.
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)
has also been added, because the action open_website_url linked to the publish
button is not defined on res.users model (but on its inherited partner).
It now has the method that is routed on its partner.
Jeremy Kersten