hide cmdb classes in change/incident

[tenagra]

Hi everyone.

Running into a bit of a challenge here and could use some guidance/direction.

Our CMDBis somewhat large (1.6M+ CI's), but only about 100-150k are really desired for incident/change.  What I've been tasked with doing is to do the following:

1) Limit the CI's that are available for selection on Change and Incident to a specific set of classes. 
    a) For change, don't just add filters to the related list, but actual hide classes when using the 'Add' button and don't let users select them.
    b) For incident, limit the classes when the hour glass search is selected and/or if someone starts typing in values.

2) For a select set of Business Rules on the cmdb_ci table, only run if the class is one of the classes available on incident and/or change.

My initial thought was to create a script includes that would house the list of classes that are available and then use that to filter lists and dictate when the business rules run.  That was easy for  #2 as I could just return a true/false if the class is in the list. 

For #1, I'm looking at something that appears to be more complex than I thought it would be.  It's looks like I would need to go into the UI Action > Add button for tasks_ci and actually change the code for this to limit the results when list pops up.  Besides not being sure where else that UI Action is being used, I hesitate to make code changes to this for future upgrade, and if there is something easier.

So, before going much further, I wanted to reach out to the community to see if I'm heading down the right path or if there are better options that I'm just haven't considered and/or know about.

Thank you very much.

Nathan

[joebusuttil]

I have solved this with a dictionary override on task.cmdb_ci which adds a reference qualifier that excludes specific sys_class_name(s).

[tenagra]

Thanks for the reply.  I've been able to get it to work for Incident, but it isn't working for Change Request.  Here is my initial dictionary entry:

Both my overrides are using the following logic as a test:  

install_status=1^sys_class_name=cmdb_ci_win_server^ORsys_class_name=cmdb_ci_linux_server 

As stated, it works for incident but not change.  I'm guessing this has to do with the change CI's being a related list (as below), rather than a reference lookup field like we are using in incident.  

If my guess is wrong, any thoughts on why the code isn't working?  Assuming the related list is the issue any thoughts on how to customize that for all users so when we go click the 'add' button, we can still filter the list to specific classes?

Thanks,

Nathan

[joebusuttil]

You are correct, the solution I gave you is for the cmdb_ci field from Task which is a one to one field to a single configuration item.

Affected CI is a query to the table task_ci, you would need to put in more reference qualifiers there.

[tenagra]

What I'm finding is that the task_ci holds the record of the CI that was selected, but doesn't get looked at when getting the list of CI's to select from.  In some way, it appears to look directly at the CMDB_CI table, but that doesn't seem right....

The only other thing I'm finding is the 'AssociateCIToTask' script include that get's called when the list is loading.  However, while this does seem to manage some filters, it appears to be more after the fact that initial filters.  It is also adding the selected CI's to the task_ci table.  I could probably do it, but it seems a really odd place to do the filtering.

Nathan