This commit adds a rating text field called `rating_avg_text` to display
a text based on the value of `rating_avg` field in `rating.mixin` model.
Here is the text displayed based on the value of `rating_avg`:
1. 'Satisfied' if the `rating_avg >= 3.66`
2. 'Okay' if the `2.33 <= rating_avg < 3.66`
3. 'Dissatisfied' if the `1 <= rating_avg < 2.33`
4. 'No Rating' if the `rating_avg < 1`
Purpose
=======
This commit changes a conversion variable
`RATING_LIMIT_SATISFIED` in order to follow a new conversion:
> 5/4 := Satisfied
> 3 := Okay
> 2/1 := Dissatisfied
Specifications
==============
This commit only changes the variable in order to limit the
modifications made to the `rating` module/models.
This is done in order to change the faces displayed for each review/rating
without impacting the statistics. The ratings/reviews will have the same values
as before but will only get a different conversion if higher than 4.
task-2597345
See odoo/enterprise#20480
See odoo/upgrade#2784
Part-of: odoo/odoo#75646
The purpose of this commit is to make improvements in ratings
views.
so in this commit did the following changes:
Graph View
- rename 'Rating Value' to 'Rating Value (/5) in measures
- remove 'document' and 'parent document' measures
Kanban view
- only display the name of the rated operator, not his company
list view:
- resequence the fields and change attrs
search view:
- added various filter
Related Enterprise PR: https://github.com/odoo/enterprise/pull/19415closesodoo/odoo#72965
Taskid: 2531491
Related: odoo/enterprise#19415
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
RATING
Rating texts currently have a negative skewness. Indeed apart top rating
all ratings have a negative feeling. In this commit we update them
to match more closely a 1-5 range from dissatisfied to satisfied, ok being
the middle value.
PROJECT
Filter customer rating were taking in account ratings from first e-mail
instead of current satisfaction.
IM LIVECHAT
Livechat did not catch feedbacks without comment.
Task ID-2439720
COM PR odoo/odoo#66992
ENT PR odoo/enterprise#16757
Fix issues in livechat display
* rename Rated user filter into Rated Operator
* add padding to improve readability of the feedback screen in the livechat
window.
* fixed URL in placeholders to match existing "contactus" page URL
Task ID-2301261
PR odoo/odoo#60549
X-original-commit: 60e27876bb7ccdd6a6f871db82d44ac194b6f739
- Rename the 'Use Rating on Project' feature into 'Customer Ratings'
- Rename the 'Set Email Template to Stages' link to 'Set a Rating Email Template on Stages'
- Add an optional list view for the Stages menu
- display warning if the rating_template_id field is set and if one of the selected project_ids doesn't have the rating_status field set to true
- Project form view revamp
- rename the '% on tasks' stat button into 'Customer Satisfaction'
- Remove the 'no option' for the rating frequency field because it is required
- project form : Add a 'Go to Website' stat button
- Project dashboard: remove the 'Customer Ratings' menu item in more
- Ratings page: the 'Last 30 days' filter include ratings from today
- remove the Appointment / Helpdesk Customer Satisfaction / Live Support menu items
TASK ID : 1251
Issue
- Install eLearning
- Delete a rating
- Go to the course page, review tab
Only the stars disappeared.
Cause
Review = rating + message, the rating is the stars and
publisher_comment
So this is normal if the review is not completely deleted
Solution
Seen with SBU and he said that the message should be deleted
too.
OPW-2181568
closesodoo/odoo#44529
X-original-commit: 1f41c7ae9de061ec861a3a3db9c403510861cc76
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
Website mail defines a website_published field allowing to publish / unpublish
comments on the frontend of some modules. This field has several drawbacks :
* it is used only for front-end people (portal, public) and has no real
effect in chatter / classic discussions;
* it is used only in some advanced front-end module and is not available
in portal by default;
* its naming is not really correct as it is not linked to fields coming
from the website_published mixin and its behavior is not really
the same;
* its use is a bit duplicated with internal flag coming from subtype
allowing to hide messages related to an internal subtype;
* there are overrides of standard mail.message methods just to handle
this flag;
In this commit we change that field by an is_internal flag directly on
mail.message model itself. It tells if share people (customers, share users)
are allowed to read the message. This field can be given through posting
API or set manually using widgets. It is also used in access rights custom
methods and managed like the internal flag of subtypes.
Mailgateway was already using an internal flag for internal note replies. It
is renamed to is_internal and propagated as it is now a standard field. It
also eases code understanding.
Portal is updated to allow managing the flag directly. It means customer portal
now natively allows to moderate customer comments without any need of website
modules.
Rating is updated accordingly. An is_internal field is added, replacing the
related on website published.
LINKS
Task ID 2071556
PR #38692
Currently if we try to display image of a rating having a different value of
0/1/5/10 there is an infinite loading. Indeed images for rating are limited
to those values.
In this commit we fix that by computing a rounded value to find the closest
image.
Text display in form view is also centered for better wow onboarding back 2
basics demo usability fiximp effect.
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
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'`
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.
This allows to better control the posting process, notably using custom
layout to encapsulate emails. Previously to this commit a simple email was
send using a template. Now this template is used to post a message on the
record asking for customer request.
New parameters are added on the request send method
* a subtype, allowing some custom behavior with followers; by default the
behavior is to log a note with the customer being in the recipients list;
* composition_mode can be given and propagated to message_post_with_template
allowing a comment or mass mailing mode;
This commit is related to task 51122 (and PR #24052).
Remove the support to replace emojis by images. Most browser
now support colored emoji or at least black and white emojis.
The emojis list have been updated to ensure a correct support
for most os/browser.
Users have the possibility to install fonts localy if their os does not
have one of the default emoji font installed.
After default os emoji font, one of twemoji, emojione or noto color
will be selected.
The emoji list is now hardcoded in js in order to reduce the number of
records in shortcodes.
Also include a small fix for livechat to display message field when rating
is bad.
Task #36898
PR #23689
For objects inherting from rating.mixin, when their parent model change
(e.i.: task from a project to another), the "Parent document name" does
not change. The rating is still considered belonging to the old parent
object (rating stat of project is not correct).
Change the rating API. In rating mixin, instead of having 2 methods
returning parent id and parent model (rating_get_parent_id and
rating_get_parent_model_name), we should have one method returning the
'parent relation field' (inevitably m2o field). Then we can deduce its
parent_res_id/parent_res_model, and check this parent field is in values
of write to trigger the recompute of parent_res_name.
Also, add "ondelete=cascade" on parent_res_model_id
Impacted modules: project, rating, helpdesk, livechat
It shouldn't happen, but if we change the name of multiple rating_mixin
inheriting models, we can run into an error, because write doesn't
support multiple values.
*im_livechat,rating.
Emojis are now encoded in unicode characters in messages. This
allows to copy/paste messages including emojis, ensures that
emojis are properly displayed in mail interfaces (at least those
that support unicode, e.g. GMAIL, counter-example: outlook), and
allows the user to directly use emojis of its smartphone in mobile.
This commit also adds several new emojis.
PR #11095
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
This commit change field rating_text into
selection computed field.
In customer satifaction, we want to be able
to group by note, but not use the rating value
itself. So a label representing provide 3 satisfaction
levels : 'Dissatisfied' (1-3 points), 'Not satisfied'
(4-7 points) and 'Satisfied' (8-10 points).
This commit provide a parenting system for rated
record, such as mail alias.
For instance, 'project.project' is the parent of
task and issue objects.
This will allow to have a global view of customer
statisfaction on 'parent' objects (project and
livechat channel for now).
To do so, the rating
mixin provides 2 methods that need to be
overriden: `rating_get_parent_model_name` and
`rating_get_parent_id`.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Demoted to library in Python 3, see if uses can be replaced by more
specific construct, just import functools.reduce otherwise.
Futurize fixers:
* lib2to3.fixes.fix_reduce
The `rating_last_value` field was a related on the One2many
field `rating_ids`, on which the domain
`[('res_model', '=', self._name)]` is applied.
The problem is that this domain is not taken into account
when retrieving the records for which this value must be recomputed
Therefore, when computing the `rating_last_value` of a record,
if there was a record with the same `res_id` but another
`res_model`, the `rating_last_value` of this other record
is recomputed as well.
And, if you did not have the write access rights on this other
record, it raised a security exception.
There is at the moment no way in the ORM to filter the
depends on a specific subset of records for which
a computed field must be recomputed. Therefore,
we have no other choices to make the recomputation
of the records value as sudo. It will
recompute the value of other records which have nothing
to do with the one on which this value must be recomputed
(nothing to do except the id of the records which is common),
but at least it will succeed.
opw-709349
Automatically deleting a rating was not implemented
yet. We find 2 cases :
- when uninstalling a module, the same mecanism as
mail.follower is used, via a res_model_id field
pointing on ir.model. When this model does not
exist anymore, remove all related rating.
- when deleting a record, its rating should be
deleted too.
In rating module
- provide list and form view for rating
- better kanban view (remove js code, ellispsis
for long name, better feedback display, ...)
- provide more field on the mixin to cover
more case
- update res_name of rating when the ressource name
is changed (for consistency)
- make the rating web page, a correct html page (by
using web.layout template)
- some guidelines compliance
In rating_project and rating_project_issue:
- add filter for rated document
- some guidelines compliance
Several translation issues are faced with the rating module:
- the feedback page is always displayed in the admin language
- the feedback emails are always sent in the user's language
One would expect these to be in the partner language.
opw-694718
Xavier BOL (xbo)