[13.0][MIG] report_qweb_signer - #522
Conversation
These limits were being hit when printing PDF reports with just 80 pages.
- Good dependency chain - Context for forcing rendering PDF - Extra test
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: reporting-engine-12.0/reporting-engine-12.0-report_qweb_signer Translate-URL: https://translation.odoo-community.org/projects/reporting-engine-12-0/reporting-engine-12-0-report_qweb_signer/
`render_qweb_pdf` must return a tuple of `(content, 'pdf')`
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: reporting-engine-12.0/reporting-engine-12.0-report_qweb_signer Translate-URL: https://translation.odoo-community.org/projects/reporting-engine-12-0/reporting-engine-12-0-report_qweb_signer/
Fix website on manifest
39356bb to
89129f2
Compare
| res = """<filter name="%s" string="%s" | ||
| context="{'group_by':'%s'}"/>""" % ( | ||
| res = """<filter name="{}" string="{}" | ||
| context="{{'group_by':'{}'}}"/>""".format( |
There was a problem hiding this comment.
This change should not be in this PR ?
There was a problem hiding this comment.
This was changed automatically by pre-commit, I can remove it if you would like ?
There was a problem hiding this comment.
Ah ok, it must be pyupgrade that does it. Strange that it changes in this PR and while the main branch is green ?
| <record model="ir.config_parameter" id="report_qweb_signer_java_param"> | ||
| <field name="key">report_qweb_signer.java_parameters</field> | ||
| <field name="value">-Xms4M -Xmx4M</field> | ||
| <field name="value">-Xms4M -Xmx1g -XX:CompressedClassSpaceSize=256m</field> |
There was a problem hiding this comment.
Is this change related to the migration ?
There was a problem hiding this comment.
If I didn't add -XX:CompressedClassSpaceSize=256m to the file, I couldn't run tests (same thing for a gitlab runner)
-Xmx1g was just a test I didn't remove, changed it back to -Xmx4M
89129f2 to
1917d7f
Compare
1917d7f to
f9b405a
Compare
|
@pedrobaeza if you are interested. There is also #528 which adds optional endesive support (no java \o/). |
|
Thanks for the pointer. If the Java-free solution is working, shouldn't we go directly to that one and don't make it optional? |
|
We could make endesive the default in 13.0+, and keep the java code path for a little while until people confirm they are happy with endesive. |
|
If there's no drawback, I think the goal of the module is very clear: to sign the PDF. Letting 2 options for doing exactly the same is maintenance-wise? If there are some differences, then let's put them on the table for deciding. |
|
I agree we'll need to keep only one at some point. But for now we can't promise that endesive has no drawbacks. It is simpler to deploy and has better performance, but there might be some exotic signature feature missing (such as the LTV option). |
pedrobaeza
left a comment
There was a problem hiding this comment.
OK then, let's go with such approach.
Code review
|
/ocabot merge nobump |
|
This PR looks fantastic, let's merge it! |
|
Congratulations, your PR was merged at f95255a. Thanks a lot for contributing to OCA. ❤️ |
No description provided.