Skip to content
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

Open
luis100 opened this issue Jul 7, 2017 · 2 comments
Open

Configuration import and auto-update #314

luis100 opened this issue Jul 7, 2017 · 2 comments

Comments

@luis100
Copy link
Member

luis100 commented Jul 7, 2017

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.

@luis100 luis100 added this to the Unplanned milestone Jul 7, 2017
@luis100
Copy link
Member Author

luis100 commented Jul 7, 2017

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.
Download could be done inside the RODA-in application itself, and resetting/reloading the configuration in the end.

In case configurations are private, a access token could be configured in the update and download URLs.

@luis100 luis100 changed the title Configuration import Configuration import and auto-update Jul 7, 2017
@luis100
Copy link
Member Author

luis100 commented Jul 7, 2017

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.

DenysShvorack pushed a commit to scopesolutions-ch/roda-in that referenced this issue Mar 21, 2018
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant