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
[IMP] rating: website rating page: reviewed design, rate on click, update on submit
[IMP] rating_project: rating_status: 'no' instead of False
[IMP] rating_project/issue: smileys insteaf of thumbs for consistency in kanban
[IMP] rating: allow to update an existing rating (feedback + rate)
[IMP] rating: consistency on rating names (statisfied, not satisfied, higly dissatisfed)
[IMP] rating: avoid deadend after rating, button to go to Odoo
[IMP] rating: res_config better sentence
Purpose:
For our internal project management, we would like to track the customer
satisfaction on the open projects. We send them an email every one or 2
weeks allowing them to give a feedback by clicking on one of 3
smileys: Happy, Average, Angry. They can also put a additional explanation.
We already have something similar which is working on livechat with a
unusable reporting, and on issues but unusable. Our project are managed by tasks.
Specification:
- On the project : Selection fields : (Periodical Rating or Rating on Stage)
+ Fields to choose the period if periodical
- On the stage : email_template_id field.
- IF :
---> Periodical : Send an email to all the customers for the tasks on this stage periodically
---> On Stage : Send an email to the customer's tasks when the task reaches the stage
- That way, it's impossible to send a satisfaction request both periodically and sequentially.
FP request
- Who is the customer : The customer on the task OR the customer on the related sales order
OR the customer on the projet OR nobody
- The last feedback is displayed on the task kanban card (Thumb up, down, or neutral)
- On the project kanban card, the customer satisfaction is displayed. This is the simple
mean of all the previous ratings.
- star widget and rating card to post and display rating
- Linked rating.rating to mail.message
- method to extract more statistics about the rating of an object.
Christophe Simonis