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)
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.
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).
This is a partial patch for issue #3460, pending more
improvements and refinements in master.
Currently the karma penalty is hardcoded to 5*downvote penalty,
which may or may not be sufficient to prevent posting, depending
on the other karma levels.
- fixed voting, karma check could be avoided
- fixed posting comments, now correctly checking karma (not for
notifications)
- fixed bootstraping of users, now not allowed to ask questions by default;
added validation email that gives the first karma points required to
participate
- added tests
While posting new questions and answers the check
for karma limit was bypassed because it was using
super-user mode: use regular user instead.
Also improve the user feedback when karma level is
too low to perform some actions: post comment,
post question, post answer.
The usability in these cases still needs to be
improved.
- avoid to browse on every question/answer, only the 20 most recent ones (need to manually update the view to see the real number of q&a)
- do not render hidden tabs (leakage of information and useless rendering)
- add related fields to speed up vote search (need to be stored to be efficient)
add the possibility to users to follow a forum and be automatically followers of new
questions, using some new subtypes on the forum.forum model that do the auto subscription.
Also added a profile link on the forum, when logged.
Also added a subscribe button on the forum.
Using sql will be faster (doing a write in a read is never a good idea for performances) and will not update the write_date (which is used for the last activity filter)
- display tag name in 'filter' bar when filtering on a tag
- display active tag in a blue color
- order answers: correct first, then most upvoted
bzr revid: tde@openerp.com-20140506123001-fz5gt6i9zw6ondcu
gamification:
- fix batch mode when grouping by id
- fix subquery in batch mode when a ending date is set
- serialisation method can exclude categories of challenge
- view improvements
website_forum:
- enabling bages in batch mode
- fix karma computation when creating a new post
- changing previous vote affects the user karma
- do not display forum challenges on user home page
bzr revid: mat@openerp.com-20140415162400-78cklbdw0bmn94zr
as it is now a feature in trunk.
Also removed unnecessary column redefinition.
Also removed an override in users, will see if necessary.
bzr revid: tde@openerp.com-20140411160003-tffx54f2evjh4r70
- cleaned models
- cleaned controllers: lots of cleaning, rewriting, simplfiication + updated in views
- added an override of the contact widget, to be able to display partner-related
stuff about karma and badges
- some css tweaking
- badges cleaning
bzr revid: tde@openerp.com-20140411132939-bmvyc9bqpqpkk843
someone see the question. Also use message_is_follower instead of re-implementing its
feature by checking the followers.
Views is updated through a method on the post object, incrementing the views counter
by 1.
bzr revid: tde@openerp.com-20140409172522-pwehz1k9z5rf765s