In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..
Otherwise it is not visible when set on an instance of the new API.
self is a recordset instead of the model `res.users`
Without this patch a low priviledge user was not able to modify its own value
of `notify_email` through the preference window.
When only a message argument is given to the crash manager, the popup display
"Error while validating constarint" and "None" with the warning message
which does not make any sense for the common user.
When a user attempted to edit his answer,
and had not enough karma to edit the tags
of the post, he was always restricted,
even if he made no changes within
the post tags.
opw-670090
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.
Using message_post_with_view, raw html contained in python is now moved into
a template data and called from the code. This allows to avoid having raw html
directly embedded in python code.
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.
It is now possible to follow tags in the forum app. When following tags you
will be notified for every new post linking this tag.
A small karma update is also performed. We now correctly use karma to retag
posts, and karma to create new tags.
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)
rap-odoo