axiscommunications / backstage-plugins Goto Github PK

Please do not disclose security vulnerabilities as issues. See our security policy for responsible disclosures.

Describe the bug

Hi all,

I have installed the Frontend and Backend integration and given the data from my StatusPage account but I am experiencing an issue attempting to see the data.

The error is No implementation available for apiRef{plugin.statuspage}. I have provided a screenshot below.

This issue is occurring in my current implementation of Backstage as well a fresh instance from the Getting Started Documentation

To reproduce

1. Create a new instance of Backstage using the Getting Started Documentation
2. Install StatusPage frontend and StatusPage backend
3. Add annotations to a component
4. Navigate to where the Card is on the Component
5. See error

Screenshots

Error:

Environment

• Stack trace or logs: Provided in screenshot above
• OS and version: Linux 6.6.12-linuxkit - linux/arm64
• Backstage Version: 1.23.3
• NodeJS Version: v18.19.1

Additional context

I did make some small changes based on the plugin guides. They are:

1. Removed authMiddleware, changing apiRouter.use('/statuspage', authMiddleware, await statuspage(statuspageEnv)); to simply apiRouter.use('/statuspage', await statuspage(statuspageEnv));. Adding it back in did not solve my issue
2. Changed StatuspageEntityComponent to StatuspageEntityCard, changing import { StatuspageEntityComponent, isStatuspageAvailable } to import { StatuspageEntityCart, isStatuspageAvailable }

My config values are:

1. My statuspage configuration looks like the following:
   
2. My annotations look like the following:
   

Please do not disclose security vulnerabilities as issues. See our security policy for responsible disclosures.

Describe the bug

When I open the dashboard page on an entity I get a TypeError "Cannot read properties of undefined (reading 'name')".

I assume the problem is that it is expected that a projectCategory object is in the response from Jira Cloud (i.e. https://company.atlassian.net/rest/api/2). In my case there is no such entry in the response json.

To reproduce

I configured the Jira Dashboard plugin according to the official guide.

I configured an entity with annotation "jira.com/project-key: 'key' (I cannot provide the exact key because it is a company Jira).

I started the developer portal in dev mode with "yarn dev"

When I open the dashboard on an entity I get a TypeError "Cannot read properties of undefined (reading 'name')".

Screenshots

Environment

• Stacktrace

`index-fe0f2c13.esm.js:38 Uncaught TypeError: Cannot read properties of undefined (reading 'name')
at JiraProjectCard (index-fe0f2c13.esm.js:38:1)
at renderWithHooks (react-dom.development.js:14985:1)
at mountIndeterminateComponent (react-dom.development.js:17811:1)
at beginWork (react-dom.development.js:19049:1)
at HTMLUnknownElement.callCallback (react-dom.development.js:3945:1)
at Object.invokeGuardedCallbackDev (react-dom.development.js:3994:1)
at invokeGuardedCallback (react-dom.development.js:4056:1)
at beginWork$1 (react-dom.development.js:23964:1)
at performUnitOfWork (react-dom.development.js:22776:1)
at workLoopSync (react-dom.development.js:22707:1)
JiraProjectCard @ index-fe0f2c13.esm.js:38
renderWithHooks @ react-dom.development.js:14985
mountIndeterminateComponent @ react-dom.development.js:17811
beginWork @ react-dom.development.js:19049
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
beginWork$1 @ react-dom.development.js:23964
performUnitOfWork @ react-dom.development.js:22776
workLoopSync @ react-dom.development.js:22707
renderRootSync @ react-dom.development.js:22670
performSyncWorkOnRoot @ react-dom.development.js:22293
eval @ react-dom.development.js:11327
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushSyncCallbackQueueImpl @ react-dom.development.js:11322
flushSyncCallbackQueue @ react-dom.development.js:11309
scheduleUpdateOnFiber @ react-dom.development.js:21893
dispatchAction @ react-dom.development.js:16139
eval @ useAsyncFn.js:22
Promise.then (async)
eval @ useAsyncFn.js:21
eval @ useAsync.js:12
invokePassiveEffectCreate @ react-dom.development.js:23487
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
flushPassiveEffectsImpl @ react-dom.development.js:23574
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushPassiveEffects @ react-dom.development.js:23447
eval @ react-dom.development.js:23324
workLoop @ scheduler.development.js:417
flushWork @ scheduler.development.js:390
performWorkUntilDeadline @ scheduler.development.js:157

index-fe0f2c13.esm.js:139 Uncaught TypeError: Cannot read properties of undefined (reading 'split')
at Object.render (index-fe0f2c13.esm.js:139:1)
at getRenderValue (utils.js:96:1)
at MTableCell (index.js:42:1)
at renderWithHooks (react-dom.development.js:14985:1)
at mountIndeterminateComponent (react-dom.development.js:17811:1)
at beginWork (react-dom.development.js:19049:1)
at HTMLUnknownElement.callCallback (react-dom.development.js:3945:1)
at Object.invokeGuardedCallbackDev (react-dom.development.js:3994:1)
at invokeGuardedCallback (react-dom.development.js:4056:1)
at beginWork$1 (react-dom.development.js:23964:1)`

• Version: "@axis-backstage/plugin-jira-dashboard": "^0.1.0"

Additional context

Add any other context about the problem here.

Describe the bug

annotationPrefix is ignored after adding if={entity => isJiraDashboardAvailable(entity, 'jira')} and added the environment variable
JIRA_ANNOTATION_PREFIX as "jira" as well.

Explain the behavior you would expect and the actual behavior.
I was expecting the code will avoid looking for "jira.com" prefix.

To reproduce

set the changes I set above.

Describe the bug

Newest 0.7.1 version of @axis-backstage/plugin-jira-dashboard was published with workspace version tag

  "dependencies": {
    "@axis-backstage/plugin-jira-dashboard-common": "workspace:^",

This makes it impossible to yarn add it or yarn install it. I had to freeze it to 0.7.0 version to get it working

yarn --cwd packages/app add @axis-backstage/plugin-jira-dashboard

➤ YN0000: · Yarn 4.1.0
➤ YN0000: ┌ Resolution step
➤ YN0001: │ Error: @axis-backstage/plugin-jira-dashboard-common@workspace:^: Workspace not found (@axis-backstage/plugin-jira-dashboard-common@workspace:^)
 

To reproduce

Run yarn --cwd packages/app add @axis-backstage/plugin-jira-dashboard on any backstage project or add "@axis-backstage/plugin-jira-dashboard": "0.7.1" dependency to packages/app/package.json file and run yarn install.

Screenshots

Here's package.json file of the released artifact: https://www.npmjs.com/package/@axis-backstage/plugin-jira-dashboard/v/0.7.1?activeTab=code

Additional context

My guess is that recent changes to publish process caused this issue by not resolving workspace version to a semver before releasing artifact.

Describe the bug

The Dashboard get's the Issues from a Jira Server instance with a BaseURL (https://SERVER/PATH/...) The Dashboard Frontend rewrites the URL into https://SERVER/... Ignoring the PATH part of the Jira BaseURL.

This results in JIRA Issues, which are displayed in the frontend with details, but the Links to JIRA are broken (missing the PATH). Therefore one cannot open them on the JIRA Server.

It looks as if the problem is in https://github.com/AxisCommunications/backstage-plugins/blob/main/plugins/jira-dashboard/src/lib.ts

export const getProjectUrl = (project: Project) => {
  const url = new URL(project.self);
  return `https://${url.host}/browse/${project.key}`;
};

This function returns only the Host part of the URL, ignoring the additional PATH.

Example:
Given: "self": "https://SERVER/PATH/rest/api/2/project/ID"

Actual Return:
https://SERVER/browse/PROJECTKEY

Expected Return:
https://SERVER/PATH/browse/PROJECTKEY

Same is true for

export const getIssueUrl = (issueUrl: string, issueKey: string) => {
  const url = new URL(issueUrl);
  return `https://${url.host}/browse/${issueKey}`;
};

To reproduce

Steps to reproduce the behavior:

1. Set up JIRA Server with a BaseURL of https://SERVER/PATH
2. Install & Configure backstage
3. install & Configure Plugin
4. Open Backstage with plugin

Additional context

Found on JIRA Server

Describe the bug

When using the readme component in fullHeight mode it takes at max of 500px height, while it should take all available height.

To reproduce

Add readme card in a fullHeight mode

<EntityLayout.Route path='/readme' title='Readme'>
      <ReadmeCard variant="fullHeight" />
    </EntityLayout.Route>

Screenshots

Describe the feature

Title: Update Project Lead Name Field from 'key' to 'displayName' for Clarity and Consistency

Description:
Currently, the project lead name field in our system is labeled as 'key', which might lead to confusion and ambiguity for users. This issue suggests updating the label to 'displayName' to provide clearer and more descriptive information.

Steps to Implement:

1. Identify all instances where the project lead name field is referenced as 'key'.
2. Replace occurrences of 'key' with 'displayName' in the relevant codebase.
3. Update documentation and user interface elements to reflect the change.
4. Test the updated functionality to ensure proper functionality and clarity.

Expected Behavior:
After implementing this enhancement, users will see the project lead name displayed as 'displayName' throughout the system, leading to improved clarity and consistency in data representation.

Added Value:
This enhancement will greatly benefit users by reducing confusion and improving the overall user experience. Clear and consistent labeling of fields enhances usability and reduces the likelihood of errors. By adopting this change, we align our system with best practices in data representation, enhancing user satisfaction and efficiency.

Describe the feature

At present, the incomingFilter in the jira-dashboard-backend plugin only searches for tickets with the status new. This limits the plugin's usability in Jira workflows where sometimes the initial status of tickets is not new, but something else like To Do.

To enhance the plugin's flexibility, it would be beneficial to introduce an optional annotation for the "incoming issues" status. This annotation would allow users to specify the name of the status for incoming issues.
For instance:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  # ...
  annotations:
    jira.com/incoming-issues: value  # optional: The name of the status for incoming issues e.g. 'To Do'

Added value

This feature would improve the usability of the frontend plugin.

Additional context

Please do not disclose security vulnerabilities as issues. See our security policy for responsible disclosures.

Describe the bug

when it is deployed behind my auth proxy service, the /:entityref path parameter gets decoded and then the backend fails to find a matching URI path. This is what happens:

UI fetches:
/api/jira-dashboard/avatar/by-entity-ref/component%3Adefault%2Fexample-website

Backend URI received:
/api/jira-dashboard/avatar/by-entity-ref/component:default/example-website

so express is trying to match a route for something like the below APIs, but can't find it and responds with a 404:
/api/jira-dashboard/avatar/by-entity-ref/:entityref/example-website
/api/jira-dashboard/avatar/by-entity-ref/:entityref/:name

where ":entityref == "component:default"

Technically speaking, RFC3986 section 2.2 explains the risks of encoding reserved characters such as '/' in the URI path:

The purpose of reserved characters is to provide a set of delimiting
characters that are distinguishable from other data within a URI.
URIs that differ in the replacement of a reserved character with its
corresponding percent-encoded octet are not equivalent. Percent-
encoding a reserved character, or decoding a percent-encoded octet
that corresponds to a reserved character, will change how the URI is
interpreted by most applications.

Reference:
https://datatracker.ietf.org/doc/html/rfc3986#section-2.2

To reproduce

1. Setup backstage to use the oauth2Proxy sign on provider as such:
   https://backstage.io/docs/auth/oauth2-proxy/provider

2. startup oauth2Proxy such as this example docker-compose file: https://github.com/backstage/backstage/blob/57397e7d6d2d725712c439f4ab93f2ac6aa27bf8/plugins/auth-backend/examples/docker-compose.oauth2-proxy.yaml

3. add jira-dashboard plugins to the backstage app.

4. Navigate to the jira-dashboard tab of a valid entity.

5. Jira tab shows "404" error, where UI fetches:
   /api/jira-dashboard/avatar/by-entity-ref/component%3Adefault%2Fexample-website

Backend URI received:
/api/jira-dashboard/avatar/by-entity-ref/component:default/example-website

Environment

• Node 18.16.1
• React 18
• custom auth proxy, but can be tested with the oauth2Proxy

Please do not disclose security vulnerabilities as issues. See our security policy for responsible disclosures.

Describe the bug

We have installed the readme plugin. The README panel shows up on the detail page of a service. However, the standard text is shown, not the actual readme. I have read the trouble shooting guide, which indicated to change the backstage.io/source-location label to point to the blob path instead of the tree path. However, that would require us to do that for all the hundred services.

To reproduce

Just install the plugin as is, define a component and see the default README card on the default page
Steps to reproduce the behavior:

1. Set up the readme plugin v.
2. Add a simple component using a catalog-info.yaml file hosted on github without specifying the backstage.io/source-location label
3. Import that file into backstage
4. Check the detail page of the component

Environment

• latest backstage readme plugin version

Additional context

My understanding that the label backstage.io/source-location is populated by backstage by default like this: url:https://github.com/organisation-name/repository-name/tree/master/ but it should be url:https://github.com/organisation-name/repository-name/blob/master/

Instead of overriding the label, wouldn't it be easier, if the plugin modified the URL to the correct point? Thanks for your help, really appreciate it!

Describe the bug

Unable to start the project post adding the Jira backend plugin getting the following error

Backend failed to start up TypeError: Cannot read properties of undefined (reading 'fromConfig')

To reproduce

Steps to reproduce the behavior:

1. Set up a new backstage project .
2. Added the plugin by following the documentation including the steps adding the three lines required.

• Create a new file with the name jiraDashboard.ts.
• Added the following lines into src/index.ts.

import jiraDashboard from './plugins/jiraDashboard';
 
// Add this line into main()
  const jiraDashboardEnv = useHotMemoize(module, () => createEnv('jira-dashboard'));
  
// Add this following line into the existing routes
  apiRouter.use('/jira-dashboard', await jiraDashboard(jiraDashboardEnv));

yarn dev
yarn run v1.22.21
$ concurrently "yarn start" "yarn start-backend"
$ yarn workspace app start
$ yarn workspace backend start
$ backstage-cli package start
$ backstage-cli package start
[0] Loaded config from app-config.yaml, app-config.local.yaml
[0] <i> [webpack-dev-server] Project is running at:
[0] <i> [webpack-dev-server] Loopback: http://localhost:3000/, http://[::1]:3000/
[0] <i> [webpack-dev-server] Content not from webpack is served from '/Users/<username>/test_projects/developer-activity/packages/app/public' directory
[0] <i> [webpack-dev-server] 404s will fallback to '/index.html'
[0] <i> [webpack-dev-middleware] wait until bundle finished: /catalog?filters%5Bkind%5D=component&filters%5Buser%5D=all
[0] webpack compiled successfully
[1] Loaded config from app-config.yaml, app-config.local.yaml
[1] 2024-01-04T13:43:13.564Z backstage info Found 3 new secrets in config that will be redacted
[1] ObservableConfigProxy {
[1]   parent: undefined,
[1]   parentKey: undefined,
[1]   config: ConfigReader {
[1]     data: { proxy: [Object] },
[1]     context: 'app-config.local.yaml',
[1]     fallback: ConfigReader {
[1]       data: [Object],
[1]       context: 'app-config.yaml',
[1]       fallback: undefined,
[1]       prefix: '',
[1]       filteredKeys: undefined,
[1]       notifiedFilteredKeys: Set(0) {}
[1]     },
[1]     prefix: '',
[1]     filteredKeys: undefined,
[1]     notifiedFilteredKeys: Set(0) {}
[1]   },
[1]   subscribers: [ [Function (anonymous)] ]
[1] }
[1] Backend failed to start up TypeError: Cannot read properties of undefined (reading 'fromConfig')
[1]     at makeCreateEnv (/Users/<username>/test_projects/developer-activity/packages/backend/src/index.ts:43:35)
[1]     at main (/Users<username>/test_projects/developer-activity/packages/backend/src/index.ts:86:21)

Additional context

• Tried both available version 0.1.0 and 0.2.0 still encountering same issue

Add any other context about the problem here.

Describe the bug

The "Assigned to me" Entity does not work if the backstage username is different from the email-prefix.
For example, Backstage user: user:default/FooBar does not work for email addresses like: [email protected] or [email protected].

I would expect that it is not needed for the username to match the email-address.

Possible solution

After roughly looking at the code-base, I guess the issue comes from the way the userIdentiy is used.
Currently, the username is taken from the identityAPI.userEntityRef and the email suffix is then added based on the JIRA_EMAIL_SUFFIX configuration variable.

A better approach would be to directly use the email address of the user. Maybe this can be used?

Code-Directions:

• backstage-plugins/plugins/jira-dashboard-backend/src/filters.ts

  Line 6 in ce0637c

  return userRef?.split('/').slice(1)[0];

• backstage-plugins/plugins/jira-dashboard-backend/src/service/router.ts

  Line 148 in ce0637c

  userIdentity?.identity?.userEntityRef,

• backstage-plugins/plugins/jira-dashboard-backend/src/service/router.ts

  Line 135 in ce0637c

  const userIdentity = await identity.getIdentity({ request: request });

Screenshots

Additional context

If you need any additional information, I am more than happy to help!

Please do not disclose security vulnerabilities as issues. See our security policy for responsible disclosures.

Describe the bug

I following the instructions about using a Bearer token and I am getting a 401 when I check the health:

 curl localhost:7007/api/jira-dashboard/health
{"error":{"name":"AuthenticationError","message":"Missing credentials","stack":"AuthenticationError: Missing credentials\n    at DefaultHttpAuthService.credentials (/mnt/c/Users/u1175114/Gitlab-tstenv/backstage_poc/backstage/node_modules/@backstage/backend-defaults/node_modules/@backstage/backend-app-api/src/services/implementations/httpAuth/httpAuthServiceFactory.ts:150:13)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"},"request":{"method":"GET","url":"/api/jira-dashboard/health"},"response":{"statusCode":401}} 

Using the same Bearer token calling directly to the Jira instance it works correctly:

schaves:~$ curl -H "Authorization: ${JIRA_BEARER_TOKEN}" https://XXXXXXXXX/rest/api/2/project/SDLC
{"expand":"description,lead,url,projectKeys","self":"https://XXXXXXXXX/rest/api/2/project/10200","id":"10200","key":"SDLC","description":"","lead":{"self":"https://XXXXXXXXX/rest/api/2/user?username=q831841","key":"q831841","name":"q831841","avatarUrls":{"48x48":"https://XXXXXXXXX/secure/useravatar?ownerId=q831841&avatarId=10500","24x24":"https://jira.rwts-.........
}

To reproduce

 curl localhost:7007/api/jira-dashboard/health
{"error":{"name":"AuthenticationError","message":"Missing credentials","stack":"AuthenticationError: Missing credentials\n    at DefaultHttpAuthService.credentials (/mnt/c/Users/u1175114/Gitlab-tstenv/backstage_poc/backstage/node_modules/@backstage/backend-defaults/node_modules/@backstage/backend-app-api/src/services/implementations/httpAuth/httpAuthServiceFactory.ts:150:13)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)"},"request":{"method":"GET","url":"/api/jira-dashboard/health"},"response":{"statusCode":401}} 

OR

Please provide as much context as possible and describe the reproduction steps that someone else can follow to recreate the issue

Here are the important details for the backend setup:

jira/project-key: KEY
jira/component:Component

This helps the users to adopt the plugin with less efforts

Hi,

sorry to misuse the issue function but I want to ask how your release roadmap looks like? I saw your comments on backstage Discord a while ago and have been waiting to integrate/test your plugin from an npm registry.

Thx.

I've set readme and readme-backend plugins like it's described here and here (old backend) with no more changes in code and got this error

Cannot set headers after they are sent to the client\n    
at ServerResponse.setHeader (node:_http_outgoing:659:11)\n    
at ServerResponse.header (/app/node_modules/express/lib/response.js:795:10
at ServerResponse.send (/app/node_modules/express/lib/response.js:175:12)\n    
at ServerResponse.json (/app/node_modules/express/lib/response.js:279:15)\n    
at /app/node_modules/@axis-backstage/plugin-readme-backend/dist/index.cjs.js:123:26\n    
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)","type":"errorHandler"} 

Linguist data was loaded fine, but readme failed

Any ideas what could be the reason? I can try to provide more details

These messages are present in logs:

{"level":"info","message":"::ffff:my.ip - - [20/May/2024:14:32:38 +0000]Initializing readme backend \"GET /favicon.ico HTTP/1.1\" 200 - \"-\" \"mybrowserinfo\"","service":"backstage","type":"incomingRequest"}

{"level":"info","message":"Fetch README component:default/testrepo: https://github.com/myorgname/testrepo/README, text/plain ","plugin":"readme","service":"backstage","type":"plugin"}

{"level":"info","message":"Readme not found for component:default/testrepo","plugin":"readme","service":"backstage","type":"plugin"}

(I replaced ip with my.ip, browser info with mybrowserinfo and org, repo name with myorgname and testrepo above)

This issue addresses two key improvements in our project management tool: updating the thumbnail representation of assignees and revising the terminology used for the project lead. The current thumbnail display lacks consistency and clarity, hindering quick identification of assignees. Additionally, the term 'key' used to represent the project lead is ambiguous and lacks descriptive value. This update aims to enhance clarity and consistency throughout the tool by improving the visual representation of assignees' thumbnails and replacing 'key' with 'displayName' for the project lead.