There is an issue when exporting pdf using edi documents created before
the PDF/A commit. With the subtype now included, the system would try
to use the subtype given by the ir.attachment which would not be formated
as expected by the pdf file format.
The attachment may get neutered by the ORM, so we may have to force
the mimetype when embedding it.
This fix in two parts will allow to force a subtype when adding an
attachment into a pdf, as well as parse the subtype of ir.attachment
to give them the right format.
xxx/xxx should become /xxx#2Fxxx
opw-2714040
closesodoo/odoo#81898
X-original-commit: 880d7a1c8474a3bee4fd05474788fbd4a63f4ae7
Signed-off-by: Laurent Smet <las@odoo.com>
We do not want to fail ever if loading the attachment fails.
We still log a warning in every case though.
Some malformed PDFs lead to seeking the wrong bytes while looking for
some parts, raising a ValueError
closesodoo/odoo#68171
X-original-commit: f4cc0579a3e0ee9c117c7dd0f6090edc6e94384d
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps:
- Install accounting
- On the dashboard, try to upload an "encrypted" PDF like this one https://launchpadlibrarian.net/24827090/DS-0157.pdf
Bug:
Traceback:
PyPDF2.utils.PdfReadError: file has not been decrypted
Explanation:
In 13.0, these errors were caught in a catch all `except` as shown here: https://github.com/odoo/odoo/blob/4e089041252c25cc197a30f9e285d82f7162d809/addons/account_facturx/models/account_move.py#L303-L328
From this SO comment: https://stackoverflow.com/questions/52047944/pdfbox-extracting-blanks-from-pdf-encrypted-with-no-password#comment91054285_52047944
> A PDF can be encrypted with two passwords: a user password and an owner password. When a PDF is encrypted with a user password, you can't open the document in a PDF viewer without entering that password. When a PDF is encrypted with an owner password only, everyone can open a PDF without that password, but some restrictions may be in place.
From time to time, we get a PDF encrypted with an owner password. The
content is still readable, but PyPDF2 fails because it thinks the PDF is
encrypted. With this fix, we try to unwrap the PDF by providing an empty
user password. This way, PyPDF2 thinks the content is now decrypted.
However, PyPDF2 only supports decrypting versions 1 and 2 of the
encryption implementation. If the version is different, we skip reading
the attachments and carry on to allow the user to upload the document.
opw:2375993
closesodoo/odoo#64320
X-original-commit: 851fe64f7789bb398383c22e3ebbaebb051791f6
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
By default, PdfFileReader will monkeypatch the `warnings` module even
if it has no reason whatsoever to do so and suppress the
`captureWarnings` behavior.
This means as soon as we've loaded a PDF file, `warnings.warn` don't
trigger `logging` warnings anymore, and become invisible.
This can lead to non-deterministic behaviors depending as warnings may
or may not be suppressed depending when they occur relative to loading
a PDF e.g. load a module which runs a test which loads a PDF before a
module triggering a warning and the warning won't be visible, other
way around it will.
Except ofc while we have an override to PdfFileReader it's not
used *everywhere*, so need to monkeypatch the init.
closesodoo/odoo#60132
X-original-commit: 6b04dbcd4204a75d6bd68fc0b3010a2297779b32
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In the PDF, `DictionaryObject` can be wrapped in `IndirectObject`. For nested
dictionaries, using `get` on a `DictionaryObject` will unwrap the result if it's
an `IndirectObject`, but not `__getitem__` so when trying to futher call `get`
on the result will cause an error: we need to unwrap the object first.
Instead, we patch `DictionaryObject.get()` for it to unwrap the object in case
it's an `IndirectObject`.
This is a follow-up commit of fece5ab1bf2fef043b131f1bd0886f0841116103
closesodoo/odoo#53269
X-original-commit: 189a0b28ec7fdb7472f936450cfd7b4bfd6912ed
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Depending on the PDF version and the presence of embedded files, the PDF
document catalog `trailer["/Root"]` may not have any Name Dictionary
`["/Names"]`, and the latter may not have any `EmbeddedFiles` entry.
In that case `getAttachments()` should return an empty list rather than
raising a `KeyError`.
closesodoo/odoo#52312
Ref: Section 7.7.2, 7.7.4 and 7.11.4 of [PDF 1.7 spec](https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf)
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
To avoid having to fixup half a dozen places where we're creating PDF
writers, and possibly ending up with new ill-configured writers in
the future, patch PyPDF2's own writer with a subclass setting /Creator
and /Producer.
Note that this will not affect non-post-processed PDFs generated by
wkhtmltopdf. wkhtmltopdf does not allow setting these properties[0][1], so
to fix this issue we'd have to alter _run_wkhtmltopdf to pass the
result through PyPDF2 in order to alter its metadata.
[0] https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2000
[1] https://bugreports.qt.io/browse/QTBUG-44451closesodoo/odoo#29460
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Nicolas (vin)