Hide a work item from all grids

Brian_Winter

Occasionally, we'll get an IR or SR that contains sensitive information... security, personal, etc.  We'd like to be able to tag those work items so they are invisible in any grid (Active, Team, Search Results, Reports, etc.).  They'd only be accessible by direct URL that could be shared with Corporate Management, Security, HR, etc.

Alright folks, say there's a solution!

Justin_Workman

The most bullet proof way would be a queue defined by some unique value.  I would say a class extension to the IR and SR classes. Ideally, it would be a boolean field. Then scope all your roles (with the exception of the users you do want to see these WIs) to not have access to this queue.  

One thing this won't do: prevent the Work items from showing up in SQL queries.  If you have SQL Widgets that query against the ServiceManagement database, it won't be able to filter something like that out(unless your unique value comes in the form of an existing property that gets synchronized to ServiceManagment and you write all your queries to exclude it).

Another consideration of doing this method: it may potentially add a burden to the scoped access calculation that is performed by the cachebuilder.  In most SCSM roles, you will typically have all Work Items access or no work items access.  When you start specifying queue access, cachebuilder has to evaluate each work item by each user that is a member of the role which is what can cause the potential burden especially for roles that contain a large amount of users.

Another option that might work: a class extension for an alternate description.  If someone determines the work item is sensitive, they could mark it as such and either manually or through automation the description could be moved to this alternate description field.  Then you could customize the work item form in the portal and only expose that property to members of a specified group.  It's not as bullet proof, but it wouldn't have as much performance impact and would be reasonably secure.

Justin_Workman

The most bullet proof way would be a queue defined by some unique value.  I would say a class extension to the IR and SR classes. Ideally, it would be a boolean field. Then scope all your roles (with the exception of the users you do want to see these WIs) to not have access to this queue.  

One thing this won't do: prevent the Work items from showing up in SQL queries.  If you have SQL Widgets that query against the ServiceManagement database, it won't be able to filter something like that out(unless your unique value comes in the form of an existing property that gets synchronized to ServiceManagment and you write all your queries to exclude it).

Another consideration of doing this method: it may potentially add a burden to the scoped access calculation that is performed by the cachebuilder.  In most SCSM roles, you will typically have all Work Items access or no work items access.  When you start specifying queue access, cachebuilder has to evaluate each work item by each user that is a member of the role which is what can cause the potential burden especially for roles that contain a large amount of users.

Another option that might work: a class extension for an alternate description.  If someone determines the work item is sensitive, they could mark it as such and either manually or through automation the description could be moved to this alternate description field.  Then you could customize the work item form in the portal and only expose that property to members of a specified group.  It's not as bullet proof, but it wouldn't have as much performance impact and would be reasonably secure.

Brian_Winter

Sounds like a challenge any way you slice it.  I was hoping maybe a keyword in the title may be abled to be used as a switch in the JSN code that renders the grids.  Oh well.....

Justin_Workman

That might work too....I'll test that idea!