Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Title (Goal)Admin UI - Database Driven Configuration Property Management
Primary ActorSystem | Human
Story (A paragraph or two describing what happens)

Repository Managers should be able to manage most configuration properties from an Administrative UI in DSpace. At this time management of configuration requires editing of properties files and restart of DSpace.

Properties should be stored in database and made available in the UI to be managed there, these properties can be in context of the entire repository, or specific to individual Communities, Collections or Items within the repository.

Dependency Injection and Plugin Management should not be property based, instead existing popular Plugin or Dependency Injection approaches should be leveraged.


  1. Ideally, I would like the ability to deploy some configuration changes without needing to restart the service.  I am not certain that these properties need to move into the database if there is a mechanism to force a property file to be re-read.

  2. Moving this use case as "child" of Admin UI - Configurations in the admin UI, as it's one possible implementation of this broader use case. The broader use case has slightly more details of additional configs that likely should be added to the Admin UI control. 

    While Database Driven Configuration is definitely worth considering, we also may wish to determine whether the database is the best place for all such configurations, or if there are other ways they could also be either dynamically changed or re-deployed.  So, this is just one possible implementation of how configurations could be managed from the Admin UI.

  3. Should we decide to move to Database Driven Configuration, we would need to find a way to easily "sync" configurations across Test and Production instances of DSpace. 

    I has been pointed out (to me) that the detriment to moving configurations to the database, is that it could become more difficult to have a Test Server which "mirrors" your Production Server setup (simply because you'd be forced to "sync" the database-stored configurations, or manually apply the same configurations to each server individually). 

    While file-based configs are definitely not ideal, they are easy to "sync" across servers (simply via 'rsync' or 'scp'). So, in moving configurations to the Admin UI, we'd want to keep in mind a way to "sync" configurations across servers.  If configs are stored in the database, this might still be achievable by simply allowing for a mechanism to:

    1. "dump" configs/settings to a file
    2. sync the file
    3. "reload" configs/settings from a file on the other server

    We may want to have a way to dump/reload configs from a file for other use cases anyways (e.g. simply backing up just your configurations, in case something gets misconfigured and you'd like to "rollback").

    1. I agree that some synchronization will need to take place.  The metadata and format registries may serve as a model for this.  The master instance resides in the database, but the configuration can also be captured in code.

      The configuration changes that I would most like to apply dynamically are handle-based changes such as themes & facets.

      We often wish to develop a custom theme or facet in TEST using a TEST collection handle.  

      Ideally, I would then like to deploy this change to a PROD server, create a new collection in PROD, and then associate the custom change with that new collection handle.

      1. +1 to the idea of the Metadata/Format registries serving as a model for this concept of syncing configs. It had completely slipped my mind that they do essentially achieve this idea of the "live" configs residing in the database, while they can be re-loaded/updated via importing an XML config file.