[FEATURE] Add admin page within webportal

[Danny-dK]

Is your feature request related to a problem? Please describe.

Currently various things for admins have to be done using iCommands or various aspects require some knowledge on how Yoda uses certain files and their location. A GUI like page on the Yoda portal specifically for admins would be nice and likely allows a larger variety of people to be assigned as an admin to Yoda (there would be less dependency on affinity with a CLI). This in the long run would alleviate pressure on UU and SURF functional admins and developers when institutes / organizations / sub-organizations are able to do things themselves. This may also separate the function rodsadmin from a general functional admin.

Describe the solution you'd like

An admin page where a Yoda admin can:

• YDA-5718: Create and activate a banner to be displayed on the homepage of the Yoda webportal for example when there is maintenance / downtime expected. (input Danny)

• YDA-5720: See current text templates for, for example, the text templates used during the publication workflow, and be able to adjust them from the webportal. (input Danny)

• YDA-5719: Be able to adjust themes from a GUI like perspective. (input Danny)

• YDA-5721: Configure lists of preservable file formats

• Perhaps a dashboard type information on storage. Currently there is a statistics page, but perhaps could be more of a dashboard. At SURF the Grafana dashboard is available that gives some nice insights (although a bit too busy for my liking). (input Danny)

• List all user that are currently associated with a research group (basically iquest --no-page "%s" "SELECT ORDER_DESC(USER_NAME) WHERE USER_GROUP_NAME LIKE 'research-%' and USER_TYPE = 'rodsuser'"). (input Danny)

• List all Yoda data managers (basically iquest --no-page "%s" "SELECT ORDER_DESC(USER_NAME) WHERE USER_GROUP_NAME LIKE 'datamanager-%' and USER_TYPE = 'rodsuser'"). (input Danny)

• List all (rods)admins (basically iquest "select USER_NAME WHERE USER_TYPE = 'rodsadmin'"). (input Danny)

• View and empty trashes. (input Danny)(basically

  iquest "SELECT SUM(DATA_SIZE) where COLL_NAME like '/wur/trash/home/%wur.nl/%' 
  irmtrash -r -V -M "/wur/trash/home/john.doe@wur.nl/vault-testdannyrmvault"

Please add points in comments below (and of course whether agree or not). For example from the top of my head @peer35, @DorienHuijser, and Nika (need to find her git name), and the Yoda UU data managers. Of course others are very welcome to give input.

I fully understand that this is something for the very long run in years to come.

Describe alternatives you've considered

Train heavily in iCommands, but honestly, CLI is not for everyone.

[peer35]

I certainly agree with all the points in this request. It would make our admin's (and SURF's) live easier.

• With regards to trash: currently I do irmtrash -rMV --age 43200 to delete all trash older than 30 days. It would be good to be able to do this via an admin page, or to be able to set an age limit and schedule it.

• With regards to the storage usage: Add metadata fields to the Yoda groups so we can register owner and cost centre information.

• Include these administrative fields in the statistics export. This would be sufficient for our internal cost reporting.

[Boehlf]

I've got a number of additional requests:

1. Documentation: clear link to the github page in the UU Yoda documentation
2. Overview of planned features (and their priorities).
3. Being able to update the contents of a datapackage, cq. the content of a file in a data package while data is allready archived/published. Preferably with a logging function.
4. Being able to change (sub) categories and or metadata schemes for groups.
5. Some standard management reports (which I get now sent daily to a specific group by Sietse), e.g. number of groups, No of empty groups, last use date of a group, groups per manager, groups per user - downloadable in CSV format.
6. Direct coupling with high computing environments, e.g. SURFResearch Drive, incl. documentation.

[Danny-dK]

@Boehlf These are less for the admin page I suppose?

1. can be done / included in the Yoda website maybe?
2. perhaps related to https://github.com/UtrechtUniversity/yoda/discussions/405
3. doi versioning is available to update files to a new version (https://github.com/UtrechtUniversity/yoda/issues/140). The base doi then always resolves to the latest version available. I don't think it is wise to be able to update files without doi versioning. If only documentation is present of changes made to files, it can become confusing to others reusing data (and depending on the amount of changes, it can become very chaotic). Yoda data managers can always update the metadata file even after publication.
4. Not sure what you mean with be able to change categories? You can update the research group properties and change the category or subcategory that a research group belongs to (if you don't have these privileges, ask the Yoda team to add you to these privileges). Metadata can currently be chosen while creating a research group. I don't know what the impact is once a metadata scheme has been chosen and changed afterwards. A workaround is to create a new research group, choose the metadata scheme you want to use, and copy all data from the previous research group to the new research group.

6 I'm not sure the coupling is on Yoda side. It is linked to this discussion https://github.com/UtrechtUniversity/yoda/discussions/208 and https://github.com/UtrechtUniversity/yoda/issues/353