POC2 - Auto printing

[gdgellatly]

OK I've completely rethought the design, I need to wait until base_report_to_printer has merged plus a bug fix on queue but here is a couple of screenshots - pretty excited by what we will be able to do.

It's next to no code. Just adding a new type of server action with the printer fields, linking it to reports and decorating print job.

[gdgellatly]

There is now a working implementation for anyone wanting to follow or contribute ideas to this.
Extra screenshots in images directory.
Still an alpha WIP - but it works, hopefully next month or two once dependent PR's are through I an finish this up.

https://github.com/gdgellatly/report-print-send/tree/11.0-refactor-auto-print

[lasley]

@gdgellatly - I think leveraging queue in print is a good idea yeah. Question though - any reason we can't just do it in a glue module instead of the core base_report_to_printer? Queue has some additional required setup, so requiring it in a base module I think isn't a good way to go.

Seriously though having a queue for the printing is exactly the way real print servers works, so it makes absolute sense here. Bonus points if we can figure out how to dynamically make channels, which would allow for virtual queues at the printer level.

[gdgellatly]

@lasley absolutely, its a piece of cake, it was in this module originally.

All I did was decorate print_document with @job and call it with_delay, returning super of the main module.

As for the other part, dynamically setting queues, above my paygrade, but my guess would be that we would do it in the update_printers_from_cups functions of printing server and actually now that I think about, probably not that hard.

[gdgellatly]

@lasley just had a think while in shower. I think if we do dynamic queues we are better to do at the CUPS server level if at all. Afterall, CUPS handle queues for the printers, so we basically treat the Odoo server as sending the documents as received for that server and let the CUPS server sort it out. I can kind of see some edge cases, so idk maybe at printer level where you have 1 slot per printer (that way long running reports aren't overtaken by shortrunning reports and docs print in order if that is something important to you - it is to me).

[lasley]

I use this for prescription label + med guide printing into multiple remote pharmacies, and sometimes into a robot. The ordering is definitely important to me as well, otherwise our printer jobs get out of sync with each other.

So yeah I think you're right - we'd need one channel per CUPS server, with the CUPS server handling the rest. If you need faster printing, the channel runner count can just be enabled - assuming the server on the other end can handle the load and you're [the sys admin] not worried about sync/concurrency issues. That's basically what we're doing today with cron workers, just more defined and unified.

[lasley]

One possibly major shortcoming to this would be the masking of printing errors at the user level. We may need to also override the queue notifier to send the print failed notification to the user that printed instead of just the connector managers.

[gdgellatly]

You are right, I'll think about, it shouldn't be that difficult. It doesn't actually apply to the use case for this module which is printing via automated action as in my original use case the server not the user was responsible for ensuring documents were printed.

I'm actually not very familiar with the user notification system for base_report_to_printer but I don't think the queue notifier is the place for it to be inserted, but rather just in the regular printing functions. Currently printing.printer.printfile just returns True and I can't see anywhere where job updates notify the user currently. I don't think that part will be a big challenge though, we have so many notification tools available.

[lasley]

I'm actually not very familiar with the user notification system for base_report_to_printer but I don't think the queue notifier is the place for it to be inserted, but rather just in the regular printing functions. Currently printing.printer.printfile just returns True and I can't see anywhere where job updates notify the user currently. I don't think that part will be a big challenge though, we have so many notification tools available.

Basically if a job fails, members of "Job Queue Manager" ACL are sent a notification. Because the jobs are performing async, there's no way to actually notify the user via the UI.

You're totally right though - piece of cake, was just worth mentioning for consideration. We need only override the notification method and add some custom logic. It might make sense to add this in abstract to the pre-existing queue_job_subscribe, which is ambiguously named currently because it actually makes it so you're NOT subsribed to the queue in the event of some logic.

[simahawk]

Basically if a job fails, members of "Job Queue Manager" ACL are sent a notification. Because the jobs are performing async, there's no way to actually notify the user via the UI.

I think there's a way: the bus. You can create new notification channel and send notifications to it. A talk at OdooExp showed us that you can send real-time updates from backend/server side to the frontend.
I don't know enough about the internals yet, so I don't know if it could fit the use case. Still worth to try tho :)

[gdgellatly]

@simahawk @lasley we are talking at cross purposes here, as I refer to print jobs, and you 2 refer to queue jobs.

A failed print job on base_report_to_printer (i.e. the job fails, not the code) will be reported as a success to queue_job. (Lets say I accidentally tested that a lot in development) Thats the bit I meant about notification. So really there are 3 issues.

1. queue_job job failure notifications
2. base_report_to_printer job failure notifications
3. not notifying base_report_to_printer notifications if in a queue_job until max retries met.

But yes, what Simone says is the general idea I had in mind. I caught a bit of that talk, just waiting for it to be released.

[yung-wang]

@gdgellatly I'm testing this module but i'm unable to print with the automated action. In the log files i cannot find anything. I installed both base_report_to_printer and queue_job. Manual printing with only the base_report_to_printer works, but with the automated action it does not do anything. The automated action is working if I do another action. Any idea what I'm missing, or do you need more information?

[yung-wang]

Never mind, i got it working after some more installing and removing.

[gdgellatly]

@yung-wang This was just a Proof of Concept. Its kind of dead, although I did rewrite and release under my own repo for v12.

[yung-wang]

@gdgellatly Seems like a very useful Proof of Concept. Why dont we put this in de OCA instead your own Repo?