923 add support for categories for software

[fembau]

add support for categories for software

Addresses #923 :)

This is a first functional prototype. This branch also includes some pre-defined categories for testing.

Some intro

• categories are organized in a hierarchical structure (tree)
• naming:
  • a category is a leaf in the category tree
  • a parent category is a tree node with sub-categories
  • a top-level category is a tree node with no parent
  • a list of categories traversing the category tree from the top-level category down to a leaf is the category path of the leaf
  • the visual representation of a category path could be p.ex.
    top-level cat / sub-cat / category
• software/projects could be related to multiply categories
  • side effect: because categories are the tree leafs, categories could be re-structured without harming the association to software/projects
  • POV topics are related to research fields (see list of pre-defined categories), thus the origin structure would be:
    POV phase / research field / topic
    ➜ design decision: for now the middle level is left out:
    POF phase / topic

Version 1

• Minimal functionality (!)
• maintainer:
  • .. is able to manage categories for a software:
    • categories = research fields and POF topics
    • start with really simple UI: add/remove button, list of (all) categories
• admin:
  • no admin interface for categories yet. Data for pre-defined categories is injected by an extra migration file during deployment
• user view of a software:
  • add a new headline "Categories" (+icon) in the right lane above "Keywords"
  • ...and a (sorted) list of category paths, p.ex. like this (see example):
    • Research fields | Energy
    • POF IV | Energy System Design
  • show long name on mouse-over an item in a category path

TODOs

Testing

• add backend test?! how?
• add frontend test?!

Usability / Features

• find good representation of category paths
  • p.ex. how should we abbreviate some of these long category names?
  • design
  • interaction (p.ex. show long name on hover)
• add category: do not show already added categories in the offered list

Code structure

• the API calling functions have a lot of copy&paste code. Let's create some generic helper functions for API calls

---

Changes proposed in this pull request:

How to test:

PR Checklist:

• Increase version numbers in docker-compose.yml
• Link to a GitHub issue
• Update documentation
• Tests

[fembau]

enables Array.entries()

[ewan-escience]

Here are a few things I noticed when looking at the database files:

• there is no row level security for category, which means that any logged in user can create, edit and delete categories
• there is no check that the categories cannot form a cycle (e.g. cat1 has parent cat2, cat2 has parent cat1)
• please add the corresponding sanitise functions to category
• is_published = TRUE can be shortened to is_published in a where clause
• some keywords are not capitalised, e.g. references, as

We can furthermore add tests to the backend_tests module to test if all functions and checks work as intended, let me know if you need help with that.

[jmaassen]

Some comments from the UI perspective:

• The design of the categories is now quite different from the keywords directly below:

I think it would be better to use the same design approach: rounded boxed and an "(x)" for deletion instead of a delete button? And maybe a "type to search" option?

• When adding a category, the top entry is "click to add more categories" which implies clicking it will allow you to define a new category (which isn't the case).

• The list of categories becomes quite unwieldy when you have many categories of deeply nested ones. Would an approach similar to Research Domains in projects work?

• When adding multiple categories with the same root, the full path is always shown in each box:

for research domains in projects we use a slightly different approach:

In this case, LS is the parent of both LS3 and LS6 and grand parent of LS3_14. The full path isn't shown for the last three. Would a similar approach work for categories? This may depend on the rules there are to select one? On difference I see is that for Research Domains, one is also allowed to select a top level or mid level one, not just a leaf one.

[ctwhome]

A small comment on the functionality. When the user is not able to add categories (I believe that is because of privileges) there is still a message saying "add categories", but it is not possible to manually add any. It gives the illusion that new categories can be created, but no.

Also, maybe is wise to use muy components instead of native HTML select to keep design consistency and functionality as Jason mentioned.

[ctwhome]

In terms of design I think is oke, the whole information page has become too full of features that in my opinion needs an aesthetic redesign to keep the form inputs more organized.

[ctwhome]

After a meeting between @fembau and me, we came up with a way to display categories that will make it easier for users and developers. We designed a single component that can be used in both view mode and admin mode. This will save time and effort, and make the user experience better.

Our design assumes that the organization has a list of categories already. We don't have a design for this list yet, but that's not part of this PR.

[fembau]

As discussed with @ewan-escience we put the metadata of categories, like color, icon, etc. into the same database table. Most metadata columns would be empty. Other options we talked about: put metadata into extra table (to save space); add a column of type json to store metadata.

[sonarcloud]

[rsd-database] Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

No Coverage information
0.0% Duplication

[sonarcloud]

[rsd-frontend] Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
8 Code Smells

57.1% Coverage
0.0% Duplication

[fembau]

closing in favor of #984