When fetching messages from the portal controller, we might
give a domain to restrict the message selection. Typically,
the ecommerce allows users to submit messages with rating
of the product. Users are allowed to filter the messages
with a certain rating.
Passing a non-normalized domain to this controller could
give strange result, as the code was using `+=` to concat
domains; some result domain could have been correct, but
return some strange results.
This commit normalizes all domains used in the code
making a non-normalized domain (given as parameter) crashes,
instead of returning unexpected messages.
Closes#26939
Have the main company (A) with the public user
Have an invoice in company B
Make a brand new browser access the invoice with the token
Before this commit: the token link ended up asking the customer to login,
eventhough it wouldn't if the invoice were in company A
After this commit: the whole payment with access token flow works as expected.
OPW 1879999
closes#26744
In bd4f09f there was a typo in the domain portal message fetch (two `&`
instead of one), luckily this did not cause an error in 11.0
But in master expression.AND normalizes the domain, thus we got an error.
opw-1819702
closes#25131
The portal view for tasks previously listed all task of all projects
without grouping them. It was a problem, mainly when we want to make
the distinction on project label_tasks, to make the difference
between tasks, issues, ... Grouping task by project by default allows
to show the label_tasks before each project.
Grouping the tasks removes the possibility to define a primary
ordering. We want to be able to ungroup the tasks in some cases.
The implentation was done in the portalsearch bar adding
a group by option. The portal proposes two grouping options,
project (by default) and none (to keep strict ordering).
Task: #1827950
PR #23769
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
In the frontend only plaintext is saved without any javascript fiddling
so in the controller it should be adapted to be saved.
With this change, the behavior is more similar to backend chatter which
sends html (processed by javascript) to the server.
opw-1817918
closes#23706
60c920d4a should solve duplication of chatter when editing the website.
But portal module doesn't depends on website, so eg. on a instance with
just helpdesk (and no website) we would not see the chatter on the
frontend.
This fix reverts 60c920d4a and adds another solution not depending on
website.
opw-1813792
closes#23614
When editing a view on the frontend with a dynamic chatter (chatter
added dynamically to the view), if that part was edited, that
dynamically rendered part would be saved as is. Thus we would get a
duplicated chatter (with the first one statically the rendering at the
edit time).
opw-1813792
closes#23593
When a chatter is displayed and the document is accessed with a valid
access_token, the message related to the document are searched in sudo.
This bypass valid filtering we may down the line.
This change apply the filtering so note type messages are not displayed
for user who are not employees.
note: before 11.0 this logic was in 1b5c2ced. In future version it would
probably be better to have a method eg. _get_domain_based_on_user
that would be called before sudo and if not sudo.
opw-1819702
closes#23544
Odoo Translation Bot