-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuration import and auto-update #314
Comments
Auto-update of configurations could also be supported by including an update URL in each configuration. This URL could get the latest configuration version and a link to download it. In case configurations are private, a access token could be configured in the update and download URLs. |
Note that each configuration could be a different GitHub/GitLab repository, and the update URL could point to a version.properties on the master branch of the git repository. The download link would be the download ZIP of the master branch. Access tokens would be a personal access token of a "deploy" user. |
…h of metadata form fields; 3)Updated configuration loading logic; 4)Small update to metadata.xml. ------------------------------------------------------------ 1) Submission number is not mandatory anymore, Submission office and Records creator are. Made an appropriate update fo the ARELDA template. 2) Mainly mandatory status and length of fields are validated. 3) For the templates and schemas added logic which overrides older files in the configuration folder. Checking only if file exsist caused that some old templates stayed and there was old UI representation for metadata form, similar with schemas, old schemas caused metadata.xml validation errors. For other configuration files I'm not sure if they can be replaced in such way. There is an open issue in GitHub to validate configuration files, this approach could be better, but not sure about performance: keeps#260 keeps#314 4) Empty <schutzfrist> caused xsd validation erro for metadata.xml, now it is added only when there is a value from user. There could be similar places in metadata.xml generation, not sure if they need an update, at least no more errors.
RODA-in can be configured with a set of options, schemas and templates, but currently there is no easy way to import a pre-made configuration into a stock installed RODA-in. This forces the creation of specialized versions like the Hungarian one.
Have an option in RODA-in to import a configuration, from a file (possibly a ZIP file with a well-defined defined structure similar to the initial roda-in home).
When first installing RODA-in, and roda-in home does not exist, ask the user if he want to initialize with the default configuration or upload a specific configuration. Also, allow to repeat this process in the future by an option in the menu that will reset the configuration to the selected version.
The text was updated successfully, but these errors were encountered: