Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A per-printer 'job hold policy'? #2578

Closed
michaelrsweet opened this Issue Oct 30, 2007 · 5 comments

Comments

Projects
None yet
1 participant
@michaelrsweet
Copy link
Collaborator

michaelrsweet commented Oct 30, 2007

Version: -feature
CUPS.org User: murdie

We'd like to implement 'job hold and release' here using CUPS - see my
discussion in http://www.cups.org/newsgroups.php?gcups.general+v:31157
I think that CUPS provides almost all the functionality that would be required to do this, as what is needed for an ideal solution is a specialised touch-screen interface per-printer which displays the jobs in the printer queue with a select-for-release (and also a delete) button next to each job. This would be implemented by a separate program running on a networked unit placed next to each printer. We've already provided touch-screens in our kitchens to permit staff and research students to purchase beverages etc electronically.

All I think that I need from CUPS itself is to be able to set a 'Job hold policy' on the 'Set printer options' page for each printer to control whether jobs sent there should: i) not be held by default (overrideable); ii) be held by default (overrideable); iii) always be held (mandatory); and then whether: i) any user can release held jobs, even other users' jobs, without password; or ii) a password is required to release them. The CUPS API would have to allow the printer-adjacent unit to command the release of the held jobs. Deleting a job would always require a password.

Being able to set job hold as default for a queue would also allow us to provide the functionality (in limited form) to non-IPP clients whose print protocol does not include a standard 'hold job' command, e.g. our Windows client PCs, whose Windows Server uses Berkeley LPR protocol to our CUPS server as Windows Server cannot publish IPP printers to the clients.

John A. Murdie
Department of Computer Science
University of York
UK

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

michaelrsweet commented Jan 16, 2008

CUPS.org User: mike

Not sure how this is different from doing:

lpadmin -p printer -o job-hold-until-default=indefinite

and then releasing the held jobs from the web interface?

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

michaelrsweet commented Jan 17, 2008

CUPS.org User: murdie

I must admit I'd not seen how much of the desired functionality that:

lpadmin -p printer -o job-hold-until-default=indefinite

would actually give us. If I understand correctly, however, this may be overridden for each job by the user - it's just case ii of my wishlist (case i is no hold by default). Case iii is when the hold to be mandatory (e.g. to prevent accidental immediate printing on a secure printer, or one on which we always require the user to confirm at the screen by the printer that the printout is required). (A case iv in which no holding is allowed just isn't required.)

Then there's the other setting I mention we'd like - whether any user is allowed to release a held job without a password (instead of the default configuration that allows only the submitting user - or a print administrator to release the job, with a password). We talked here about this as a no-fuss way to hold a job until a colleague has put some special media into the printer and is ready to release it for us without being present at the printer oneself. Perhaps this is just frippery; I can't remember any better reasons given in the conversation I had with a colleague about this, and neither can he.

There are two strong reasons for my asking in general for such extra job release functionality. First, we'd like to set mandatory print holds on some queues to force users to confirm at the printer that the printout is really necessary, and that they are there to collect it - to save paper wastage. (Though for printers in the same classroom as the user I think this is silly.) Second, some administration staff ask for and get uneconomic but desirable personal printers on the excuse that a shared workgroup printer would be insecure. If we could offer them a common shared printer with mandatory job hold and release in a separate room, their excuse and their printers would be taken away from them and some money would be saved.

John A. Murdie

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

michaelrsweet commented Jan 17, 2008

CUPS.org User: mike

STR #618 includes provisions for forcing particular defaults by appending "-force" to the option value - that will be part of CUPS 1.4.

As for allowing any user to release, that's just an IPP policy thing - remove Release-Job from the list of job operations requiring admin or owner in the default policy and then any user can release a job for printing.

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

michaelrsweet commented Jan 18, 2008

CUPS.org User: murdie

Thank you. I think that my RFE is subsumed by the one you mention, in that case. I don't have time to look now at making such configurations in practice to confirm that this is indeed all that we need, but your reply is sufficiently convincing that I think that perhaps this STR can be closed.

John A. Murdie

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

michaelrsweet commented Jan 18, 2008

CUPS.org User: mike

OK, partially a dupe of STR #618 with some massaging of operation policies. Final support for this will come in 1.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.