Default assignment group based on Configuration Item in Alert

[Henrik Jutterst]

I have a problem when an Alert is being reopened and a new incident is being created.

The issue I have is that the Assignment Group of the Incident is copied from the previous incident to the Alert, and that's not the way our Operators would like it to go. We want to use the support_group field from the cmdb_ci instead.

Anyone know how/where this can be configured?

Kind regards

/Henrik

[Nayan Dhamane]

Hello @Henrik Jutterst ,

You are receiving an alert. Hence it should be written on client side. Kindly check in the client script and add the filter script contains { alert('put what your alert starts with }and then edit it.

Please mark correct if it helped.
BR,
Nayan.

[Henrik Jutterst]

Hi and thanks for feedback.

Unfortunately I see no records of code where either incident or assignment group is refered to in Client Script on Alert table. Do you have something that I don't see?

And also, this really shouldn't be a client script according to me. It should be server-side.

[Henrik Jutterst]

It looks like the code is hidden in this Script Include: "EvtMgmtAlertMgmtAlertReopenHandler"

    createNew: function(current, alertNumber, newTask, taskNumber, type, task) {
        // Create a new one and copy fields from the old one here
        newTask.initialize();

        // Copy all fields into newIncident
        var fields = task.getElements();
        var fieldsToIgnore = gs.getProperty('evt_mgmt.open_new_incident_ignore_fields', 'number,state,opened_at');
        fieldsToIgnore = fieldsToIgnore.replace(/ /g, ''); //remove all spaces
        var fieldsToIgnoreArr = JSON.stringify(fieldsToIgnore.split(","));

        for (var i = 0; i < fields.length; ++i) {
            var ele = fields[i];
			if ((typeof ele.getName() == "undefined") ||ele.getName() == "active"|| (((ele.getName() +"").startsWith("sys_")) && (!((ele.getName() +"").startsWith("sys_domain")))) || fieldsToIgnoreArr.includes(ele.getName())){
				continue;
            }
            newTask.setValue(ele.getName(), ele);
        }
        // Add comments on new incident
        this.updateWorkNoteField(newTask, gs.getMessage("The related alert {0} is now unlinked from the previous {1} {2}", [alertNumber, type, taskNumber]));
        newTaskId = newTask.insert();
        current.incident = newTaskId;
    },

So modifying this piece to look on current.cmdb_ci.support_group should do it I guess?

[Ryan Zulli]

Hi Henrik,

 The usecase I am assuming you are referring to is when an assignment group is set on the Incident however it may be been routed incorrectly so the NOC operator changes the group.  Then the Alert/Incident close - the new one comes in and its populated with the incorrect (changed) value, instead of the one from the CI. If I'm wrong please let me know.

This works OOB, by making a slight change to the Create Incident subflow (of course make a copy then modify) - at the bottom of Create Task - add a new field value for Assignment Group and set it to AlertGR --> Configuration Item --> Support Group

make sure the Alert Management Rule (Alert Filter) is set to Alert Changes to Filter

I successfully tested this with the following criteria ::

• Set support group on a CI to the "Change Management" group
• Create event with the Node set to said CI
• Notice Alert created
• Notice Incident created with Assignment Group set to "Change Management"
• Change Assignment Group to the "Database" Group - Update Incident Record
• Send in a clear event to close the alert and resolves the Incident
• Send in another event matching the first (same message_key)
• Notice Alert opened with state of "Reopen"
• Notice New Incident is opened however with an Assignment Group of "Change Management"

This is because the subflow ran again, and looked up the configuration item's support group.

Hope this helps.

Thanks,

-Ryan