I need help both realizing the best course of action, and how to proceed with said course of action.
My goal:
Have emails sent to members of a specific team based on the specific software a patch is applied to.
I notice that the software and patch CIs do not have contacts or other joinable fields for the OQL query.
My initial gut response is that I need to make an update to the data model creating some form of linking table between software and Contacts. That way I can JOIN the tables and select accordingly. Right now the most I can seem to do is just 1 action per software, but this is inefficient. I see no reason 1 action rule can not extend to all of them if it can find the proper way to reference the data.
Any input or insight would be fantastic, so far I only have the following which again, requires a new action per software:
SELECT Person AS P
JOIN lnkPersonToTeam AS L ON L.person_id = P.id
JOIN Team AS T ON L.team_id = T.id
WHERE T.id = 268
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You would indeed require changes to the datamodel so there's some sort of link.
Likely you'll create a link between contacts and software; since you create multiple patches for the software and probably don't want to have to start from scratch each time.
As for the query: you can use variables such as WHERE id = :id . If you run this through the "Run queries" action, you will manually be able to enter the ID (which you'd have to look up each time though).
One way to accomplish this kind of thing would be to add an AttributeDashboard field to the SoftwarePatch class. Here, you can write an OQL query similar to the one above; and you can use a placeholder such as WHERE id = :this->id ("this" would be the SoftwarePatch object; and the id is the ID of the object. But you can also use the other attribute codes, so you can also use :this->software_id)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Software are linked to SoftwareInstance itself joined to Contacts, so you could notify Person or Team linked to any SoftwareInstance of a particular Software. This model allow to have different contacts in charge of different instances of a given Software...
2) Another mean could be to create ApplicationSolution containing the Software(s) and a link to a Team in charge of those Software(s), so at least one ApplicationSolution per Team.
3) Modify the DataModel with an extension (or 5 min with the ITSM designer) to add to the class Software an ExternalKey on Team or a n:n relationship.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I need help both realizing the best course of action, and how to proceed with said course of action.
My goal:
Have emails sent to members of a specific team based on the specific software a patch is applied to.
I notice that the software and patch CIs do not have contacts or other joinable fields for the OQL query.
My initial gut response is that I need to make an update to the data model creating some form of linking table between software and Contacts. That way I can JOIN the tables and select accordingly. Right now the most I can seem to do is just 1 action per software, but this is inefficient. I see no reason 1 action rule can not extend to all of them if it can find the proper way to reference the data.
Any input or insight would be fantastic, so far I only have the following which again, requires a new action per software:
SELECT Person AS P
JOIN lnkPersonToTeam AS L ON L.person_id = P.id
JOIN Team AS T ON L.team_id = T.id
WHERE T.id = 268
You would indeed require changes to the datamodel so there's some sort of link.
Likely you'll create a link between contacts and software; since you create multiple patches for the software and probably don't want to have to start from scratch each time.
As for the query: you can use variables such as
WHERE id = :id. If you run this through the "Run queries" action, you will manually be able to enter the ID (which you'd have to look up each time though).One way to accomplish this kind of thing would be to add an AttributeDashboard field to the SoftwarePatch class. Here, you can write an OQL query similar to the one above; and you can use a placeholder such as
WHERE id = :this->id("this" would be the SoftwarePatch object; and the id is the ID of the object. But you can also use the other attribute codes, so you can also use:this->software_id)1) Software are linked to SoftwareInstance itself joined to Contacts, so you could notify Person or Team linked to any SoftwareInstance of a particular Software. This model allow to have different contacts in charge of different instances of a given Software...
2) Another mean could be to create ApplicationSolution containing the Software(s) and a link to a Team in charge of those Software(s), so at least one ApplicationSolution per Team.
3) Modify the DataModel with an extension (or 5 min with the ITSM designer) to add to the class Software an ExternalKey on Team or a n:n relationship.