Repository navigation
Conversation
Odoo 20.0 removed ir.actions.report.render_document and the IoT menu the module hooked into: printing now goes through the new printer module (printer.printer + get_print_jobs + printer.type.handlers in the client). As decided by the PO in task 76786 (option A), PrintNode becomes a printer type, following the pattern of Odoo's obox module: - printnode.account replaces the IoT box with an API key; it syncs its printers as printer.printer records of type printnode. - get_print_jobs adds a printnode job (pdf for qweb-pdf/pdf/aeroo, raw for qweb-text) and a client handler sends it with printnode_print. - The module depends on printer instead of iot (no Enterprise needed). - Account and wizard management is restricted to Settings admins, under Settings > Technical > Reporting > PrintNode.
…user get_print_jobs also runs from _read_format, under the sudo of /web/action/load and with active_ids from the client, and from report_action with docids as a recordset. Rendering there sent the report rendered as superuser back to the browser and failed with a recordset. Now get_print_jobs only adds the report and its ids, and printnode_print renders it as the user right before sending it, as render_document did in 19.0. Also: - printnode_print only prints reports linked to the printer. - Only administrators can set the PrintNode account or identifier of a printer: printer.printer is writable by every internal user. - The views add their condition to ip_address instead of replacing the ones of iot and obox. - Add the Reset Linked Printers menu that the IoT app gave in 19.0.
Contributor
|
|
les-adhoc
marked this pull request as ready for review
November 13, 2026 16:28
This branch has not been deployed
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.
Tarea: https://www.adhoc.inc/odoo/project.task/76786
What changes
Odoo 20.0 removed
ir.actions.report.render_document(the method this module overrode to send IoT print jobs to PrintNode) and the IoT menu it hung from. Printing now goes through the newprintermodule:printer.printer,ir.actions.report.get_print_jobsand theprinter.type.handlersregistry in the client.As decided by the product owner in the task, PrintNode becomes a printer type, following the pattern of Odoo's
oboxmodule:printnode.accountreplaces the IoT box that held the API key. It syncs the account printers asprinter.printerrecords of typeprintnode(create, update and delete, as in 19.0).get_print_jobsadds aprintnodejob with the report and its ids, without rendering. The client handler callsprinter.printer.printnode_print, which renders the report as the current user and sends it to PrintNode (pdf_base64for qweb-pdf/pdf/aeroo,raw_base64for qweb-text), asrender_documentdid in 19.0. Rendering inget_print_jobswould run under the sudo of/web/action/loadand with docids as a recordset fromreport_action.printnode_printonly prints reports linked to the printer, and only administrators can set the PrintNode account or identifier of a printer (printer.printeris writable by every internal user).Manifest
depends:iot→printer. The module no longer needs IoT (Enterprise); license stays AGPL-3.web.assets_backendfor the client handler.Where it is configured
Settings > Technical > Reporting > PrintNode: accounts, Add PrintNode, Printers and Reset Linked Printers. Account and wizard management is restricted to
base.group_system(in 19.0 the wizard was reachable from the IoT app).Removed symbols
All the 19.0 symbols are ported to the new ones:
iot.box.print_node_api_key→printnode.account.print_node_api_key;iot.device.connection = printnode_printer→printer.printer.type = printnode;iot.box._get_response,_print_node_submit_job,action_print_update_devices→ same methods onprintnode.account;iot.box.open_homepage→printnode.account.action_open_printnode;ir.actions.report.render_document→get_print_jobs+printnode_print+ client handler; wizardadd.iot.printnode→add.printnode.account.Data
No data migration script for 19.0 → 20.0: no production database has the module installed in 19.0. A 19.0 database would need its API key and printers moved before the
-u.Tests
The module had no tests in 19.0. New tests for the 20.0 code (10, mocking the PrintNode API): printer sync, connection error, wizard,
get_print_jobswithout rendering,report_actionwith a recordset, rendering as the user and sending to PrintNode, no job without a PrintNode printer, report not linked, unsupported report type, internal user cannot point a printer to PrintNode. They pass in a local 20.0 database. The full flow (add account, sync, link a report, print from a quotation) was also checked in the browser against a fake PrintNode API; it was not tested against a real PrintNode account.