fraunhofer-iem/dodo-github-visualization

dodo-github-visualization's Issues

Rework API endpoint /api/project/[pid]

• Change name to /api/projects/[pid] to better fit with CRUD naming conventions
• Move KPI list to paginated endpoint /api/projects/[pid]/kpis (see #9)
• Remove selectedKPIs field from response

Visual Glitch Table

TableGlitch.mp4

After loading the table the first click on the next page button triggers a reload even tho there are no additional elements to load. every following click doesn't do that.

Add new API endpoint /api/kpis

Return the list of KPI types including their children as defined for the current user.

Project detail page and API data

The project detail page should pull its data from the API instead of pulling it from a JSON file.

Add API endpoint for organization's ratings

In order to display the organization health, performance, etc. on the landing page as shown below, we need a new API endpoint that returns said indicator(s).
This endpoint should also return the name and rating of the KPIs used to calculate the indicator (in order to populate the rings).

Enable production build

General collection of current problems with creating and using a production build.

KPI detail page and API data

The KPI detail page should pull its data from the API instead of pulling it from a JSON file.

Add new API endpoint /api/projects/[pid]/kpis/[kid]/data

Given that low level KPIs will use a lot of data, it may be a good idea to separate the data from the KpiDetail type. This would also allow us to solve the issue raised in the KpiDetailtype definition:

export type KpiDetail = Kpi & {
  description: string
  children: Kpi[]
  calculation: string
  // this is custom for each KPI, I guess we need to define a type for each KPI
  // and cast the KPI_Detail as needed
  data?: any
}

The new endpoint could return the data and additional information to the data's actual structure, for example:

type KpiData = {
  type: array,
  items: {
    type: number
  } // this is basically taken directly from OpenAPI :)
  data: any
}

This way, we wouldn't need to define types for each and every KPI and can store this information within a database. Leaving it up to the receiver to cast the data to its specified type.

For reference, the OpenAPI data types specification: https://swagger.io/docs/specification/data-models/data-types/

Add new API endpoint /api/projects/[pid]/kpis

List of calculated KPI instances can grow very large rather quickly for a given project. Introduce paginated endpoint /api/projects/[pid]/kpis to retrieve the KPI instances of a project in chunks.
See #8.

Table component sort with API

The Table component needs to sort by requesting the sorted page from the API

Icons are not displayed

After Upgrading to Next.js v12 the icons are not displayed correctly.
The behaviour can be seen in the feature/prodBuild branch.
Information about the changes in v12 can be found here
https://nextjs.org/blog/next-12 and and an upgrade guide here https://nextjs.org/docs/upgrading
I'm not sure how these changes cause issues with the icons, felix can you see anything weired there?

Expand KPI Hierarchy on click

Do not display the full KPI hierarchy. Instead, show only the root level and expand the next level if the user requests it (i.e. by double clicking).

Move KPI Table into separate component

The Project detail and KPI detail pages both implement the KPI list within the sidebar. Avoid this code duplication and move it into something like a KpiTable component.

KPI Hierarchy page and API data

The KPI hierarchy page should pull its data from the API instead of using dummy data from a JSON file.

Table component pagination

Table component should not perform pagination itself but pull the specific chunk of data from the server instead.

pageNumber can be infinitely advanced

The Table component does not detect if its content has reached the final page. If the server responds with an error, turn the page back.

Variable Shadowing

My IDE keeps complaining about variable name shadowing, since we often have code like `const project = projects.find(project => ...)

I can obviously add an ignore statement for this rule, but do we actually want this? Either way I suggest a common style how to handle this since this comes up repeatatly and I think it would be good for code readability if we handle it the same way.

Display KPI hierarchy in detail page's sidebar

As evident in the picture above, calculation of KPIs for a project involves a lot of KPI instances. Simply displaying any KPI instance in any given order within the detail page's sidebar may end up confusing for the user. Therefore we should find a way to allow the user to see or navigate through the hierarchy within the sidebar. For example, by using indentation within the table or list.
Additionally, the API endpoint has to provide the hierarchical information.

Filter and Sort on Table component

Currently, the Table component can sort the current page by any column marked as sortable. At least for paginated data, the sorting has to be done on the server (as it will most likely change page order).

Similarly, filtering (which is not yet implemented on the Table component) shouldn't be done locally for paginated data.

Table Page overflow

If you kill the dev server (in a real world szenario you would just loose the internet connection), the table component goes crazy and issues a couple of thousand requests and the page counter keeps decreasing

Invalid DOM property

When trying to access the KPI hierarchy I get the following warning. From the stacktrace I gather this appears in one of your components @DieserFelix. Mind having a quick look at this?

Collect API type definitions in single file

I would prefer to have a single file with the various type definitions used in the API calls instead of scattering them across the respective route's files.

add automatic release to build pipeline

we should extend the build pipeline to automatically create and tag releases from the main and dev branch.
dev branch should be tagged as beta / non-prod release.
these release tags can be used in the deployment repository to identify which software versions we are currently running