*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
__Description of the issue:__
When something goes wrong while downloading a report file, a 500 error
is sent as JSON. However the frontend interprets this response as HTML
and then try to parse the text content as JSON.
Most of the time this works, but if the response contains any HTML tags,
like `<lambda>` from a Python stacktrace, the JSON response will get
misinterpreted as HTML instead of regular text, causing the subsequent
JSON interpretation to fail.
The end result for the user is that empty tracebacks will be displayed
instead of User Errors or actual tracebacks.
__Desired behavior:__
The JSON response is HTML escaped before being sent and will therefore
be correctly parsed and displayed to the user.
This basically restore what was done prior of #104594.
Enterprise: odoo/enterprise#36523
X-original-commit: 5999a7d336553053c5638f69344cdfbc84a8c681
Part-of: odoo/odoo#112453
Current behaviour:
When we are printing a report and then the report fails to generate
(for ex. wkhtmltopdf memory limit/timeout),
the incorrect state is committed to the database.
Expected behaviour:
We should rollback when generating reports fails, since it is an error state.
Steps to reproduce:
To reproduce the behaviour, we need to force an error state.
- In odoo/addons/base/models/ir_actions_report.py:`_run_wkhtmltopdf()`,
raise an exception before spawning the subprocess (for ex. adding a 1/0).
- In addons/web/controllers/main.py:`report_download()`#L2126,
add this little code snippet:
```python
ids = [int(x) for x in docids.split(",")]
report = request.env['ir.actions.report']._get_report_from_name(reportname)
obj = request.env[report.model].browse(ids)
if getattr(obj, 'message_post'):
obj.message_post(body='This report was committed!')
```
- Install Inventory
- Pick a delivery order and try to print it, there should be an error
(whatever exception you decided to raise in `_run_wkhtmltopdf()`)
- See that in the message board we got a message that the report has been committed,
which isn't the case, it failed to generate.
Reason for the problem:
Controllers are catching the exception when generating reports,
but never reset the state of the database.
Fix:
Raise an InternalServerError with an error code of 500 to trigger
a database rollback.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3001950
closesodoo/odoo#106172
X-original-commit: ec185fcf7f32da05c83733af36bebe10ac22e2ad
Related: odoo/enterprise#34193
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The odoo.addons.web.controllers.main module was a very long bloated file
where many different controllers were concatened. It proved difficult to
work on that file on a regular basis,mainly because ctrl-p "web main.py"
was not pointing the right file.
In this work the file has been split on the basic 1 controller = 1 file.
The original way of importing stuff (through main.py) is still possible
thanks to deprecated aliases.
Part-of: odoo/odoo#87571
Benoit Socias