WorkItem Search of Action Log Comments

carrie_medine · November 2016

Many times there is valuable information within the Action Log Comments of workitems, it would be great to have the ability to perform a search of those comments returning a result set of workitems.

Chris_Keander · December 2016

Came here to post this. Here, have an upvote!

Amarjit_Dhillon · March 2017

I am all in favour for this, upvosted.

Adrian_Mataisz · March 2017

We should have a master search option that searches on every WI created and it does it for title, description, comments,Results Notes, MA notes, etc.

Wendy_Craig · September 2017

Just resurrecting this one, if possible. It has 34 upvotes, but no response from Cireson. This is probably the most frequent request we get from our analysts. They feel that their detailed documentation of resolutions goes into a black hole where no one can ever find it again or reuse it.

Amarjit_Dhillon · September 2017

I agree, the same goes for our Analysts as well and now they have stopped documenting. I have to say that the search facility in SCSM/Cireson is terrible. You cannot even search for the affected user.

Wendy_Craig · September 2017

You can search for the affected user IF you limit the work item type. Since MAs and RAs don't have affected users, you can't find them for those work items. It took us quite a while to realize that any time we search, we should immediately remove the default and then add just the sections we want. I think the search and reporting features are the weakest part of the portal, and the area we get the most complaints about.

Tom_Hendricks · September 2017

Amarjit_Dhillon said:

I agree, the same goes for our Analysts as well and now they have stopped documenting. I have to say that the search facility in SCSM/Cireson is terrible. You cannot even search for the affected user.

Unfortunately, I must agree. Lack of ad-hoc search is the #1 pain point for my users, orders of magnitude more than anything else that might be on their list. @Wendy_Craig is correct that affected users can be searched for if you stop searching by work item and instead search by a more specific class (IR or SR), but there are plenty of other fields you cannot search on, and you cannot search on related objects.

Users do not care about any of this, of course. They just wonder why they cannot construct any kind of useful search, let alone why it is not easier.

Conner_Wood · September 2017

@Tom_Hendricks you remind me of a younger version of myself, full of hope....
Sadly it's not the first time the subject of a better search has been brought to Cireson.

I personally don't believe Community Votes have an impact large enough to prioritize rebuilding the hardcoded search logic into the search engine it could be. I've tried to make my SCSM CopyCat program known to Cireson, to show it could be done, selecting a class and being able to search all the properties and relationships that the class has access to (this includes custom extensions as well as parent classes). The download includes the source code, not much guesswork needed when you have a working example. But it seems #UlteriorMotive didn't work like I hoped it would.

The tricky part about making a comment searcher in particular is that it would need to be made in particular. At least, to make the user experience tolerable. It wouldn't hurt to brainstorm it out either, so we know exactly what we're asking for and Cireson could better guesstimate how long it would take for new, 100% working functionality.

In this case, I'm going to envision it, let my coherent extrapolated volition take form!

User wants to search for troubleshooting comments that contain the phrase Wubba Lubba Dub Dub
User goes to the main search page and removes the filthy default section.
User clicks the "Add Work Item Type Section To Search By" combobox and select the special option called "Comments", and then clicks Add Section
A glorious new "Search Comments By" section appears.
There are properties listed as usual but there's also a special Filter Property!
It allows choosing the ticket to search for

Incident
Change Request
Service Request
Problem

And the best part is, this will search all the comment types for a ticket, so no need to specify the comment class (CommentLog, AnalystCommentLog, UserCommentLog)Note: It was a design choice to not allow choosing the comment class, and just asking for a ticket filter, if no filter chosen, then search them all.The Comment Properties that can be chained: EnteredByCommentEnteredDateAt this point the User is able to choose Incidents for the Ticket Filter, then set criteria of [Comment] [Contains] [Wubba Lubba Dub Dub]They hit search, and low and behold they receive back a list of rows that contain a comment with the Ticket ID it belongs to, as well as EnteredBy and EnteredDate. Searching Comments everyone, Searching Comments, yeeeeaaaaaaahhhhhh!!!!The User can then click on the comment rows and it'll bring them to the ticket, like an actual search!

Tom_Hendricks · September 2017

Conner_Wood said:

@Tom_Hendricks you remind me of a younger version of myself, full of hope....
Sadly it's not the first time the subject of a better search has been brought to Cireson.

Oh, trust me I know. At this point it is more like "full of repetition" than "full of hope." I will keep repeating this, wherever it is on topic, until it gets some kind of resolution. This is technical debt and not a shiny new feature. The effort to deliver this may be high, or not, but it needs to be addressed in either case. I want Config Item forms in the portal very badly, but I would actually be happy if they released a v9 where the only feature was a decent Ad-Hoc work item search.

...
The tricky part about making a comment searcher in particular is that it would need to be made in particular. At least, to make the user experience tolerable. ...

Repeating this as a quote for emphasis. Well said.

...
And the best part is, this will search all the comment types for a ticket, so no need to specify the comment class (CommentLog, AnalystCommentLog, UserCommentLog)
Note: It was a design choice to not allow choosing the comment class, and just asking for a ticket filter, if no filter chosen, then search them all.

The Comment Properties that can be chained:
EnteredBy
Comment
EnteredDate

This is the kind of design users could really get behind, I think. What I am about to say overlaps with your CopyCat program a bit, I think, but in the interest of brainstorming I'll say it here too. In our various different SCSM implementations, we may have all kinds of class extensions and type projections. I sense that this is where some of the difficulty tends to come from. To a lesser degree, we have OOB classes that are actually separate, but appear to users as a single "thing" on a form, like you have described above.

Can we not, as admins, help make this simpler by being responsible for providing which class/projection to use for certain types of searches? I am fine if we have to look up a GUID and hand-type it instead of getting a fancy dropdown list that gives the display name of all projections for a given base class (although that seems like it would be straightforward enough). In the example you show here, I think it is reasonable to just accept the properties that can be chained. In others, it is not (e.g. extended Change Request class). One size does not fit all, and I think common sense can be used here.

I have nothing to add to the rest of your post. If that was built, I would love to use it the way you have described.

Conner_Wood · September 2017

@Tom_Hendricks that is great feedback, and I know there's a way with combination classes (type projections) to get the seed class through SQL, so that's more than possible to select a class and return all projections related to it.

Conner_Wood said on Have offerings assign template dynamicly based on answers:
...
[ServiceManager].[dbo].[TypeProjection]
Type Projection [TypeProjectionSeed] is the base object class GUID. (Ex. "Incident (advanced)" uses the Incident Class as the base object class)

And yes, my logic is that because a comment is a target orientated search, it needed to be much more intricate than the regular ticket searches which are source of relationship orientated.

Common sense is currently a misnomer, however I would very much like that to change.

I am partially tempted to build my own, it was only after I showed screenshots of the custom Reviewer Portal that Cireson decided to prioritize restricting reviewers reviewing an activity. Seriously I double checked the datestamps under Inspect elements on the dates on the posts.

I don't want to get anyone's hope up, I just wanted to state I know it is possible to do since I have the knowledge to make a comment searcher web page that could then be referenced by the Cireson Portal. Optionally I could also make a node on the side menu that links to the webpage, but the other option seems cleaner.

Tom_Hendricks · September 2017

Exactly, @Connor_Wood. All of these extension classes inherit from the same base classes that are currently represented in search, and it therefore seems logical to be able to query for anything that extends the class, and include its properties.

In regard to your last point, it seems better to get these ideas out in text and encourage some movement, than to not say anything and stew about the lack of said feature existing (not saying you are, btw, speaking generally here). I am glad you added this to the thread. I am not sure what is going on with the votes (down votes, perhaps?) on these search features, but they are:

Crucial to any ticket platform
Feasible
Expected to already exist by nearly 100% of users, who are then frustrated and annoyed to learn that they are wrong

If the mantra is still "first make it possible, then make it easy" then let's just focus on that first part to start with. Make it possible. It is not even possible for users to conduct a meaningful search (again, this goes for comments and also work items in general). I would prefer that the difficulty get shifted on to us as admins and away from the users, but I could even live with something difficult for users to start with if that is the only way to get the feature.

Conner_Wood · September 2017

Yeah, and it's not that hard to get a list of all the properties of a class in the ServiceManager Database, especially using SQL because Microsoft put extensions under the same view. So you don't have to try to recurse through the classes as you just need to get the viewname that the class you want is reported from and then you say give me all class properties of that view.

https://community.cireson.com/discussion/3075/sql-servicemanager-class-properties-and-relationships-cireson-senpai-notice-me

Granted, programming is more "Need Mental Knowledge" than "Need Physical Effort" as I know the SCSM databases better than most I'd say, given how much hideous troubleshooting I've had to do....

Now relationship classes are a bit harder because they are all in the massive [dbo].[RelationshipType] and you do need to do a bit of Common Table Expression (CTE) Recursion to get the list of classes that your class can access (Incident can access the WorkItem AssignedTo relationship). Basically the criteria is the class and any hierarchical parents of the class.

USE [ServiceManager];

WITH CTE_Class AS
(
  SELECT MT.[ManagedTypeId], MT.[BaseManagedTypeId]
  FROM [dbo].[ManagedType] MT (nolock)
  WHERE MT.[TypeName] = 'System.WorkItem.Incident' -- This is the class you want to see all the relationships it can be a part of.
  UNION ALL
  SELECT c.[ManagedTypeId], c.[BaseManagedTypeId]
  FROM [dbo].[ManagedType] c (nolock)
  JOIN CTE_Class p
  ON p.[BaseManagedTypeId] = c.[ManagedTypeId]  -- this is the recursion to get parent of child.
)
,Class_Relationships AS
(
  SELECT [RelationshipTypeId]
  FROM [dbo].[RelationshipType] RT (nolock)

  JOIN CTE_Class SourceFilter
  ON SourceFilter.[ManagedTypeId] = RT.[SourceManagedTypeId]

  UNION --Just UNION removes Duplicates

  SELECT [RelationshipTypeId]
  FROM [dbo].[RelationshipType] RT (nolock)

  JOIN CTE_Class TargetFilter
  ON TargetFilter.[ManagedTypeId] = RT.[TargetManagedTypeId]
)
SELECT RT.[RelationshipTypeId]
      ,RT.[RelationshipTypeName]
FROM Class_Relationships

JOIN [dbo].[RelationshipType] RT (nolock)
ON RT.[RelationshipTypeId] = Class_Relationships.[RelationshipTypeId]

The above query returns only relationship classes that an incident is able to be related to (though you would have to determine if you should relate to source or target).

As for the down votes, it's more likely they like the idea later on when revisiting the thread, and end up clicking the up arrow again which removes their vote.

Hahaha, and I agree @Tom_Hendricks , the community should be as active as possible with finding the flaws and lack of features, though I don't blame them for being already overwhelmed and just, fine whatever.

#UlteriorMotive #UlteriorMotive #UlteriorMotive #UlteriorMotive #UlteriorMotive #UlteriorMotive #UlteriorMotive

Jason_Meyer · January 2020

Cireson, when can we expect this functionality in the product?

Gerhard_Goossens · January 2020

@Jason_Meyer

I think this will form part of the "Global Search" that was released in 9.7.0. Theare are still some bugs, but from what I have tested it is a game changer