That's a bit trickier, but it can be done.
We first need to create a metric definition. Set the type to script calculation and the table to incident. Leave the script field blank, we will be using a business rule to create the instances.
Now we need to create a metric instance each time a user does something to the incident. We can accomplish this with a business rule.
Create a new business rule that runs on inserts and updates to the incident table. The rule will create an incident metric each time the incident is updated by a user. This counts all changes to the incident as a "touch", including things like adding worknotes, changing the state or assignment group.
Check the "advanced" checkbox and go the the advanced tab. Then paste in the following script. Make sure to replace the sys_id to the one of the metric definition you just created:
(function executeRule(current, previous /*null when async*/) {
var definition = '1ce280cf0753ac10da6cff4c7c1ed0b2'; //sysid of the metric definition
var user = gs.getUserID();
var currentTime = new GlideDateTime();
var mi = new MetricInstance(definition, current, user, currentTime);
var nr = mi.getNewRecord();
nr.id = current.getUniqueValue();
nr.definition = definition;
nr.field = 'sys_user';
nr.field_value = user;
nr.start = currentTime;
nr.calculation_complete = true;
nr.insert();
})(current, previous);This business rule creates a metric capturing the users sys_id each time the record is updated:
We capture the user since that's really all we know. A user can be a member of multiple groups, so we don't know which of the user's groups "touched" the incident. Say I am a member of the database group and the windows server group and I update an incident. Was it the database group or the server group that touched the incident?
What we can do is to join our metrics in a database view to the sys_user_grmember table. That way, we get a row for each possible group that could be regarded as having touched the incident, i.e. each group the updating user belongs to. If your users only belong to a single group, there will only be a single row for each metric instance:
The where-clause that is cut off in the picture is:
met.field_value = mem.user AND met.definition ='1ce280cf0753ac10da6cff4c7c1ed0b2'
Again, replace the sys_id with that of you metric definition.
This will create a table containing the groups that can be seen as having touched the incident, based on the updating user's group membership. We can then create an indicator source on this table and filter out rows for a specific group, and then count the distinct ID values in an indicator.
In this example, I added a work note to INC0010055 using the account of Beth Anglin. She is a member of 8 groups, so we get 8 rows in our database view.
One thing to remember is that since this DB view is based on the group membership table, if we remove a user from a group that will remove the rows for that group for all metrics. Since you are using PA that wont be an issue, the scores for the groups will be saved in the PA scores table and wont be affected by changes to previous days data in the source table. But if you were using reporting, removing a user from a group would affect all historic "touches" for that group.
That's a bit trickier, but it can be done.
We first need to create a metric definition. Set the type to script calculation and the table to incident. Leave the script field blank, we will be using a business rule to create the instances.
Now we need to create a metric instance each time a user does something to the incident. We can accomplish this with a business rule.
Create a new business rule that runs on inserts and updates to the incident table. The rule will create an incident metric each time the incident is updated by a user. This counts all changes to the incident as a "touch", including things like adding worknotes, changing the state or assignment group.
Check the "advanced" checkbox and go the the advanced tab. Then paste in the following script. Make sure to replace the sys_id to the one of the metric definition you just created:
(function executeRule(current, previous /*null when async*/) {
var definition = '1ce280cf0753ac10da6cff4c7c1ed0b2'; //sysid of the metric definition
var user = gs.getUserID();
var currentTime = new GlideDateTime();
var mi = new MetricInstance(definition, current, user, currentTime);
var nr = mi.getNewRecord();
nr.id = current.getUniqueValue();
nr.definition = definition;
nr.field = 'sys_user';
nr.field_value = user;
nr.start = currentTime;
nr.calculation_complete = true;
nr.insert();
})(current, previous);This business rule creates a metric capturing the users sys_id each time the record is updated:
We capture the user since that's really all we know. A user can be a member of multiple groups, so we don't know which of the user's groups "touched" the incident. Say I am a member of the database group and the windows server group and I update an incident. Was it the database group or the server group that touched the incident?
What we can do is to join our metrics in a database view to the sys_user_grmember table. That way, we get a row for each possible group that could be regarded as having touched the incident, i.e. each group the updating user belongs to. If your users only belong to a single group, there will only be a single row for each metric instance:
The where-clause that is cut off in the picture is:
met.field_value = mem.user AND met.definition ='1ce280cf0753ac10da6cff4c7c1ed0b2'
Again, replace the sys_id with that of you metric definition.
This will create a table containing the groups that can be seen as having touched the incident, based on the updating user's group membership. We can then create an indicator source on this table and filter out rows for a specific group, and then count the distinct ID values in an indicator.
In this example, I added a work note to INC0010055 using the account of Beth Anglin. She is a member of 8 groups, so we get 8 rows in our database view.
One thing to remember is that since this DB view is based on the group membership table, if we remove a user from a group that will remove the rows for that group for all metrics. Since you are using PA that wont be an issue, the scores for the groups will be saved in the PA scores table and wont be affected by changes to previous days data in the source table. But if you were using reporting, removing a user from a group would affect all historic "touches" for that group.
