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'`
* 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
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
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
The statistic bar size is now related to the value of the rating
+ Adds small modififications to align correctly the different divs
+ harmonize icons size
+ show white icon for readability
+ Add inline padding to team member icon for readability
(inline because this part will be completelly reviewed in next version)
Task ID 1883227
Adrian Torres