Here is a list of some enhancement ideas or sideprojects to consider.
Prefill ORCID and possibly filename
Fix and document a "magic key" that is prefilled with the ORCID of the signed-in person, e.g. the key datasetUploaderORCID
Similarly, if for some reason we need filename in the metadata, it could also be pre-filled.
Backend validation plugin system
-
Allow to perform additional checks not based on json schema in the backend,
-
report errors back to user for each file/the root metadata
This might be the same script as the postprocessing one: give it the profile and the current data,
let it return an error dict.
So basically it would generalize the interaction from "post-processing hook" to "multi-purpose hook"
Orcid + Guest
Instead of having either ORCID only, or no authentication at all,
allow guests (works like with orcid disabled, i.e. see no datasets, but can create and submit)
This means, the setting orcid.enabled would be semantically separated from orcid.allow_guests
- if both false, no one can do anything
- if both true, you may sign in, but you can also upload without signing in (but then cannot see/revisit your pending submissions)
Admin API
- Pick an ORCID that has admin status
- allow admin to run clean-up job, reload profiles/schemas and the allowlist
- Admin can see all datasets, all normal users only their own
- for an admin, one could also allow profile/schema management in the frontend
Alternatively instead of ORCID have a "secret token" for the Admin Sub-API
Synergy with DirSchema linter tool
Reuse frontend for a local tool to check dirschema
Or think about how maybe dataset profiles should be replaced by (restricted) dirschemas (might be a bad idea), or at least convert the dataset profile into a dirschema that is added into the dataset (definitely a good idea)
Here is a list of some enhancement ideas or sideprojects to consider.
Prefill ORCID and possibly filename
Fix and document a "magic key" that is prefilled with the ORCID of the signed-in person, e.g. the key
datasetUploaderORCIDSimilarly, if for some reason we need
filenamein the metadata, it could also be pre-filled.Backend validation plugin system
Allow to perform additional checks not based on json schema in the backend,
report errors back to user for each file/the root metadata
This might be the same script as the postprocessing one: give it the profile and the current data,
let it return an error dict.
So basically it would generalize the interaction from "post-processing hook" to "multi-purpose hook"
Orcid + Guest
Instead of having either ORCID only, or no authentication at all,
allow guests (works like with orcid disabled, i.e. see no datasets, but can create and submit)
This means, the setting
orcid.enabledwould be semantically separated fromorcid.allow_guestsAdmin API
Alternatively instead of ORCID have a "secret token" for the Admin Sub-API
Synergy with DirSchema linter tool
Reuse frontend for a local tool to check dirschema
Or think about how maybe dataset profiles should be replaced by (restricted) dirschemas (might be a bad idea), or at least convert the dataset profile into a dirschema that is added into the dataset (definitely a good idea)