923 add categories for software

[dmijatovic]

PR #946 was polished and prepared for v2 -> created this new PR.

How to test:

remove extra file extension from 999-add-categories.sql.example, optional edit file and finally build application as usual.

On a software edit page you will find a new headline "Categories".

[fembau]

@dmijatovic it seems that only you can switch off draft state ;) Please also review this PR (can not add you)

[ewan-escience]

Nice work! I have a few small comments/questions:

• What is frontend/.yarn/releases/yarn-1.22.19.cjs? It is 5MB in size. Can it be removed? Same for frontend/.yarnrc.yml.
• Please remove the AND is_published from the policy 'anyone_can_read' on category_for_software, that logic is already covered by the policy on software.
• Please capitalise 'as' everywhere in category_paths_by_software_expanded
• In the test, please put the User class in a dedicated file.
• I'm not sure about the User constructor using HTTP requests to initialise itself. I think it's better to have a static factory method somewhere that does this for you and returns a User upon success. But this could be done later as well.
• Line 273 can be deleted as it only contains a unnecessary semicolon.
• Maybe a test can be added that tries to create a cycle in the categories.
• Is it intentional that there is not an admin interface to add/edit categories?

[jmaassen]

Works well, some comments:

• I was slightly confusing at first that the categories in the drop down list when selecting are different that what you see after selecting. This was mainly because in the example the "Category X aka X.Y.Z" is shorter than the short name ;-)

• currently, only leaf items can be selected. Are you sure this restriction is okay? For the research domains in projects one can also select top or mid level values

• having an icon is a nice touch. Do we have documentation on which icon names are valid? Currently it says "science".

• for consideration: can we use the same approach for projects? You could say that "Research domains" is simply the top level category.

[dmijatovic]

@fembau If you need the yarn settings @ewan is referring, please add these to .gitignore file. That way these will not be included in the repo.

[fembau]

Thank you for your feedback! :)

@ewan-escience @dmijatovic:

• ejected yarn topic from this PR. see also discussions/843
• Please remove the AND is_published from the policy 'anyone_can_read' on category_for_software, that logic is already covered by the policy on software. --> This should prevent reading information related to not-published software.
• moved User to separate file + added factory. Also created a class Commons
• beautified code :)
• added test for cyclic categories.
• admin interface is postponed to add interface for managing categories as admin #952

@jmaassen:

• improved text of example categories :)
• select leafs only: yes, as proposed in the related issue I think this is the proper way of using a catalog/vocabulary here... Anyhow it is currently not prevented by the backend...
• icons: until we have Dynamically load icons #975 available icons are defined in frontend/components/typography/Icon.tsx. I put a note into the examples file.
• also for projects: yes, this is intended. Kept this out of this PR to make it smaller and setup a generic foundation first ;)

We have already seen that generic categories inspire lots of ideas what we could do next :)

[ewan-escience]

This should prevent reading information related to not-published software.

But that is already covered by SELECT 1 FROM software WHERE id = software_id, which takes the published status into account because of the row level security on software.

A small pet peeve of mine, the example SQL file is indented with spaces instead of tabs. :)

That's all from me, nice work!

[cmeessen]

Awesome, this is looking really good already.

I created #992 to address one aspect that was part of #741 but was not implemented yet.

[fembau]

@ewan-escience understood now the hidden magic :) -> fixed

Also finally fixed Sonarcube code smells.

I do not agree with one rule considering export type CategoryID = string as redundant type alias and disabled it for that line. In my opinion, having an explicit type here improves readability and type-safety.

[sonarqubecloud]

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

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sonarqubecloud]

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

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

39.8% Coverage
0.0% Duplication