Repository navigation
Conversation
Summary
JWT timestamps generated by onlyoffice_odoo are incorrect on non-UTC systems.
Root cause
The module uses datetime.utcnow() and then converts that naive datetime with timestamp(). In Python, timestamp() interprets naive datetimes as local time. That means a naive UTC value is converted incorrectly on hosts whose local timezone is not UTC.
Impact
On systems running in timezones such as America/Argentina/Buenos_Aires (UTC-3), the generated iat claim is shifted into the future. PyJWT then rejects the token with "The token is not yet valid (iat)". This breaks ONLYOFFICE file access and editor callbacks.
Resolution
Replace naive UTC datetimes with timezone-aware UTC datetimes:
datetime.datetime.now(datetime.timezone.utc)
This produces correct iat/exp claims regardless of the server timezone.
When doc_server_odoo_url or doc_server_inner_url fields are empty (False in Odoo), settings_validation() crashes with: AttributeError: 'bool' object has no attribute 'startswith' This happens because check_mixed_content() calls .startswith() on the raw field value without checking for False/None first. The fix: - Falls back to web.base.url when doc_server_odoo_url is falsy - Guards check_mixed_content and check_doc_serv_convert_service against missing base_url - Uses str() cast in check_mixed_content for defensive safety
This avoids Python 3.12 SyntaxWarning caused by invalid escape sequences (e.g. \/, \w, \d) in normal strings, and simplifies the pattern by removing redundant escaping of /.
This avoids Python 3.12 SyntaxWarning caused by invalid escape sequences (e.g. \/, \w, \d) in normal strings, and simplifies the pattern by removing redundant escaping of /.
This avoids Python 3.12 SyntaxWarning caused by invalid escape sequences (e.g. \/, \w, \d) in normal strings, and simplifies the pattern by removing redundant escaping of /.
Updating to type="jsonrpc" ensures compatibility with current and future Odoo versions and removes deprecation warnings.
Summary
JWT timestamps generated by onlyoffice_odoo are incorrect on non-UTC systems.
Root cause
The module uses datetime.utcnow() and then converts that naive datetime with timestamp(). In Python, timestamp() interprets naive datetimes as local time. That means a naive UTC value is converted incorrectly on hosts whose local timezone is not UTC.
Impact
On systems running in timezones such as America/Argentina/Buenos_Aires (UTC-3), the generated iat claim is shifted into the future. PyJWT then rejects the token with "The token is not yet valid (iat)". This breaks ONLYOFFICE file access and editor callbacks.
Resolution
Replace naive UTC datetimes with timezone-aware UTC datetimes:
datetime.datetime.now(datetime.timezone.utc)
This produces correct iat/exp claims regardless of the server timezone.
…e/19.0 # Conflicts: # onlyoffice_odoo/utils/validation_utils.py
This avoids Python 3.12 SyntaxWarning caused by invalid escape sequences (e.g. \/, \w, \d) in normal strings, and simplifies the pattern by removing redundant escaping of /. # Conflicts: # onlyoffice_odoo/utils/validation_utils.py
# Conflicts: # onlyoffice_odoo/utils/validation_utils.py
… at import time _() at class definition time triggers "no translation language detected" warnings in Odoo 19.0 because no language context exists during module loading. _lt() defers translation to render time.
…doo 19.0 Since Odoo 19.0, type='json' is a deprecated alias for type='jsonrpc'. Updated all three modules: onlyoffice_odoo, onlyoffice_odoo_documents, and onlyoffice_odoo_templates.
…tion-fields' into feature/19.0 # Conflicts: # onlyoffice_odoo_documents/models/onlyoffice_documents_access.py # onlyoffice_odoo_documents/models/onlyoffice_documents_access_user.py
…ugfix into develop Reviewed-on: https://git.onlyoffice.com/ONLYOFFICE/onlyoffice_odoo/pulls/89
Uploading an Office document as a template always failed: the upload widget only accepted .pdf, the uploaded bytes were stored as application/pdf regardless of content, and _convert_to_form hardcoded "filetype": "pdf", so the document server was asked to build a PDF form out of DOCX bytes and the conversion errored. - pdf_utils: detect the real source format from magic bytes (PDF vs OOXML zip) - model: store the source file with its correct name/mimetype while converting, pass the real filetype to the converter, then overwrite the attachment with the resulting PDF form (both create and _onchange_file paths) - controller: serve the attachment's real mimetype/extension on download so the document server receives the source in the format it was told to expect - view: accept .pdf,.docx,.xlsx,.pptx and update the helper text Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Member
Author
|
Superseded — reopening against ONLYOFFICE upstream (feature/19.0) instead of the fork. |
Rad0van
force-pushed
the
feature/templates-office-import
branch
from
June 29, 2026 08:42
8b19ba1 to
d0d204c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Uploading an Office document (DOCX/XLSX/PPTX) as a template always failed. Three things blocked it:
.pdf, so a DOCX couldn't even be selected.application/pdfnamed.pdf, regardless of the real content._convert_to_form()hardcoded"filetype": "pdf", so the document server was asked to build a PDF form out of DOCX bytes and the conversion errored (pdf_utilseven carried a# TODO: add convert docx to pdf).Fix
pdf_utils— newget_source_format()detects the real type from magic bytes (%PDFvs thePK\x03\x04OOXML zip header, peeking inside forword/document.xmletc.). The upload field carries no filename, so detection has to come from the bytes.create()and_onchange_file()now store the source file with its correct name/mimetype while converting, pass the realfiletypeto the converter, then overwrite the attachment with the resulting PDF form on success (rollback preserved on failure)._convert_to_form()takes afiletypeargument.downloadendpoint (what the document server fetches mid-conversion) serves the attachment's real mimetype/extension instead of alwaysapplication/pdf..pdf,.docx,.xlsx,.pptxand the helper text reflects it.outputtype: "pdf"+pdf.form: Trueare unchanged, so the end result is still a fillable PDF form.Testing
Verified end-to-end against a local ONLYOFFICE Document Server (Odoo 17 deployment): upload a
.docx→ it converts to a fillable PDF on save → opens in the editor.ruff checkpasses on the changed files.