pagerduty/backstage-plugin

PagerDuty plugin for Backstage

backstage-plugin's Issues

Add support for Scoped OAuth

Is your feature request related to a problem? Please describe.
The PagerDuty plugin for Backstage requires an API Token to be provided to query the REST API. This API Token is generated for an account and can either have read or read/write permissions for all operations provided by the REST API.

This is not necessarily a security risk by itself in the context of the plugin but we should be able to use a restrictive approach and only have the permissions requested by the plugin.

Describe the solution you'd like
PagerDuty recently made available Scoped OAuth for both US and EU based accounts which allows an admin to specify which operations and permissions are available to a token.

I would like this feature to be implemented as an alternative way of using the REST API inside the plugin.

Describe alternatives you've considered
Currently the only approach supported by the plugin is to use a general or user API Token.

Opt-out from showing on-call information

Is your feature request related to a problem? Please describe.
I would like to be able to simplify the information showing up on the PagerDuty Card. The on-call information might lead to people reaching out directly to on-call engineers which might lead to other problems by not allowing them to do their work.

Describe the solution you'd like
I would like to be able to customize the PagerDuty Card not to show the on-call section. This might be a boolean parameter passed into the PagerDuty Card.

Additional context
This feature was requested by @asandoval and @jerroydmoore.

Add more details when creating an incident from Backstage

Is your feature request related to a problem? Please describe.
When creating an incident from the PagerDuty plugin for Backstage the only property that we are able to define is the description. This is typically not enough for on-call engineers to solve the problem.

Describe the solution you'd like
I would like to capture more information to help the on-call engineer with more context on the problem being raised, such as the severity of the event.

Describe alternatives you've considered
There isn't much else to be considered here since the UI only provides one text box. The only option would be to customise it for each configuration.

Updating to 0.10 or newer can't find the service

Describe the bug

After updating from 0.9.3 to newer versions (0.10 , 0.11) the widget can not find the service anymore.

In 0.9.3 I see these calls in the backend

GET /api/pagerduty/services/
GET /api/pagerduty/oncall-users?escalation_policy_ids[]=
GET /api/pagerduty/services//incidents

They return 304 and work

With 0.10 I see

GET /api/pagerduty/services/ 304
GET /api/pagerduty/services//standards 404

In the UI the widget says the service was not found. But I do not think so, I think it is picking the 404 of the standards. The standards were not found but well, I do not care about standards anyways.

Hide Standards box

Is your feature request related to a problem? Please describe.
The current standards box and a list of suggestions that are not relevant for us and are currently showing 1/9. Our customers requested us to remove it because it's making the wrong impact.

Describe the solution you'd like
Provide a prop to hide this box (same as disableChangeEvents).
Another option would be to allow us to modify the standards list and also to hide it ( I assume that this will take more time to implement)

Describe alternatives you've considered
Unfortunately, the only alternative we currently have is not to update to the latest version

Small sized PagerDutyCard component

Is your feature request related to a problem? Please describe.
Our Entity page has multiple tabs and we reserve the first one to smaller widgets to provide relevant and quick information to users. We then have specific tab for Operations where we would like to keep the existing card.

Describe the solution you'd like
I would like to have a smaller card that shows the status of the service, the oncall engineer, service standards and eventually some statistics. Details on incidents are not necessary, we have the other PagerDuty card for that.

Describe alternatives you've considered
We are considering building an internal-only custom component to expose only the information we need.

Implement GitHub actions to build and push package to NPM

The plugin was extracted from backstage/backstage and so it needs to be published to NPM in order to be referenced by developers using the PagerDuty plugin on Backstage

RFC: PagerDuty Service Import/Mapping capabilities

🔖 Need

The PagerDuty plugin provides a software project scaffolder custom action that enables the integration between Backstage and PagerDuty for new services but it is not possible to do the same for existing services.

I would like to have an easy way where I could see a list of Backstage entities and the PagerDuty services and easily map them together. The goal would be to have an easy way to map services without requiring the integration to be setup on each individual service.

This RFC is my proposal to solve issue (#80) but looking for different perspectives from the community.

🎉 Proposal

My proposal is to have a PagerDuty page that can be used used to import all PagerDuty Services to a list inside Backstage. From there you can use the UI to map PagerDuty services to existing Backstage entities.

The mappings will be stored on a database and will be checked for updates the next time a Backstage entity is loaded or when another import operation takes place. If the data is not in sync it will show on-screen. This might happen because the entity config was updated in source code. If this happens, the user will need to use the UI to select the new mapping or the old one.

All these mappings will only be persisted when the user clicks the "Save" button on the screen.

Example UI  👇

〽️ Alternatives

We have considered two alternatives instead of the UI-based approach mentioned above.
1. Providing a CLI tool to allow a fast mapping between PagerDuty and Backstage services
This would provide a similar approach to the one proposed above but instead of providing a UI-based interface to the user it would be done through CLI. For each mapping specified a PR would be created in the source code of that same service.

2. Create PRs to Backstage service code instead of storing the mapping on a database
This approach is similar to the one mentioned in the proposal section but instead of storing the mappings on a database and implement conflict management capabilities we would create PRs for every single mapping update.

The downside for these two approaches is that those PRs would require permissions to GitHub/GitLab/Azure DevOps and would still need to be approved and merged in every single service.

❌ Risks

We are introducing a database dependency that we didn't have before. This means that for service mapping capabilities the pagerduty.com/service-id is no longer the only option to configure the mapping between services in PagerDuty and Backstage.

Also, potentially in future changes, the database schema might change and therefore introduce the need for database migrations which adds up to the complexity of the plugin and its dependency management and versioning.

The automated release is failing 🚨

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

Reuse previous inputs when creating new incident with empty description

Describe the bug
When i create incident with pagerduty backstage plugin, the first time i create incident with description "Test Incident 1" and click trigger button. Then i open create incident again, the trigger button should be disable with empty description. But I can still click Trigger Incident button, and will create a incident same with previous one.

To Reproduce
Steps to reproduce the behavior:

1. Trigger PagerDuty incident via Backstage with description not empty.
2. Trigger PagerDuty incident again without description (empty description), a new incident will be created but the description will be the same as the previous one.

Expected behavior
Without description, the trigger button should be disabled. (maybe clear description text field each time the create incident modal is closed)

Screenshots

Optionally remove 'create incident' button from card

Is your feature request related to a problem? Please describe.
Currently the PagerDuty Card shows the 'create incident' button even when configured with service-id only.

According to the documentation if we only use the service-id annotation on the service entity it will not be possible to create incidents and therefore the button becomes greyed-out.

Describe the solution you'd like
To simplify the PagerDuty Card readability I would like the button to fully disappear when the card is configured as read-only or when service-id is the only annotation provided on the service entity configuration.

Additional context
This feature was requested by @asandoval and @jerroydmoore.

The toggle visibility elements of the "Show/Hide columns" button on the PagerDutyPage do not work

Describe the bug
The toggle visibility elements of the "Show/Hide columns" button on the PagerDutyPage do not seem to work.

To Reproduce
Navigate to the PagerDutyPage component, wait for the Page to load, click on the Show/Hide columns button on the top right hand side of the table, try to toggle any element of the drop down menu or select the Hide All or Show all. Nothing works. It's impossible to toggle any element.

Expected behavior
The chosen visibility toggle should change to off/on when selected. The Hide All and Show all buttons should toggle off/on all visibility toggles. The change should result in hiding/showing the respective columns.

Additional context
backstage version: 1.29.1
"@pagerduty/backstage-plugin": "0.14.1",
"@pagerduty/backstage-plugin-common": "0.2.0",
"@pagerduty/backstage-plugin-backend": "0.8.2"

Users without AIOps or Event Intelligence license getting 403 on "Change Events" tab

Describe the bug
Getting 403 error on the Change Events tab

To Reproduce
Steps to reproduce the behavior:

1. Use basic user API token
2. Navigate to the PD section on the overview page.
3. Click on 'Change Events'

Expected behavior
Hide this tab or have a proper message rather than an error.

New release `0.8.1` breaks use of different PagerDuty API host

Describe the bug
The new release 0.8.1 that deprecates the proxy configuration in favor of using a backend plugin to make calls to the PagerDuty REST API does not offer the possibility to change the server base URL. Calls to the european server https://api.eu.pagerduty.com are not possible anymore.

Expected behavior
The possibility in the configuration to change the API server.

On-call user doesn't show during 'blank' hours on level 1 of the escalation policy

Describe the bug
I have an escalation policy with no users assigned to it during off hours, on escalation level 1 - not sure if this is the right way to do it. But I do have users on level 2 but they are not showing up. Instead I get his message on the plugin.

To Reproduce
Steps to reproduce the behavior:

1. Go to an escalation policy in PagerDuty
2. Define a schedule on level 1 and make sure to leave a blank spot.
3. During that blank timeslot - open Backstage - navigate to a service that uses that escalation policy
4. See the same information I posted below.

Expected behavior
I was expecting to see the on-call user, independent of the escalation level. If no one is on call on level 1, then level 2 is the one to be on-call.

Two-way mapping between Backstage service dependencies and PagerDuty

Is your feature request related to a problem? Please describe.
Today we use Backstage as a main source of truth for service dependencies as we sync with multiple providers and therefore leverage Backstage as the default place to go to search for this information.

Describe the solution you'd like
We would like that our dependencies would be mapped to PagerDuty and kept in sync. We don't have service dependency configurations in PagerDuty and therefore we don't take a lot of advantage of PagerDuty's service mapping and status pages. We would like to but it just takes to much effort to do these configurations in multiple places.

Describe alternatives you've considered
We have considered to implement some scripts to sync Backstage and PagerDuty using the PagerDuty REST APIs. But if this feature would be brought into the plugin we would save a lot of time and I believe this is useful for other customers as well.

Additional context
This feature was requested by @brianphillips and the Shutterstock team.

OAuth Authentication for PagerDuty Fails with "Missing or Invalid PagerDuty Token" Error

Describe the bug
The OAuth authentication method for PagerDuty is not working. When attempting to authenticate, the following error messages are logged:

[1] 2024-06-12T13:45:55.611Z pagerduty warn No PagerDuty API token found in config file. Trying OAuth token instead...
[1] 2024-06-12T13:45:56.512Z rootHttpRouter info ::1 - - [12/Jun/2024:13:45:56 +0000] "POST /api/permission/authorize HTTP/1.1" 200 74 "-" "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)" type=incomingRequest
[1] 2024-06-12T13:45:56.513Z rootHttpRouter info ::1 - - [12/Jun/2024:13:45:56 +0000] "POST /api/catalog/entities/by-refs/ HTTP/1.1" 200 822 "http://localhost:3000/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" type=incomingRequest
[1] 2024-06-12T13:45:56.582Z pagerduty error Unable to retrieve valid PagerDuty AUTH configuration from config file: Error: Failed to retrieve valid token. Bad Request - Invalid arguments provided.

In the console, the following message appears:

Missing or invalid PagerDuty Token

To Reproduce
Steps to reproduce the behavior:

1. Configure the Backstage app with the following app-config.yaml settings:

pagerDuty:
  oauth:
    clientId: ${PD_CLIENT_ID}
    clientSecret: ${PD_CLIENT_SECRET}
    subDomain: ${PD_ACCOUNT_SUBDOMAIN}
    region: ${PD_ACCOUNT_REGION}

2. Start the Backstage application.
3. Attempt to authenticate with PagerDuty using OAuth.
4. Observe the error messages in the logs and console.

Expected behavior
The OAuth authentication should successfully retrieve a valid token and authenticate with PagerDuty without errors.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Mac OS X 14.0
• Browser: Chrome
• Version: 125.0.6422.142

Additional context
The issue appears to be related to the inability to retrieve a valid token from PagerDuty using the provided OAuth credentials.

@backstage/core-components 0.14

Hi,

The code in the main branch and next branch are using @backstage/core-components 0.13. Any plan to use @backstage/core-components 0.14? The cli version check is picking up on this and we can't remove the 0.13 because pager plugin is still using it.

Thanks,
MS

Adding Telemetry

Is your feature request related to a problem? Please describe

In order to focus our efforts on features that actually bring value to our users we should have some telemetry to understand how the plugin is being used. However since telemetry is a sensitive topic as it raises concerns regarding privacy, we need to be careful here. If we spot any resistence we should drop it so not to lose adoption.

Telemetry should be opt-in and disabled by default and must be fully transparent regarding data collected.

Describe the solution you'd like

• Instrument the code to collect telemetry data, ideally avoiding third-party software
• All collected data is clearly described in the README.md (or other)
• Raw data is anonymized and ideally made public.
• Proper procedures and documentation in place to handle data

Describe alternatives you've considered

• we get feedback from users through other means.

Add link to slack channel in the incidents list (or a link to set/create a slack channel if one not set)

Is your feature request related to a problem? Please describe.
When reviewing live incidents in Backstage, have a number of clicks between me and the active Slack channel can be friction that I could do without.

Describe the solution you'd like
It would be helpful to be able to view, and navigate to, the Slack channel associated with an incident from within Backstage.
If a Slack channel has not been set, the ability to set or create one from within the plugin would be helpful.

The automated release is failing 🚨

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

The automated release is failing 🚨

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

No NPM access token specified.

A NPM access token must be provided in your configuration. The token must allow to publish to the registry "https://registry.yarnpkg.com".

Please refer to the npm registry authentication section of the README to learn how to configure the NPM registry access token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

Adopt Backstage Community plugin standards

Is your feature request related to a problem? Please describe.
At this point we maintain separate packages in different repos which allows for additional flexibility but it requires a lot of effort in terms of maintenance due to release syncing and package dependencies.

Backstage recently announced their Community plugins repo which is going to host community plugins and also implements the standards and processes used in the main Backstage repo.

Describe the solution you'd like
I would like all the packages to be moved into a monorepo and follow the Backstage approach. This would still publish individual packages with their own version but would allow all contributors to the main Backstage repo to transparently contribute to our repo as it follows the same set of steps.

Describe alternatives you've considered
N/A

Additional context
This is not urgent but would reduce the amount of time it takes to do a release and ease the development process.

Extend plugin functionality to create an integration along with service

Is your feature request related to a problem? Please describe.
I want to create an integration along with the service.

Hi there! I would like to seek advice before I go down the path to create a new plugin for my current task. This question is not specific to this Pagerduty plugin, butI have posted this question in Backstage but got no response, so I post here instead.

I want to create a Template that 1) creates a PagerDuty service and, 2) adds an integration for the service such that its integration key can be used in another tool like Grafana.

I have created the PagerDuty service successfully using this guide: https://pagerduty.github.io/backstage-plugin-docs/advanced/create-service-software-template/, but the plugin doesn't support actions to create a service's integration.

I looked into the project's roadmap and it doesn't seem like adding an integration is on the list.

Describe alternatives you've considered
I wonder what's the best route to take from here:

• Approach 1: Create a local plugin in my Backstage app based on the PagerDuty plugin, then extend the ability to create an integration.
• Approach 2: Create a separate plugin with the ability to create an integration. Then create a Template to use actions from both plugins.
• Approach 3: Somehow make a curl request from the software template. I'm looking at this plugin to make HTTP request (https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/scaffolder-actions/scaffolder-backend-module-http-request/README.md), but not sure if it's meant to make any arbitrary requests or just backend's endpoints

I'm new to Backstage in general, please advise me on the most preferable approach. Thank you very much!

Pagerduty Plugin support for teams

Is your feature request related to a problem? Please describe.

Currently in the backstage's pagerduty plugin, we can find the on-calls, active incidents..etc for a PD service. However, I want a similar card to be there for PD teams i.e. if I provide the PD teams, it can give me things like services this team owns, the members, the agg. of the incidents across all its services, Statistics for showing performance of on calls and showing statistics like frequency of same type of errors, severity of the alert ...etc.

Describe the solution you'd like

We can have 2-3 cards - one for showing the teams data, one for showing statistics of team's performance i.e. on call statistics and one for showing statistics related to frequency of alerts

Describe alternatives you've considered
I have modified the existing code of the PD plugin to show data of team members. However, it will be better if the features were written properly and maintained by the PD team

Plugin doesn't refresh from search

Describe the bug
When searching from the Backstage search modal the data of the plugin doesn't refresh

To Reproduce
Steps to reproduce the behavior:

1. Go to an entity that uses the plugin, you should see the PD data of that service (in the example - "acc")
   
2. Click on the "search" from the left pane
   
3. You should see the search modal
4. select a different service from the modal data
5. Look at the PD plugin and see that the data didn't change
   

Expected behavior
After clicking on a different service, the PD data should refresh

Screenshots
Added in the steps above

Desktop (please complete the following information):

• OS: Mac Sonoma 14.2.1
• Browser Chrome
• Version 120.0.6099.129

Additional context
We are connecting the PD plugin using the annotation pagerduty.com/service-id and the package is using EntityPagerDutyCard from @pagerduty/backstage-plugin version: 0.7.3

Who's on Call widget for main dashboard, showing who's on call for multiple services

Is your feature request related to a problem? Please describe.
As an engineer, I can be named on multiple escalation policies. When I'm not on call, it can be difficult to get a summary view of who's on call for all services that I'm concerned with.

Describe the solution you'd like
For the main Backstage dashboard, I would like a widget showing who's on call for all the services where the user logged-in is named on the escalation policy.

Describe alternatives you've considered
An alternative, could be a widget that showed who's on call for a customised list of services (customisable by the user logged into Backstage). It would be great if the user could favourite services for display. This alternative would be useful to a wider range of people as not all Backstage users are engineers or on-call, but many are consumers of services and would appreciate a quick summary and link to frequently used services.

Add support for multiple project ids/service ids per component

Is your feature request related to a problem? Please describe.
Each component we manage in our company is represented by multiple services in Pagerduty, one by environment and cluster/group of machines. The current annotation only work for 1:1 relation between a component and a service_id

Describe the solution you'd like
Be able to add multiple service ids in the pagerduty annotation and adapt the plugin to render an aggregated view of those service ids.

Describe alternatives you've considered
Return the current widget for each service id could be a quick win, but this will lead to potentially a lot of widgets displayed and will be messy for end users. The solution found for a squad view expressed in another issue could be used there as well, based on the multiple values of the annotation instead of the owner relationship ?

Support for multiple PagerDuty accounts

Currently, the plugin is limited to using a single API key. This is restrictive for scenarios where mulitple PagerDuty integrations are necessary.

Lack of required scopes might prevent that `PagerDutyCard` loads properly

Describe the bug
The PagerDuty plugin for Backstage, when configured with OAuth, requires the following scopes to work:

    abilities.read // used in scaffolder only
    analytics.read
    escalation_policies.read
    incidents.read
    oncalls.read
    schedules.read
    services.read
    services.write // used in scaffolder only
    standards.read
    teams.read
    users.read
    vendors.read // used in scaffolder only

If some of these scopes are missing (e.g. standards.read) the PagerDutyCard fails to load and causes to app to crash. This doesn't happen for all scopes as some will fail more gracefully.

To Reproduce
Steps to reproduce the behavior:

1. Register an Application in PagerDuty
2. When setting the Application Scopes select all of the ones above, except for standards.read.
3. Run your Backstage application
4. Open a Backstage entity that contains the PagerDutyCard

Expected behavior
When a required scope is missing I would expect the PagerDutyCard to fail gracefully and present a message saying which scopes are missing in the Application Registration so it can be fixed.

Screenshots
This is how we found out the problem was related to a missing scope 👇

Add support for calling automation actions

Is your feature request related to a problem? Please describe.
The PagerDuty plugin for Backstage is, at this point in time, mostly read-only as it doesn't allow users to perform any action on PagerDuty except from creating incidents.

As Backstage is used as the one stop shop for services I would like to be able to call automation actions from Backstage directly instead of opening to the PagerDuty console and doing it from there.

Describe the solution you'd like
I came up with a basic proposal for what I believe could be the integration of automation actions in Backstage.

In the main incident list we would have a new button that, when clicked, would show the available automation actions available to the user.

Once the automation action was clicked users could check the status of the execution and all previous executions on the Automation Log tab.

Describe alternatives you've considered
At this point in time, the alternative is to open the service page from within the PagerDuty plugin for Backstage and run the automation action from there.

Pagerduty scaffolder actions

Is your feature request related to a problem? Please describe.

The problem that I am trying to solve is of new service onboarding, i.e. when a new service gets created, I want to create a new PD service for it based on the PD team provided by user input

Describe the solution you'd like

We can have a set of actions like

1. pagerduty:create:service - which creates a pagerduty service
2. pagerduty:integrate:*- which integrates the pagerduty service with the other third party services like Datadog, signalFX

Custom scaffolder action to create PagerDuty service

Is your feature request related to a problem? Please describe.
The problem that I am trying to solve is of new service onboarding, i.e. when a new service gets created, I want to create a new PD service for it based on the PD team provided by user input.

Describe the solution you'd like
Create scaffolder action to create a PagerDuty Service from Backstage:

• pagerduty:create:service - which creates a pagerduty service

Additional context
Original issue raised by @Alok650 in #35. Broken down into two issues to reduce scope.

Add support for creating a PR in source repo when updating mapping

Is your feature request related to a problem? Please describe.
The new service mapping feature allows users to map existing PagerDuty services to Backstage entities and provides a simple way to visualize if the configuration is in sync. But doesn't provide an easy way to push the changes to code.

Describe the solution you'd like
I would like to be able to create a PR (automatically or not) to keep my code in sync with the mappings I define in Backstage.

Describe alternatives you've considered
Currently the only option is to create a PR myself which forces me to go to each service individually and create a similar PR across repos.

Add support for disabling the `Edit` action on all rows of the PagerDutyPage component

Is your feature request related to a problem? Please describe.
I'd like to be able to disable the possibility for users to use the Edit action of the PagerDutyPage component and use the PagerDutyPage mostly in a read-only mode.

Describe the solution you'd like
I'd like to be able to disable the Edit action of the PagerDutyPage component from code using an option like disableEditAction, something similar to how it's done for ChangeEvents, e.g. <EntityPagerDutyCard disableChangeEvents>

Describe alternatives you've considered
N/A

Enable easy onboarding for existing services

Is your feature request related to a problem? Please describe.
The PagerDuty plugin provides a software project scaffolder custom action that enables the integration between Backstage and PagerDuty for new services but it is not possible to do the same for existing services.

Describe the solution you'd like
I would like to have an easy way, ideally a page on Backstage, where I could see a list of Backstage entities and the PagerDuty services and easily map them which would inject a Backstage configuration into the Backstage entity. The goal would be to have an easy way to map services without requiring the integration to be setup on each individual service.

Describe alternatives you've considered
Currently the way to achieve this is to update each entity configuration and add the service id or integration key as an annotation.

Additional context
This is an improvement that several customers have asked for to improved the usage of the plugin.

Add link on PagerDuty incident pointing to the corresponding Backstage entity

Is your feature request related to a problem? Please describe.
On PagerDuty, when an integration to Backstage is created, there is no easy way to navigate to that specific entity in Backstage directly.

Describe the solution you'd like
I would like to have a link that would allow me to easily navigate to the mapped Backstage entity from a PagerDuty incident. This can be a custom field with the type URL.

Describe alternatives you've considered
Currently I'm going to backstage and search for the service.

Additional context
This feature was requested by @brianphillips and the Shutterstock team.

Hide change events tab

Is your feature request related to a problem? Please describe.
Change Events is a feature that requires specific licensing, and therefore not available for all PagerDuty customers. Currently if the account does not support change events, it will show an error message on the PagerDuty Card.

Describe the solution you'd like
I would like to have an option to fully remove the change events tab from the PagerDuty Card to avoid additional clicks just to find out that the feature is not available after all.

Additional context
This feature was requested by @asandoval and @jerroydmoore.

Migrate frontend components to Material UI v5

Is your feature request related to a problem? Please describe.
Material UI is already working on Material UI v6(next) and the PagerDuty plugin still uses Material UI 4.

Describe the solution you'd like
I would like to have the plugin migrate to Material UI 5 to facilitate configuration and dependency management.

Describe alternatives you've considered
N/A

On call engineers are duplicated

Describe the bug

There are 2 issues with the list of on call engineers:

• It does not identify which engineer is the primary on call responder
• There are duplicate engineers in the list

To Reproduce
Steps to reproduce the behavior:

1. Go to a service's page, with an escalation policy with multiple engineers
2. The list of on call engineers will not display the primary on call
3. The list of on call engineers will have some duplicates

Expected behavior

• The primary on call engineer should be clearly identified.
• There shouldn't be duplicates, if there are then it should be easy to understand why there are duplicates

Screenshots

• David Wallace is the primary on call engineer, but it's not identified as so.
• David Wallace and Jim Halpert are duplicated for some reason

Desktop (please complete the following information):

• OS: MacOS
• Browser chrome
• Version 119

Add support for contacting on-call engineering through Slack

Is your feature request related to a problem? Please describe.
The existing PagerDuty card component shows the on-call user(s) email information but email is not an effective communication mechanism when working on an ongoing issue.

Describe the solution you'd like
I would like to see a Slack icon next to the on-call user information. By clicking that button it would start a DM on Slack with the user.

Describe alternatives you've considered
Currently I see the name of the person, open Slack and start a new DM to that user.

Backend plugin for querying PagerDuty plugin

Is your feature request related to a problem? Please describe.

As stated in the README of this project "the PagerDuty plugin requires the /pagerduty proxy endpoint be exposed by the Backstage backend as an unprotected endpoint". This raises some security concerns as it leaves the PagerDuty API open to anyone with access to Backstage, without the need to provide any credentials.

Describe the solution you'd like

Backstage documentation recommend using a backend plugin to mitigate this issue. See here

Anyone with access to your Backstage deployment will be able to make requests to the upstream service using the injected credentials. It is recommended that you instead create a backend plugin that forwards individual requests to the upstream service in a secure way

• This page documents the process of developing backend plugins

Describe alternatives you've considered

A likely easier alternative, but still not as safe, would be to log each request to the PagerDuty API with the user ID of the requester. This would at least give us a place to start to investigate any potential security incidents.