Options
Hide a work item from all grids
Brian_Winter
Customer Advanced IT Monkey ✭✭✭
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!
0
Best Answer
-
Options
Justin_Workman
Cireson Support Super IT Monkey ✭✭✭✭✭
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.1
Answers
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.