Purpose is to set review message on both message and rating so that reviews
are correctly displayed in eLearning backend as well as correctly displayed
in chatter frontend.
Task ID 2058595
PR #36281
Purpose of this commit is to
* delete rating when deleting message. Otherwise rating coming from
frontend portal review chatter are lost in the void;
* allow system users to delete ratings;
Task ID 2058595
PR #36281
PURPOSE
Allow publishers to add a comment on frontend reviews with ratings. Purpose
is to allow to give some feedback or context on published reviews.
SPECIFICATIONS
In order to answer to a rating message (review) of a course (eLearning) or a
product (eCommerce) we add a way to the publisher to directly comment a review
inside the website rating chatter.
Any publisher can add/edit/remove comment of a rating message from the website.
The goal is not to enter into a discussion but just to give a feedback. This
comment is not sent or propagated to anyone, just displayed for information
purpose.
In portal chatter
* add 1 button below a review "Comment" (for publishers of the website only)
* only one comment possible by review/rating
* when the comment is added, display
* author name, date, comment
* 2 buttons, only visible by the website publisher: edit and delete
LINKS
Task ID : 2026911
closesodoo/odoo#35956
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
* http_routing, portal, rating, survey, website, website_survey,
website_slides_survey
Before this commit, the final base layout of website was a fully
overridden layout of the one in portal, which was somehow a duplicated
one of the login one in web, which... so lots of duplicated code.
This commit is a first step towards a better organization:
1) The web app defines a frontend layout (to include base frontend
assets), with a base company logo as header.
2) The portal app modifies that layout in place to include the base
header, footer, ... It also uses a primary extension of it for
portal pages.
The survey app simply uses the above layout instead of defining its
own (by primary extension to include its own assets for its own
pages)
Same goes for the rating app and pages.
3) The website app modifies that layout in place to include the UI
assets, to add website UI, ... This allows to create frontend apps
which do not depend on website, with a non duplicated layout that
will be automatically adapted if website is ever installed (this
therefore allows to get rid of website_survey definitely)
This commit also fixes the session info system and the translation URL
on the frontend side to not require to redefine the whole session_info
for portal, website, ... Now the frontend session_info is defined in web
and http_routing extends it to add translation informations, then
website extends it again to add its own elements (not to redefine them
all as before). Note: before, http_routing defined the translation route
but only portal was adding it in its layout...
This is an adaptation of the work that was done with commit
https://github.com/odoo/odoo/commit/99821fdcf89aa66ac9561a972c6823135ebf65c0
Note 1: Many frontend but non-website apps (not only survey / rating)
could probably use this too but this would be the topic of another task.
Note 2: survey currently depends on http_routing but does not add itself
in the list of frontend apps to translate, it probably should.
Note 3: web_editor does currently not depend on http_routing but does
add itself in the list of frontend apps to translate, it thus uses a
function it does not really depend on... to check after its work-in-
progress refactoring.
task-1961045
closesodoo/odoo#33825
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to clean notification process: calls, methods
API, method name, variable propagation.
Contains notably
* simplify API of methods used to group recipients when sending notification
emails;
* improve and rename methods used in email notification process;
* move some methods on model itself as non mail thread records could be
mass-mailed and _notify_email_headers could be called on other records;
Related to task 1943901
Linked to PR #32404
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
The function _compute_parent_rating_percentage_satisfaction used the creation
date of the rating to compute the percentage.
However when a client give a new rating, it updates the old one.
As a result it doesn't give the recent satisfaction percentage,
but the satisfaction percentage of recently created tickets.
In other words recently angry clients from old projects would not appear.
Similarly this method is somewhat reimplemented directly in SQL in the rating
route, which happens to be in the project controller.
opw 1921486
closesodoo/odoo#30752
This commit provides 1 more field on the rating mixin: the average of
the ratings of the document. Before that, the only way to get the
average was to call `rating_get_stats` record per record.
As we are on a mixin, this new field is not stored to avoid recomputation
each time a rating is added. To improve performance, we decided to
compute `rating_count` and `rating_avg` in one `read_group`.
This commit also set an extendable method to get the domain of the
rating to include in those statistics computation, called `_rating_domain`.
This way, each model inheriting the rating.mixin can define the subset of
pertinent ratings.
As consequence, this commit uniformized the way average is displayed:
instead of taking the closer value to the 0.5 value, it only round it
at 2 digits.
Task-1902304
Commit f727e9d9b6 made the rating field
of mail.message non-stored for performance reasons.
When the rating is activated on the website, it adds the possibility to filter
product reviews by rating (1 to 5 stars).
It does so by searching the messages that have a given rating value.
However the osv complains that you can't search on a non-stored field.
As a result, instead of displaying messages filtered by ratings,
it would always display all of them.
We add a search='_search_rating_value' on the field to allow that field to be
searched anyway.
opw 1931038
closesodoo/odoo#30499
This is basically a backport of revision
47479401cb
to gain the performance on the project
percentage satisaction computation
but without introducing the new parent mixin,
which would not be a stable change.
closesodoo/odoo#29354
The correct way to trigger a recomputation of a field is not
to call directly the compute method. The ORM offers mecanism
to do it: we have to flag the field as "recompute to do" and
then call `recompute` method (availble on every models). This
one will call the recompute method of all fields marked as
"to recompute".
This will optimize the performance by doing recomputation in
batch.
Task-1903565
This commit simply move code for both rating.mixin
and rating.parent.mixin in their own file to ease
the reading of code, and fit the guidelines.
Task-1903565
Impacted modules: im_livechat, project and rating
This commit restricts the access to some method of the rating API. Indeed,
some of them are internal business and should not be called from anywhere
to avoid breaking the rating flow.
This commit also rename some method to fit guidelines. This should not
bring any functionnal changes.
Task-1903565
The correct way to trigger a recomputation of a field is not
to call directly the compute method. The ORM offers mecanism
to do it: we have to flag the field as "recompute to do" and
then call `recompute` method (availble on every models). This
one will call the recompute method of all fields marked as
"to recompute".
This will optimize the performance by doing recomputation in
batch.
Task-1903565
When creating a task, the satisfaction of the project is recomputed even
if the task has not rating. This can lead to performance issue:
concurrency error in Postgresql can happen if a task is created when
somebody else tries to update the project.
The satisfaction recomputation will give and concurrency error whereas
it will return the same satisfaction percentage, since the task has no
rating. The same problem will happens in every modules implementing
the rating feature: project, helpdesk and livechat.
This problem leads us to create the rating.parent.mixin in order to
retrigger the computation only when a new rating appears on the
parent object. We also unstore the field to make its computation lazy.
Maybe in a near future, this field will be computed in SQL directly.
The parent mixin allow us to standardize the behavior to all parent
rating models.
These optimizations should reduce the number of computation and speed
up the task creation.
opw-1902502
Task-1903565
Odoo Translation Bot