[Feature Request] Add `visibleTo` field to OpsGenie integration

[hsolberg]

What did you do? I checked the documentation and code and didn't find any option to map the field visibleTo for the OpsGenie integration. The field visibleTo would be very useful to give a team access to see the alert, but not trigger the normal responder workflow.

What do you want to solve? Usecase: Several teams of developers have ownership of several applications each. All these applications have global alerts that the developers want to receive, so they are the responders. The infrastructure team want insight, but doesn't need to respond to the developers alerts and this is where visibleTo comes in.

Suggestion I suggest a new field called visible_to (following the naming scheme that's already in place) that's mapped to OpsGenie's Alert API with the field name visibleTo. Here's the relevant OpsGenie documentation. I've added the relevant row from the table in the documentation below for convenience.

Field	Mandatory	Description	Limit
visibleTo	false	Teams and users that the alert will become visible to without sending any notification. type field is mandatory for each item, where possible values are team and user. In addition to the type field, either id or name should be given for teams and either id or username should be given for users. Please note: that alert will be visible to the teams that are specified within responders field by default, so there is no need to re-specify them within visibleTo field. You can refer below for example values.	50 teams or users in total

[grobinson-grafana]

Seems reasonable to me! Please create a PR for this and I'll review it.

[chlunde]

@grobinson-grafana hi, a quick design question: The data types for this field would currently be identical to OpsGenieConfigResponder (config format) and opsGenieCreateMessageResponder (opsgenie api format).

Would you like me to reuse those struct types and reuse the code (maybe by extracting a function), or rather copy them as OpsGenieConfigVisibleTo and opsGenieCreateMessageVisibleTo and copy the code that handles them.

By copying, we avoid issues if there are fields or behaviour added to responders, that should not be added to visible_to, but it doesn't look as DRY. What do you think prefer?

[grobinson-grafana]

@grobinson-grafana hi, a quick design question: The data types for this field would currently be identical to OpsGenieConfigResponder (config format) and opsGenieCreateMessageResponder (opsgenie api format).

Would you like me to reuse those struct types and reuse the code (maybe by extracting a function), or rather copy them as OpsGenieConfigVisibleTo and opsGenieCreateMessageVisibleTo and copy the code that handles them.

By copying, we avoid issues if there are fields or behaviour added to responders, that should not be added to visible_to, but it doesn't look as DRY. What do you think prefer?

I think let's do what it does for responders where it has separate struct definitions for the configuration file and for the request.

[siavashs]

Linked PR is closed, is this still valid or wanted?

[chlunde]

https://github.com/prometheus/alertmanager/issues/4244

https://developer.atlassian.com/cloud/jira/service-desk-ops/rest/v1/api-group-integration-events/#api-jsm-ops-integration-v2-alerts-post

I think the issue is still valid for JSM. I closed it because the last commit never got any feedback.