I'm a new KACE Appliance admin so I apologize if I'm out of line here.  I was wondering if anyone received a response from KACE concerning restricting visibility to queues based on being a Ticket Owner.  I just spoke to support who indicated that even with the 5.4 upgrade, this is not possible.  I'm trying to give Owners the ability to see all tickets in only their queue not just their tickets.

Update to this

Preparing to launch a queue for a user department, and this has brought me up against a dilemma.

- If I leave the support techs for New Queue with just the user interface, they can't see Unassigned tickets in their queue and therefore can't pick them up. Not good.
- If I make them Ticket Owners in their own queue, they (thanks to the bug) gain Ticket Owner status on all queues in my helpdesk, not good.

Urmmmmm.... [:@]

I'll report the bug and hope for a fix...

OK, today I did my 5.3 upgrade - smooth as a smooth thing - and this still seems to be happening; Ticket Owners for any queue can edit any ticket in any queue. So it does look like a bug, and I'll log it as such.

Thanks all

What server version are you guys on?

Hm - I have my upgrade to 5.3 booked for Wednesday... I'll do that first and then retest and see if anything changes. If it doesn't, I'll log a call!

Airwolf - in our tests you could see tickets in other queues and work and modify them but not take ownership. Unless something has changed, we have see that on our own and with other clients.

Owners in one queue cannot do anything in another queue (cannot even see that it exists) unless they also have owner rights in that queue. If your tests prove otherwise, you should contact support.

EDIT: Obviously they can see the queue and submit tickets if they are a submitter, but as a submitter in a queue they are not an owner in, they can only see tickets they have submitted in the other queue.

I think the issue is that they can still see tickets of queues they are not owners of, even from the User Portal and no admin rights, just ticket owner labels and permissions to own tickets.

Why do the helpdesk techs need into the admin portal? They can managed tickets in queues they are owners for via the user portal just fine.
Orgs is way overkill for separating some helpdesk tickets.

You could but things to consider

1. separate queues or orgs mean different email address for ticket submission or training for staff on how to submit via GUI
2. Global reporting can be done across ORGS but they are separate DB's
3. multiple permissions settings and documenting


If there is a concern of other people changing or modifying tickets, remember that there is an audit log in every ticket on who made the changes and what was changed. You can take away their ability to delete tickets if you want to so they can't cover their tracks if you will.  The decision is of course yours based on your environment and work flow.  Hopefully you can outline the benefits and cons as ORG's might be a great short term fix but what long term issues might come up or vice versa for doing multiple queues.

Ho hum. So if that's the case, I would be better off using Orgs instead of queues if I want control of my helpdesk workers, as presumably this doesn't operate across organizations?

nope...that is the way it works. There currently isn't anything that will change that in the settings. You might want to use the green "Help" Button on the right on the GUI of the admin portal in the KBOX and submit a feature request.

Ah, no, I thought of that (not quite as dumb as I look!) there can be only one, and that one (apart from Admin the account) is me.

nshah, what you describe is what's happening (a user included in the label marked as Ticket Owner on any queue seems to get that privilege on any queue) but that's got to be wrong; if it was meant to work like that the option would be on the general options not per queue, surely?

If you are a ticket owner you should be able to view/modify but not take ownership of tickets in other queues. Permissions with multiple queues, as Airwolf, described is not that granular.

Is UserB an Admin in the K1000? Full admins can modify any queue.

Ah, right, got that. If all users can be submitters, all users can create tickets. Duh.

But what I have here is UserB who is a Ticket Owner on the Test Queue, who can switch to the Main Queue of which he is NOT a Ticket Owner, list all the tickets and edit any of them....?

He should only be able to edit ones he himself has created shouldn't he?

That means anyone can submit a ticket. And they can see/edit any user editable fields in tickets they have submitted.

Ah. So if I have "Allow all users as submitters" that would perhaps be the problem?

If UserB is not a submitter, approver, or owner in the primary queue, they should not be able to even see that it exists. If UserB is a submitter in the primary queue, they can create tickets but only see/edit their own submitted tickets.

Mmmn
After some tests...

UserA has label All Ticket Owners, which is set on the primary queue as "Ticket Owners By Label"
UserB has (just) label All TestQ Ticket Owners, which is set on the test queue as "Ticket Owners By Label"

UserA can create a ticket in the Test Queue, then UserB can edit it, save it, then edit again and move it to the main queue
UserB can then go to the main queue, edit the ticket and save it again.

I'd have expected UserB to not be able to see the contents of Main Queue much less edit them. This was what happened when I tried this before. Or have I missed something?

Sorry if I'm being dense

Mmmn, queues sound like the answer then. I only want to restrict people to one queue or another, not granularly within them, so that's OK. In point of fact, Amsterdam have only asked for Service Desk so far, so at the moment they don't need inventory (classic "what can we have for free").

All in all, it does look like queues are the way to go. Comforting, because if I make a pig's ear the first time I can dump the queue and go back :)

Cheers Andy. On the nail as ever!

Well, you're limited when it comes to permissions for something like machine/software inventory. It's all or nothing, so if you want separate management of inventory and/or assets, you'll have to use multiple ORGs.

Queues have three permissions: submitter, approver, and owner. If someone is an owner in a queue, you cannot restrict them to specific categories or tickets - they have full access to the entire queue. It sounds like you just want to limit people to ownership in specific queues - and you can definitely do that. We have something like 12 queues, and our users can only submit to one, and most of our IT staff can only see/modify one.

Thanks Andy!

There are a few more considerations, which I left off as the description seemed to be getting terribly long. Amsterdam have their own AD and PCs, which I'd prefer not to have bunched with mine for scripting and so on, which is why I thought of Orgs; I guess I could smart-label them on login domain though?

More to the point I want to be able to control the ability of the users in the secondary queues to edit tickets outside those queues. In other words, have a "All CLC Ticket Owners" and an "All Cargo Ticket Owners" label able to edit just their own queue's tickets but NOT tickets in the main queue. Can this be done with Queues? I had a try but couldn't work out a way.

Cheers!

You want to use multiple queues in the same ORG. In separate ORGs you would have completely separate databases (e.g. different machine inventories to link to tickets, different queues to move tickets between, etc.).

EDIT: I realize I wasn't very clear on this, but there is nothing you described that isn't possible with multiple queues in the same ORG.