1 of 1 people found this helpful
An answer to one piece of the puzzle - it is possible to create a package which has no Queues included in it and have that be installed by all direct queue users. This would allow (given the correct scripts) feedback for print jobs using just the one package. Inclusion of queues in a package is to provide the ability to install the printer driver and to ask specific popup questions. If drivers or questions are not needed, then a package without queues will still install the Notify client (as a component of the Popup client) - allowing notify scripts to pass information back to the client for display.
Mac Popup clients will also display notify messages.
The default PrintEndJob - Notify User.txt script only provides feedback for Direct queues - although this could be changed if there was a use-case to fit the change.
Hope that is of some use.
1 of 1 people found this helpful
Changing the default error message at a release station to something other than "No suitable print available" is an excellent suggestion, and I anticipate that would benefit a large spectrum of the Uniprint customer base. If it included a reason why, that would probably be even better. Maybe even a custom error message defined at the device level could be provided (like the local prompts on PC Pharos Stations) so that you could include different instructions on who to contact and/or to suggest the next closest printer. Someone at Pharos would have to comment on whether or not there is any current way to modify that message or intercept it via script. One of the dev team could probably answer that immediately whereas I would need to go in and research it to see if I could figure out a way.
Update: I just looked at the PrintEndJob script, and it looks like the "No suitable printer" error message could be intercepted and replaced with something more descriptive.
Like Katherine said, it is definitely possible to create a print package that has no queues in order to simply install the Pharos Popup and Notify software which would save you from having to create hundreds of packages. This software-only package would be the same site-wide (well almost, one version for 32-bit and another for 64-bit), and would exclusively serve the purpose of getting the notify client on the machine so that the server can send messages back downstream. The automatically generated one via Pharos Administrator would only work for Windows, but you can download (and customize if desired - see community links at bottom) one for Mac as well. Here is a link to the Mac Popup/Notify installer: Macintosh Components. However, the mere presence of the notify client is means that the PrintEndJob script variable "bFallbackToWindowsInfo" must be set to true for the script to work. I have not looked into whether a job submitted without popup information contains a client hostname or a client IP address. If the former, you would need DNS resolution back to the machine submitting the print job as well as a network route and the firewall on the submitting machine to allow incoming connections on port 28201. If it comes in as an IP address, then DNS would not be a factor, of course, though you would still need a route and the firewall would need to allow the connection initiated from the server back down to the workstation on 28201. Maybe Katherine Baynton could confirm between host name and IP address, or you could play with the script and see.
The Job Information plugin event is where I would normally hook into a SecureRelease job to deliver confirmation that it has been received or whatever. You would want to create an exception for MobilePrint and Direct jobs as well (similar to the MP and non-direct check/script exit in the PrintEndJob script).
A final note regarding feedback... This is technically doable, it just requires scripting and notify. In the event of a failure, you could provide a notify box that asks for input from a user (or provides a list of choices) and then feed that input into an external plugin that results in an email being sent, or a entry appended to a separate log file or whatever.
Both of you, thank very much. This is great information that I will put to use.
If PrintEndJob script can intercept the default error message and replace it with something else, might portions of the message be populated by parameters such as printer device, printer status, similar to what the device status check reports in the Administrator? This would greatly help to make the message more informative and useful.
On our Windows systems, DNS resolution should not be a problem and if it is I'm certain we can remedy that. On the Windows systems, at least the client IP address should be coming through (in the Windows Event Logs, if logging of print transactions is active, the IP address of the sending computer is logged at the very least, perhaps the client host name as well but I'm not certain of that). I don't know if the Mac systems include client host name, but I do know Linux systems usually do the IP address.
- Paul L.
Regarding your questions of what else can be sent through the script, I will start from the basis of assuming that the preference is to stick with the built-in functions and features of the Pharos product. You could, of course, call an external plugin that would go out and perform an SNMP status query on the device(s) in question, but realistically you will just need to play around with this a bit (Pharos Scripting Documentation). I would expect that the PlugIn.Printer var would most likely be populated, but I have not previously tried it to know with any certainty when it is populated versus when it is not (nor would I be able to guarantee which printer name would be held in the variable - if any - in the event that you have multiple printers hooked up to a single direct queue... e.g., two devices side by side and the system load balances between them). You could certainly add additional information to the error message, but it may not be as informative as you would like from within the scripting language. Then again, maybe the primer has a surprise or two that lets you do some things I am thinking you cannot - such as initiating an SNMP query on a device in order to add the error state of the device to the warning message.