It helps if you fill the bug report completely. So, please tell what platform you see the bug on.

A few other answers needed:
- is this your machine at home or a workstation in a larger network (e.g. at a company)
- if you're not the system administrator of the machine, did you speak to your system administrator?
- do you happen to know if your underlying printing platform is configured to be CUPS?

Thanks for your bug report.

Hmmm don't remember the bug report asking me what platform I am using... I have a network of several X86 machines, some laptops, some desktops. When I got this error message, I was trying to print a job from my laptop, a Dell Inspiron 8100 running SuSE 9.2 Linux, This laptop was sending the print request to a desktop computer, also an X86 machine running SuSE Linux 9.1 which was acting as a print server and yes it is configured to be a CUPS printing platform.

I finally figured out how to delete a print job, once it has been submitted like this. I had to log in as ROOT, on the desktop computer running CUPS, and delete it from there. By the time that is accomplished, in an emergency it may be way to late and the printer may already have printed out reams of useless stuff. This is a lousy way to have to delete a print job!

There is no way you can ever convince me this is a good model for handling print jobs! If I, as a user, submit a print job, I most certainly ought to have access to whatever resources are needed, and permissions required to delete that job should I need to. I should NEVER have to ask someone else such as a system admininstrator, or figure out that I have to log in as root on the print server, to kill a print job. It is and should remain MY job, I should retain all permissions and rights to that job until it is fully printed out and I should ALWAYS have the right to abort it and/or remove it from the print queue, no matter whether I am printing directly from my own computer, or across a network to a print server. PERIOD!

I am my own system adminstrator, but I am NOT a Linux guru. I am just a simple user trying to run a small network who wishes computers were a lot easier to understand and had a more intuitive model, especially for handling errors. I will argue that in this case, this may not be a true error, but an extremely badly designed piece of software that is falsely reporting an error where none should have been... I should have been able to delete the print job WITHOUT any hassles, If permissions were required, for some reason I cannot fathom, such as needing the root password on the print server, I should have at least been prompted for it, but I would argue this would still be an extremely poor and user UNfriendly solution!

Please calm down. One piece of software (in this case kjobviewer) will _not_, ever, fix _all_ your possible computing problems.

We are now both here to try solve and fix this problem for the future the best we can. This means identifying _what_ the problem is, in the first place.

I understand very well your frustration but I can't do anything about it without knowing more and for this I need to ask questions, so bear with me.

It indeed seems that your desktop machine's CUPS is configured so that only members of system administrators group can remove jobs once submitted.

I recommend you to look into the documentation regarding configuring CUPS on your desktop machine, as this is out of the scope of what kjobviewer can (or should) do. If the printing server refuses users access to the jobs in queue, kjobviewer can't do anything about it. It's a question of security.

Thank you.

I am quite calm, thank you.. Just frustrated with the sort of programming displayed by kjobviewer in this instance. I see so much of it! Contrary to your opinion, that kjobviewer cannot do anything about this error message, I strongly disagree with you. My original complaint, about the error message I got, stands, and I will not retract it. If a program such as kjobviewer simply cannot handle a user request, such as in this case when it may have encountered a difficulty beyond its control, it should respond with an error message that not only states clearly and plainly what the problem is (This it did NOT do!), it should also TRY and guide the user to a solution. Since kjobviewer is the front end program that users are interacting with, it is its responsibility to interpret and translate all error conditions into something the user can understand and act on. This is the essence of a great program, where users are not left hanging, with a message that simply translates to "I'm sorry, I can't do that, and I am not going to help you figure out what needs to be done either!" That is what this particular error message I got effectively told me and that is why I am complaining.

You did a great job of asking me questions to diagnose where the problem might lie, and I thank you for that. But instead of forcing me, and every other user, to track down where the problem is in this manner, by submitting a bug report such as this, or finding some Linux guru to ask; why not do exactly what you did via the error handling mechanisms of kjobviewer when this error is generated. Have the program ask the user questions, if necessary, such as what the system configuration is, if it cannot automatically figure it out programatically. Then have the program explain that the CUPS server is refusing users access to their jobs in the print queue, if and when the program determines that might be where the problem lies. 

I realize there are lots of possible causes for errors, and the number of possible solutions is also large, but you must realize that most users are NOT Linux gurus and need guidance when errors occurs. Design the error handling subsystem of kjobviewer so that, for each and every error condition it can encounter, a clear and simple explaination is given, one that most naive users can comprehend. Then have the program try to do some simple analysis (it does NOT have to be an expert diagnostics subsystem) looking for solutions that cover the most likely causes and common problems. And be realistic, don't just cover the simple/obvious problems such as telling the user to check to see if the printer is plugged in. The more helpful your program really is, the more your users will appreciate it, and the less likely they will be to submit nasty bug reports. At least you will give your users a feeling that your program is trying to be helpful even if it ultamately fails to find a solution to a problem. 

The error message I got said I didn't have access to some resource, and I am arguing that error message is nearly useless, to me and to almost every other average user who will encounter it. I had no idea what resource or what access it was talking about and it did not give me any realistic clue as to how the problem might be solved. Kjobviewer, like any other program, not only has the responsibility to implement commands issued to it by the user, it has the responsibility to educate the users on how best to use and work with it. Sometimes that is done (usually poorly) with external help files and documentation, but it is far better done interactively, with the program itself acting as a guide to help the user find a solution, both for errors and for accomplishing normal/expected tasks, while not overwhelming him/her with too much information.

And finally, take this as a red flag, that you may have other bad error messages also, in kjobviewer. Examine all the possible error messages that kjobviewer might generate and look at them critically to see if they are clear and understandable. Then look for ways to have kjobviewer guide the user to a possible solution(s) for each of them. You do that, and you will have one of the key elements of a really great program in place - a helpful error handling subsystem. This often gets overlooked and ends up badly designed, hence mine and many other users frustrations...

Changing the error messages is one thing that has to be done, indeed. This won't solve your problem, though. It's a server configuration problem, and as network admin, it's your responsability to read the doc and configure the server correctly. CUPS is a very flexible, but complex piece of software. It is configured by default with high security. In your case, it's probably about the "/" or "/jobs" resources of the CUPS config file that is limited to admin or local (non-network) access.

KDEPrint in KDE3 is unmaintained and will have no more new features
implemented.  This request will never be implemented in KDEPrint as a result.  

In KDE4 kjobviewer has been replaced by printer-applet which uses
system-config-printer as a backend.

Closing.