[FEATURE] Remove/Filter components in ODTP dashboard

[jugdemon]

• Feature name: Management tools for components in ODTP Dashboard

Description:

Once a component has been added, it cannot be removed even if there is a superseding version and we don't want to keep the old one. It would be great, if we can manage the components like filter, delete, archive, hide or makes sense.

Importance Level

Medium

This feature makes it possible for non-command line users to manage an evolving codebase in ODTP. We

Origin

If you have multiple versions of the same component. The component list becomes very crowded. It is important for the user to find the components that they actually need.

User Impact

The update will make users interaction with components more accessible and comprehensive.

Mockups or Diagrams

Here is a UI mockup with the three dots opened. The three dots are connected to the section toggles on the left. (in the best case only available if something is selected)

Affected Components (examples: components, modules, … )

I believe this can already be done on the CLI but the front end would benefit from also exposing this to non-CLI users.

Technical Requirements (if possible, otherwise completed by SDSC)

Detailed technical specifications or requirements needed to implement the feature. This could include algorithms, data structures, APIs, or third-party services.

Related Documents/Links:

References to any related documentation, user stories, tickets, or external resources that provide additional context.

Dependencies (if possible, otherwise completed by SDSC):

Identification of any other features, systems, or processes that the proposed feature depends on or interacts with. This can be considered a “ready if” field and it will define what’s needed to have in order to start the development.

Acceptance criteria:

Specific criteria or metrics for evaluating the success or effectiveness of the feature once implemented.

[sabinem]

@jugdemon Here I would not delete the component versions, but deprecate them and then offer a filter to show or hide deprecated versions. I could also offer to delete versions when no execution uses them any more, but as long as execution rely on them, they need to be kept in the database.

So what I suggest to implement is:

• add filter to show deprecated, active, or all versions
• add column to the table of versions where they can be checked
• add a button to deprecated all checked versions
• add a button to activate all checked versions

Optional: Deprecated versions that are not used in any executions can also get deleted.

[jugdemon]

This makes sense. I didn't think of the user components in executions while writing this.

Another way to keep the UI clean is to bundle the same component and make the version a drop down menu. Then there should be a button in the menu "expand to show all version/ collapse version". No need to implement this if your proposal is easier to do.

[caviri]

Hello @sabinem. The removal of a component version entry, or a component document entry I think it's useful for development purposes. Cases where you want to test the addition of a component into ODTP.

However, as you pointed it gets complicated when those components has been used in executions. So I agree with only deleting those that are unused. Once the execution is deleted they can be erased from the database.