Fix the access error you could get when filtering on ratings when not logged
in or when the user has no rights to access ratings.
How to reproduce: filter on channel review ratings in eLearning frontend
when being anonymous le portal.
As rating is a technical model, we have to first retrieve messages linked
to that rating value and afterwards return a new domain used to build
the final search.
Task ID : 2167776
PR : #42847closesodoo/odoo#44380
X-original-commit: 7a241e9c21046dababc2744dd94b0c47e2d8a931
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose of this commit is to add some missing fields in message view, notably
is_internal newly added flag and its ratings. Rating form view is also
updated to display is_internal flag, and form view is a bit reorganized.
Task ID 2071556
PR #38692
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
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
PURPOSE
Rating model should be available only for internal users. External users
access them only through dedicated routes or controllers using sudo and/or
granting access through tokens. Therefore simplifying ACLs should be feasible.
SPECIFICATIONS
Remove access to rating.rating for public and portal users. Only employees
can access it, with full access given to system admins.
Update various functional flows to use sudo() and check that access is
verified before using sudo.
Impacted modules
* rating / mail: add groups on some rating related fields as only
internal users should access them now;
* rating / mail: set some statistics fields using compute_sudo as their
value should be accessible for external people even without access to
the underlying rating.rating records;
* project: makes some use of rating and has to be updated, notably for
the public rating page;
* website_{livechat, rating, slides}: add sudo in public routes as access
is already granted;
* website_slides: set statistics field using compute_sudo as their
value should be accessible for external people;
TASK ID 2053096
PR #36592
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, when user land after clicking on the smiley in the
e-mail for rating, user cannot change its rating. Its click limits the
available choice.
Now users will be able to choose rating and write feedback before submitting
its rating.
Task ID 1936849
Closes PR #33979
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Shreya Thakrar<sht@odoo.com>
en_US may not be activated as it is possible to create a database in
another language using the database manager.
When trying to install a chart of account, the tax return entry tried
to format a date at the installation of the module, with no lang in
the context. The fallback was made on en_US but an error is raised if
that language is not activated.
As it is a very common scenario to retrieve a language from the
context, add a generic tool method to do it.
Replace and closesodoo/odoo#37629closesodoo/odoo#37568
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It's a non sense to be able to write on rating_last_image/feedback field as it is a related
to a computed field based on the last rating, given by someone.
We should not even try to corrupt data !
Task ID: 2076656
PR #37511
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
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
Patrick Hoste