Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Create a vendor bill with a specific attachment (on ticket)
Go to vendor bill list view
Select the created bill and another one
Print > Original Bills
Traceback due to unhandled ValueError on pdf read
opw-3498898
closesodoo/odoo#135320
X-original-commit: adf4c91f3f696ee849577e345d40e24d59d452f4
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
With Python 3.11, PyPDF2 2.12.1 is used and the exception raised when
the encryption type is not supported is now `NotImplementedError`
instead of `PdfReadError` in previous version.
In order to support both version, this commit adds a catche for the
`NotImplementedError` too.
closesodoo/odoo#133242
X-original-commit: effff7e00d8d410106e12e7ea42c8a875a11bb8b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since the fix of the QR bill headers (see task-3241502, PR:https://github.com/odoo/odoo/pull/130478), the print in batch functionality raises a stack trace.
This is because the render_qweb_pdf_prepare_streams method in base/ir_actions_report.py wasn't meant to handle multiple pages report without specific titles in its HTML structure, which is here the case since the QR bill fixing merges the top of one page with the end of another, therefore creating a peculiar structure.
In those cases we can consider that if each non-generated stream corresponds exactly to one page in the PDF reader, this is a simple batch printing case and we can just handle each page separately.
task-3241502
closesodoo/odoo#132816
X-original-commit: 84fdd2eb11e42f0422dd62961aea7fe4e6f52da3
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
This commit addresses performance issues when generating PDFs with large
tables using wkhtmltopdf. Processing time for such tables grows
exponentially with rows, causing significant delays.
Testing revealed a PDF with 250,000 rows took about an hour.
Previously, a workaround involving special XML template was provided to
users, inserting </table><table> tags every 500 rows.
This commit introduces a general solution at framework level.
Now, tables with >500 rows will automatically use this workaround,
enhancing PDF generation speed.
The number 500 is taken from opw-1689673 and seems to be a good
compromise between the number of split in tables and the processing
time by wkhtmltopdf
closesodoo/odoo#131933
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit it was not possible to print a report without
bypassing the retrieval of a previous attachment, or to print
a report without creating one.
After this commit it is possible with the context key "report_pdf_no_attachment"
Part-of: odoo/odoo#128228
Wkhtmltopdf is unable to render WebP images.
This commit intercepts the requests for the image data during PDF
reports rendering to replace them by the converted image that was
uploaded with it.
task-2774352
Part-of: odoo/odoo#85494
action_base_document_layout_configurator should always have a dialog_size = 'large'
this ensures that the context from a calling function is not applied
closesodoo/odoo#127630
Related: odoo/enterprise#43770
Related: odoo/upgrade#4918
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Before this PR, it wasn't possible to add a custom margin bottom into specific paperformat args.
closesodoo/odoo#123872
Task-id: 3171683
X-original-commit: 0ea1af531ce8887434893f670b1c1e9f075e88c3
Related: odoo/enterprise#42004
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Steps to reproduce:
- Install industry_fsm_report, website
- Create Project P, add column/stage PC.
- Edit stage, Email Template = Task: Intervention Schduled.
- Edit the template > Advanced Settings > Optional report to print and
attach = Worksheet Report (PDF). Save everything.
- Go to website, "contact us" page > Edit the form, Action = Create a
task, Project = P > Save
Issue:
When you first submit the form, it will fail, but the task will be
created and visible in project P. By instinct, the user will submit the
form again, so the task will be duplicated. The second form submit will
return a success message.
When submitting a form, we first generate a savepoint (added in
commit [1]).
Since this is the first interaction with the report system, during the
handling of the form, the assetsbundle will be generated (see keyword
'commit_assetsbundle'), which will cause a commit.
Finally, assuming no other error is raised, we try to delete the
savepoint.
However, since a commit was executed, then the savepoint will no longer
exist, which will cause an error status to be returned.
Solution:
When submitting a form, pass `commit_assetsbundle=False` to the record
creation, which prevents the commit from happening.
This solution has a downside; creating the record also sends an email
and the report attached to that email will have broken styling. This is
still an improvement to the current behaviour, which doesn't send the
first email at all.
[1]: https://github.com/odoo-dev/odoo/commit/5a499ecf113f08c11d2b33b47680dd00ec1b297b
opw-3183912
closesodoo/odoo#123198
X-original-commit: 26031c452a7d92f35270cb04a4f37b26ff6bcc99
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Steps to reproduce:
- set up a header with company logo
- print 20 sale orders in arabic
Bug:
header disapears on most pages
Fix:
add a setting to allow users to increase the delay before printing
opw-3217155
closesodoo/odoo#122983
X-original-commit: 68f7cbd15df7839aab146023399da1570b12b441
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Followup cleanup of https://github.com/odoo/odoo/pull/106620 where
Datamatrix of pylibdmtx was replaced with built-in reportlab
ECC200DataMatrix option. For stable compatibility, some parts could
only be deleted in master, so let's delete them now.
closesodoo/odoo#122704
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
To Reproduce
============
- create two Vendor Bills and attach to each one a PDF from the ones
provided by the client on the ticket.
- select these two bills and and try to print Original Bills an error will be raised
Problem
=======
while merging these PDFs, PyPDF2 throws a `TypeError` which is not caught by the server
Solution
========
catch `TypeError` to raise a UserError
opw-3285540
closesodoo/odoo#121313
X-original-commit: 5053620c640136025f5b37c5b8d233ad63825389
Signed-off-by: abla001 <abla@odoo.com>
Rationale
---------
Given the following domain:
['|',
('company_id.name', 'like', 'BE'),
('company_id.city', 'like', 'Brussels')]
The ORM would generate the following SQL query:
SELECT "res_partner"."id"
FROM "res_partner"
WHERE "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company"
WHERE "res_company"."name" like 'BE'
) OR "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company"
WHERE "res_company"."email" like 'help@odoo.com'
);
Which is sub-optiomal as the WHERE clause of the two subqueries could be
regrouped inside of a single query like so:
SELECT "res_partner"."id"
FROM "res_partner"
WHERE "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company" WHERE (
"res_company"."name" like 'BE'
OR "res_company"."email" like 'help@odoo.com'
)
);
Postgres-wise, it is faster to execute the latter query than the former
one. This commit is about optimizing the ORM so that it generates
queries where the WHERE clause of compatible subqueries are grouped
together.
Technical solution
------------------
The solution explored by this work is to replace the regular relational
field accesses (over a dotted path) by a new `any` operator that look as
follow:
(relational_field, 'any', domain)
For instance, the above `('company_id.name', 'like', 'BE')` leaf becomes
`('company_id', 'any', [('name', 'like', 'BE')]` using `any`.
Having a domain as right-hand-side allow for the combination of the
domains of same compatible relations:
[('company_id', 'any', ['|',
('name', 'like', 'BE'),
('city', 'like', 'Brussels')])
Having combined domains allows for generating better SQL queries with
minimal changes to the expression parsing algorithm, which can only
translate a single leaf at a time to SQL. With the new `any` operator,
it is still a single leaf but the right-hand-side contains the merged
domain, thus the combined SQL WHERE clause is immediately generated.
task-id-3234671
Part-of: odoo/odoo#118067
Co-authored-by: Raphaël Collet <rco@odoo.com>
In some cases, wkhtmltopdf might exit with an error (e.g.: a memory
limit). In such cases, we want to show to the user the error returned by
wkhtmltopdf. Previously, this message was only displayed in binary
format (displayed as "Message: b'My error\n'") which is not user-friendly.
We want this message to be decoded so that it is a bare string
(displayed as "Message: My error").
closesodoo/odoo#114609
X-original-commit: 5fc49f8bb24a328e7b735847795bd8e78229cbfb
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Step to reproduce:
Edit documents layout in general setting to add logo and background
select multiple documents (more than 5) e.g. Inventory> delivery slips
print all documents.
Bug:
background and logo missing on the last documents because the pages
were printed before the browser had time to render them
Fix:
wkhtml2pdf has a default delay of 200 ms (--javascript-delay)
increasing the value will allow large document to load
opw-2951594
closesodoo/odoo#114512
X-original-commit: ac2df93eb3f08696189d010bdfa4187e02a94576
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
1. Settings > Accounting > Vendor Payments > Checks > Enabled with
Print Check (Top) - US
2. Accounting / Vendors / Payments
3. Create at least 2 vendor payments using "Checks" as the payment method
4. In the list view select both payments and click action/print checks
5. Error
Bug:
in `_render_qweb_pdf_prepare_streams`, in the case of multiple
documents on multiple pages, we can only split them if the pdf has an
outline, and it will have an outline only with templates that have a
header tag. For the ones that don't have them like
`l10n_us_check_printing.print_check_top`, it is not possible with the
current logic to unambiguously split them. (maybe we can add a
heuristic like if number of pages = number of documents we can assume
1 document/page)
thus the streams returned by `_render_qweb_pdf_prepare_streams` don't
contain the record ids and
`safe_eval(report_sudo.attachment, {'object': record, 'time': time})`
might fail based on the expression to evaluate.
Fix:
It doesn't make sense to save the attachment if we can't split the
attachments clearly anyway, so we can just continue and skip the saving
if record is null
OPW-3124089
closesodoo/odoo#113863
X-original-commit: 1fac708bd335dce27eeb77e0a11e12883a83dac6
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Install invoice, go to any sale-order and print it. There are warnings
in the logs for a problem in the wkhtmltopdf subprocess and for 404
page not found for some css assets while rendering the document.
So the first pdf printed is invalid, but as the report is printed the
asset is commited in db and the next print will be valid.
If you use kwkhtmltopdf, as the pdf is not generated (kwkhtmltopdf is
more strict), then you have an error instead of a broken pdf and the
asset is not commit, so you printing is always broken.
Before #104594, the asset was commited at the end even if we had an
error.
closesodoo/odoo#108330
X-original-commit: 0fb8bcbae18027843583304460f1956ef2d2fe51
Signed-off-by: Julien Castiaux <juc@odoo.com>
This reverts commit 3ebe1185a4.
The code ECC200DataMatrix already exist in reportlab (that is already a dependance).
Some differences:
- ECC200DataMatrix only supports a Type 12 (44x44) C40 encoded data matrix.
(214 alphanumeric characters and 14 to 27% of error correcting rate)
- pylibdmtx support more type and add a default to 24x24. So it means a
(52 characters and 20 to 35% error correcting rate). It's also smaller
to display.
We consider the gain too small compare to maintain an extra lib.
It also fix blured datamatrix in stock report if they contains too much
data.
*If you want to test 001234560000000018 is a valid sscc for package
closesodoo/odoo#106620
X-original-commit: 54ef19f41ffc4a6f715474b65a4183a7fa75feea
Related: odoo/enterprise#34422
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Accounting app > Customers > Invoices
- Create invoice with customer and a couple of products
- In the terms & conditions tab at the bottom, add 20-30 empty lines
and then a heading (/h1-3) with some text. This insures that the printed
report will have more than 1 page.
- Go back to the Invoices list view
- Select the invoice + another random one > Print > Invoices
A traceback appears in _render_qweb_pdf: `KeyError: 'attachment'`
When printing more PDF files at once, several condition have to be
respected in order to also save them as attachments. If the conditions
fail, the PDFs are not saved as attachments and a default dict is
returned, containing the undivided content stream.
The traceback is raised because later we check if an attachment already
exists, even if the files were not saved.
Bug introduced in https://github.com/odoo/odoo/pull/97050.
Solution:
If the conditions fail, add {'attachment': None} to the return dictionary.
opw-2882507
closesodoo/odoo#104916
X-original-commit: 8e3db19f881e3fb72d8a31f56d7cea8876dc57a4
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Prior to this commit get_paperformat function in ir_actions_report.py file
was trying to get a paperformat_id of an empty report and as there was none
was automatically returning company paperformat_id. After this commit said
function will try to get a paperformat_id of the report with specific
report_ref value.
Task-2980708 (Fix Ticket Reports)
Closesodoo/odoo#100199Closesodoo/odoo#104561Closesodoo/odoo#100715closesodoo/odoo#104915
X-original-commit: 78e2c6456d2f9f06d42c18d7b1849d5fad4deb46
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It was not always set (e.g. in the generate_email call of
mail.template) and it executes methods like _render_qweb_html where
data was already optional.
closesodoo/odoo#103840
X-original-commit: ddb2bf9f9cb6ea3a4bbdc4fb68c7fbcb0e66aa43
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The purpose of the task is twofold:
1. Remove empty lines in the company address.
Until now, the address format was fixed, which could
lead to empty lines if one or more field(s) were missing.
We are now removing empty fields to avoid that.
2. Make sure the external report layout is configured
before generating the PDF.
This will ensure that the company data will appear
in the file. If no layout is defined,
it would not be shown.
task-2834517
closesodoo/odoo#100936
X-original-commit: f36bb6acdacaaba26afdd8f62c48fd2c8784d1e1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Printing an invoice no longer saved the ir.attachment on the
move.
This is due to the refactor in ffc525419a,
since the render methods are now `api.model`, `self.attachment` was always
Falsy. To get the attachment name of a report, we need to call
`self._get_report(report_ref)`.
closesodoo/odoo#100363
Signed-off-by: Laurent Smet <las@odoo.com>
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
To reproduce the issue:
(Need stock_barcode)
1. Create a product:
- Barcode: 1234567890123
2. Print the label
3. Try to scan the barcode and check the value read.
Error: The value is 1234567890128, the last digit is incorrect (8
instead of 3)
When printing a barcode, we use the library 'report-lab' to generate a
barcode image from a value and a barcode type. In case of EAN-13, if the
value contains a non-digit character, it will raise an error. We then
catch the error and retry to generate the barcode according to the
barcode type Code128:
https://github.com/odoo/odoo/blob/87698d90f02bfe93c6e643f4876a5ccd74788eff/odoo/addons/base/models/ir_actions_report.py#L569-L575
However, if the value contains only digits, the method will use the 12
first digits:
https://github.com/mattjmorrison/ReportLab/blob/dade0f303cb6fcdbe535c4cc92e6102c2417b699/src/reportlab/graphics/barcode/eanbc.py#L187-L188
and will then add the last one, the check digit, which is computed by
the library. This explains why, in the above use case, the barcode value
returned by the scanner is not the same than the expected one.
Note: Similar behavior with type EAN-8
OPW-2902150
closesodoo/odoo#97052
X-original-commit: a2c7470f8fd46b2520f7b8f0750c63216273ce96
Related: odoo/enterprise#30160
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
Suppose we are printing a PDF on multiple records but having some of them excluded during the _prepare_html.
So, suppose these records are [20, 21].
If [21] is excluded during the rendering because nothing to render, the resulting html will contains only [20].
That is leading to a traceback when checking the outlines because of
assert len(outlines_pages) == len(res_ids)
This commit avoids to check the outlines if we don't care about generating attachments.
Then, we don't need to split the PDF in that case.
closesodoo/odoo#94204
X-original-commit: 210e63ab8b036bd20c68b1e03462c75af12aa326
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
When the html is grouping some records together, there is no exactly one document per record.
In that case, the wkhtmltopdf outlines must not be checked.
closesodoo/odoo#93516
X-original-commit: c1faefce79bae6ff6014e7af7f675e98f5091a07
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
When generating a PDF report with an action having 'attachment_use' set and when the pdf of at least one record has been already generated but not all, an error is raised for no reason.
X-original-commit: 7ad19283ea5c89a6629c8433b468d1dac3fdad4d
Part-of: odoo/odoo#93516
With this commit, the LooseVersion function comes from distutils which
is deprecated [0] in Python 3.10 is replaced by parse_version.
[0]: https://peps.python.org/pep-0632/
Part-of: odoo/odoo#91927
https://github.com/odoo/odoo/pull/85150 introduced the method
_render_qweb_pdf_prepare_streams called from _render_qweb_pdf
giving it its res_ids.
Two places in this method are assuming res_ids will be a list, but
it is not always the case. Plenty of call to _render_qweb_pdf is
giving it a single id as a parameter.
This will ensure that res_ids is a list by creating one for single ids
too before proceeding with the logic of the pdf rendering.
closesodoo/odoo#91631
Signed-off-by: Laurent Smet <las@odoo.com>
For the Switzerland localization, we need to append some extra pages during the PDF generation such as QR barcodes or ISR payment slip.
There were multiple difficulties with the current codes:
- The ir.attachment was generated before the hook allowing to append the extra pages.
- There is no existing hook allowing to get the pages for each invoice when printing on multiple records at once.
This commit aims to dispatch the generation of PDFs from the creating of extra attachments:
- `_render_qweb_pdf_prepare_streams` is called first and creates a stream for each record containing the PDF pages.
- Then, the ir.attachment are generated if necessary.
- Finally, all streams are aggregated together to get the final PDF.
Task: 2726507
Part-of: odoo/odoo#85150
To reproduce
============
- Create a company with a complete Swiss address (street, city, zip and country).
- Install the l10n_ch modules and install the Swiss plan comptable in the Settings of the Accounting app.
- Go to Accounting > Configuration > Settings > Activate the "QR codes" > Save
- Go to Accounting > Configuration > Journals > Choose the journal for the invoices > In "Advanced settings" verify that the communication type is "Based on invoice" and the communication standard is "Switzerland"
- Go to Accounting > Configuration > Journals > Select your bank journal(s) > Verify that you have set up your bank account number and the name of the bank
- Go to the Contact app > Configuration > Bank Accounts > Choose the one you use for the QR-bills > Edit > In "ISR Client Identification Number" refer a client number and make sure account type is 'IBAN' > Save.
- Verify that you have a complete address on the contact form of the customer (street, city, zip and country).
- create multiple invoices for this client
- try to print QR-bill for these invoices at once -> and assert error is raised
Purpose
=======
the `assert len(outlines_pages) == len(res_ids)` fails because the generated pdf
contains only a single invoice.
this issue is caused by the line `<script>document.body.className += " l10n_ch_qr";</script>` in `swissqr_report.xml`,
when `wkhtmltopdf` generates the pdf from html, it doesn't wait for all javascript to finish before rendering the page,
which lead to not execute the script `<script>document.body.className += " l10n_ch_qr";</script>` for some pages then the final pdf
is missing some pages.
Specification
=============
To solve the issue we removed the javascript block `<script>document.body.className += " l10n_ch_qr";</script>` from the template
and move it to python, by setting the body style when generating the html.
opw-2772396
closesodoo/odoo#89835
X-original-commit: a669b4c5f78aa18b87f5adcfc5acca3ce0a76040
Signed-off-by: abla001 <abla@odoo.com>
Fixesodoo/odoo#86216
When printing qweb report use the current company.
For example, the company logo printed was always from user company
default instead of the current company.
closesodoo/odoo#86356
X-original-commit: becdd7d54a5dd7dc50ca1458951f98f95b011d56
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
The `_sequence` was only used for the insertion of data in the DB for
the `id` value. But in Odoo, the `id` is always a `SERIAL`, then the
PostgreSQL fill already the value by the right SQL sequence. Then,
avoid doing the job of the DB by ourselves.
Sadly, we need to manage the case when we create an empty record to
always get a valid query.
task-2735546
Part-of: odoo/odoo#82727
reportlab package is already in use to print barcodes, but it requires
extra packages (pylibdmtx and libdmtx) to print Data Matrix barcodes.
Unfortunately the python3-pylibdmtx package is not currently in the
Ubuntu version being used by Odoo SaaS and odoo.sh => we cannot install
this package automatically. Therefore we leave both packages as optional
extra installs for users since pylibdmtx is available via pip3 and
additional libdmtx package can be installed at that time (libdmtx0b on
linux, other OS info in pylibdmtx pip page).
We default to Code128 to avoid blocking stacktrace in case
Reportlab cannot print Data Matrices.
Part of task: 2494740
Part-of: odoo/odoo#82389
First step to stream QWeb templates: removing the two post
processing operations applied on rendered templates. This
should slightly speed up the rendering of every page.
1/ Don't remove empty lines after rendering, but fix the root
cause of: view inheritancies and QWeb compilation that don't
add extra empty lines.
2/ handle page break in the two reports that uses it, rather
than processing every view produced.
closesodoo/odoo#82244
Related: odoo/enterprise#23328
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue:
Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user.
However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong.
Fix:
- Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write
- As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs.
closesodoo/odoo#78966
X-original-commit: 0b4efd37376223806e7ff7273f520b2d17337bc8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Though it can't really be typechecked it makes clearer what the
expectations are.
closesodoo/odoo#77577
X-original-commit: b28d2f5b9f7ca0656afe8020c1fa4b3c4eb5594b
Related: odoo/enterprise#21336
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Xavier Morel