User Work Item Search

Christopher_Carver

Users (non-analysts) have asked that they have the ability to search for work items just like analysts can. Right now we have to pass them the link to specific tickets to look at in the meantime. How would I go about allowing my non-analysts users the ability to search work items?

Justin_Workman

I appreciate that scene!   
Surely there is some kind of restrictive criteria on who should be able to search those tickets?  Maybe you need to leverage Team Requests?  With Team Requests you map "team groups".  A member of that group will see tickets where they or other members of that group are the Affected User.  

Justin_Workman

This sounds like a security nightmare to me.  Typically you don't want End Users seeing the other users' work items.  Are they just wanting to search their own tickets?

Adam_Dzyacky

I thought portal 6.x introduced End User work item searching in the new top search bar? This granted users the ability to search whatever they need, but with respect to Work Item it was only items in their queue scope.

Adam_Dzyacky

Strike that. Looking into this further it looks like that feature isn't available to End Users.

Christopher_Carver

Justin_Workman said:

This sounds like a security nightmare to me.  Typically you don't want End Users seeing the other users' work items.  Are they just wanting to search their own tickets?

Well, if I pass an end user a direct link to the ticket they can see it. So I'm not sure what the difference is. This is something that ServiceNow offers and my end users split their time between the Cireson and ServiceNow.

Christopher_Carver

To add extra color to the question, this is a common scenario.

Manager: Hey Bob, didn't Jim submit several SR tickets requesting 2K bulk licenses.
Bob: He sure did, it was super easy using Cireson portal. I think there were 18 open tickets right now and all are in progress.
Manager: Hey that's great, what ticket is Kenzie's name in for a license? Her manager really wants to track that ticket.

Bob: Crap, now I have to individually click on each ticket and see which ticket Kenzie is listed.

Manager: Wait you can't search tickets on criteria like you can in ServiceNow?

Bob: Nope....{awkward silence}
Manager: Well, that sucks for you. Better start combing through Joe's tickets.

Justin_Workman

I appreciate that scene!   
Surely there is some kind of restrictive criteria on who should be able to search those tickets?  Maybe you need to leverage Team Requests?  With Team Requests you map "team groups".  A member of that group will see tickets where they or other members of that group are the Affected User.  

Christopher_Carver

Thank you Justin, I forgot about team groups. That should do it I think.

Tom_Hendricks

This is just too perfect of a setup (thanks @Christopher_Carver!) for me to create my own thread...may I share a slightly different scenario?  I'm providing customer feedback here, not trying to propose a different answer.

...conversation about looking up tickets...
Manager: Wait you can't search tickets on criteria like you can in ServiceNow and [our old ticketing system]?
Bob: Nope...{awkward silence}
Manager: Well, that sucks for you, because I need you to produce a custom report ASAP, and you are going to get quite a few more requests like this that will also require different custom queries to the DB.  It is a shame, because our old system let us do this without needing your help.  When you get a moment after that, I need you to talk to Cireson about what they are doing about this.  If they cannot give us a good answer on this, then you need to spin up a project to study replacing this product with something else in the next couple years.

Some may read this scenario and say "wow, that escalated quickly!"  Others may understand that this one feature is core functionality that nearly all other ITSM products have, and the manager's response here is actually a calm, measured reaction to the inability of most (all non-admin) users to get essential information out of this tool in a reasonable manner.  I suppose it depends on who is using the portal and how they are using it.

In my particular spin-off of this scenario, both Bob and the manager are IT Analyst users with access to the Work Item Search.  Why are they still saying this, then?  Because that feature cannot even search Service Request Categories without a hack that gets applied manually after every update, and it does not acknowledge the existence of extended properties and relationships that are in the type projection for each ticket type already listed in the Admin Settings.

Security nightmare?  I understand where that sentiment comes from, I think, but I am going to respectfully disagree.  Service Manager (and to an extent, the cached tables in the portal DB too) scopes access to objects--so search results can respect that scope and not show the objects out of scope.  For out-of-scope objects, then I am agreeing completely with the accepted answer here about using team groups.  For deciding which fields to make available in the search, the admin panel already captures who should see what type projections and getting extended properties is a reasonable SQL query away (ideally with its results cached) for any class.

Geoff_Ross

Hi everyone. Lots of on here. @Tom_Hendricks you've got some great points about the functionality of the work item search but I'll leave those to the many threads about that and answer the original question about end users getting access to search. 
I'm pretty sure you can just give them the search Navigation Node by making this public in Navigation Settings. Then they can use the full search functionality and it will respect scoping. I'm pretty sure you can export to excel from there which helps with the custom reports scenario. 

As for giving them Work Item Search in the header bar, I'm sure a small customisation could sort that is its just hidden from the list for non analysts. A setting to turn that off and on would be a good feature request.

Geoff

Tom_Hendricks

@Geoff_Ross, just to be clear, results cannot be exported to Excel if results cannot be obtained in the first place due to not having the right fields/relationships available from which to create criteria in a search.  That is the root of all other comments I made above.

Joakim_Normann

I have enabled the search ability for end users through the navigation pane. However when the end user try to search for a work item it doesn't return any results even though they use search strings that one or more of their work items contain.

We use queues for work items in order to filter what work items the analysts for different departments should be able to see, but this shouldn't have any impact on the end users search since they should always be able to view their own work items and they are able to see them under "My Requests". Why can't they search for them if they are able to see them under "My Requests".