What the difference is between the menu items for opening a report and printing a report?

For me it seems that both opening a report and printing a report do the same.

I understand that I can change the definition of the report to create PDF but then both ‘open’ and ‘print’ will only open either LibreOffice or a PDF.

There is also a print directly checkbox on the report definition but that seems to do nothing.

The open is use to be open the file on your computer.
The print is used to directly print the file to a printer.

But the problem is that direct printing depends on the operating system. If you are using linux you may be interested in Issue 6999: Enable direct print on linux again - Tryton issue tracker

I think this is the best solution for Linux users: “to have an option to define the printing command (like for email)”.
It would be great to have it working.

Yes we use linux and in our our old OpenERP v5 system we print either PDFs or raw text for label printers using lpr.

If this functionality is not available, what kind of workaround do you use for printing for example in a warehouse, where the user doesn’t have time to do it manually?

You just click on print button of the viewer.

@ced Yes that is a workaround:) Our warehouse workers have quite a lot to do so I’ll need to check with them if such a workaround is suitable.

If you have a printer that support email printing you can configure an email notification which send the report to the printer email so its automatically printed when the user process some workflow steps.

Thank you for the idea but in the warehouse where this functionality is needed both our label printer and laser printers are simple ones which don’t have such a feature.

If the server is on the same LAN as the printer, you can override the report to send the report content to the printer directly from the server.

You may be interested in the printer module.

It allows you to list the printers available in the server’s CUPS and define rules to decide where reports are sent to. You can make rules such as: “all reports printed by user X should be sent directly to printer Y”, “report Z printed from IP should be sent to users’ default printer”, “report Z should be sent to the user”, etc.

You can play with the following parameters:

  • User
  • Group
  • IP Address of the client
  • Report
  • Printer state (do not send to printer if it is not working, for example)

For each combination of those parameters you can define the action (send to printer or to the user) as well as default printer to use.

The module already works with jasper_reports module but you’d need a few lines of code to make it work with core reports, your own or html_report (a patch would be welcomed for the latter).

That sounds great @albert! I will try it later.
At the moment I’m using the email button setting this at the configuration.

lp -d Zebra_Technologies_ZTC_S4M-200dpi_ZPL ${attachment}

You must know that you are loosing the email function in that PC.



Just looked at the code and the module only works with jasper_reports because it forces to use jrxml templates :man_shrugging:t2:

Also it only works with PDF output

That’s what I said, yes: it only works with jasper_reports right now, though making it work with other reports will be easy.

The reason it only works with jasper is that there was no interest to make it a core module so we cared for our use case at that moment. Now that we’re moving to html_report, support for it can be expected in the future.

Sure, don’t know of any printer that works with other jasper output formats such as XLS.

I guess you refer to this discussion about adding the hook which as commented is not required.

Even, if you want to build some ruling system to print a report automatically I think it’s better to base it on triggers and print the report when some of them happen. This will avoid the need of the user of clicking on the print action and in case the report needs to be reprinted the user can always using the print it manually on his prefered printer.

Yes, I think at that time I thought that the Mixin didn’t work because I needed the action, but I guess I was wrong because of course I’d have the cls.__name__ :sweat_smile:

Thanks for pointing it out again!

That can be an improvement.

Yes, such a functionality would definitely help. Thank you for suggesting.