Hiding classes in the CMDB

[saxon]

Hi folks,

I'd like to hide a lot of classes from the CMDB as it is listed in my Incident, Change, and Problem pick lists.   I tried creating a Reference Qualifier, but the query that specified all of the classes I wanted to hide was way, (way!) too long for the allowable field length.  

It seems like I should be able to create a query or an index of the CMDB which is called instead of "all items" for these pick list.   But I'm unaware of how to do this.

I'd like any newly discovered CI in any of these classes to be functionally invisible, but any CI from any other class to be visible.   Of course, there are some in this list that will be important for other functions (cmdb_ci_windows_service is a prime example).  

I can't imagine I'm the only one who's trying to deal with this.   Also, if anyone has session or speaker recommendations for Knowledge15 that might apply to this problem, please feel free to suggest those here.

Below is a preliminary list of the classes I want to hide.  

cmdb_ci_network_adapter

cmdb_ci_ip_address

cmdb_ci_windows_service

cmdb_ci_db_mssql_catalog

cmdb_ci_disk

cmdb_ci_memory_module

cmdb_ci_print_queue

cmdb_ci_spkg

cmdb_ci_win_cluster_resource

dscy_route_next_hop

dscy_switchport

dscy_route_interface

dscy_swtch_fwd_rule

cmdb_ci_dns_name

cmdb_ci_pdu_outlet

cmdb_ci_ups_input

cmdb_ci_ups_alarm

cmdb_ci_ups_output

dscy_router_interface

cmdb_ci_hyper_v_rpool_comp

cmdb_ci_desktop_software

cmdb_ci_cluster_vip

[doug_schulze]

Stephen,

Instead of outlining what you don't want, why not what you do want?   I would suggest going with including at the minimum the base classes off cmdb_ci_hardware.. Everything discovery finds is extended from that table..

Perhaps even having a first choice that drives the second.

1. Choose network gear? affected CI shows everything off cmdb_ci_netgear

2. Choose servers? affected CI shows everything off cmdb_ci_server

3. Choose PC? affected CI shows everything off cmdb_ci_computer of the class of computer

ect.. ect..

I'll be doing a ci lifecycle as part of the discovery 301 lab where I'll talk about this in "theory"

[saxon]

Thank you, Doug.

Identifying what I don't want is the only way to be sure that I'm not missing something I DO want to see.   If I only identify what I am certain that I want to see, there might be things that I have left out, and they would not be obvious to me.   The old Rumsfeld quote comes to mind, about "what we know, what we know we don't know, and what we don't know we don't know. . ."  

If I miss something in my "include" list, it would be forever lost to my view. But if I identify what is not relevant to the search in question, that can always be audited, documented, and/or explained by simply looking at what is being filtered out.   It seems much safer that way.

In addition, I think the list of includes will be approximately as long as the list of excludes.   I think it'll be longer than the allowable search string for a Reference Qualifier, anyway.

Discovery 301 is already on my schedule for Thursday at 10:30.   I'll definitely see you there!

[Kalaiarasan Pus]

you can always write a script include and call that in the reference qualifier. It has no limits on length

http://wiki.servicenow.com/index.php?title=Reference_Qualifiers#Advanced_Reference_Qualifier_Example

[saxon]

Kalaiarasan,

4.3.2 JavaScript Calls

Regarding include scripts: "The function must return a query string that can filter the options available on a reference field."  

My problem is that the query itself, whether returned by a script or entered manually, is too long for the RefQual field.   It seems that the script must return the query and can't return the results of the query.   Perhaps I am missing a finer point, but I'm not seeing how this would help me accomplish my goal.  

I'm not good at JavaScript (which may be a more fundamental problem I'll need to resolve), so I'm going to look more closely to parse the script examples and see if I can untangle an effective answer in there.

Thank you for offering your assistance (and thanks again to Doug, too).