configuration for enabling DCM,RSAL, etc (external components)

[pameyer]

External components for non-http uploads, downloads, etc (DCM,RSAL) are disabled by default; in order to be usable there needs to be a way to turn them on.

For SBGrid v1.0, minimal functionality would be disabling native (http) uploads and downloads in favor of DCM/RSAL uploads and downloads.

Open questions:

• Installation-level or dataverse-level? dataverse-level is additional complexity that doesn't (yet) seem to get additional functionality
• Settings table, or elsewhere? Probably settings table
• One switch for both uploads and downloads, or one for each? Two switches (aka - one for each) seems like it's worth the minimal additional complexity.
• Binary configuration items (on/off switch), or lists (native/http,dcm/rsync+ssh, etc)? Additional implementation complexity and/or performance of lists vs binary hasn't been evaluated

[pameyer]

"elsewhere" other than settings table - possibly JVM options; possibly properties file.

"Don't document settings" (from PD - these settings won't be useful until dependent issues are implemented).

[pdurbin]

@scolapasta have we made a decision about how and where to persist whether a dataset is in "rsync" mode or "standard" mode? See #3347 where there's a proposed enum that contains three items:

• STANDARD
• RSYNC
• DROPBOX

In that code the "mechanisms" are persisted at the dataverse level as "RSYNC:STANDARD" for example: https://github.com/bmckinney/dataverse-canonical/blob/b280c34fcc231b41cf9e801aff992e3858c17775/src/main/java/edu/harvard/iq/dataverse/Dataverse.java#L724

If all of this is out of scope for this issue, which issue are we using to track this? @djbrooke has asked if we can close #3347 but we still have a need to express what mode a dataset is in.

[pameyer]

Current experimental protoype:

• Installation level configuration
• in setting table (not JVM options / properties file)
• two switches (one for uploads, one for downloads)
• Lists instead of binary on/off, support methods in edu.harvard.iq.dataverse.SettingsWrapper; absence of setting for handling upload/download treated as 'native only'; likely makes sense to move generic "do stuff with setting" list out of there but will defer that until discussion/code review.
• ugly POC UI exists, primarily for evaluating functionality (in other words, xhtml changes not for merging)
• makes sense to have tests on SettingsWrapper.allowNativeDownloads() , SettingsWrapper.allowNativeUploads(); currently unclear on how.

Additionally - ugly POC UI testing clarified that "disable native" will have non-UI implications (distinct from #3725).

[pameyer]

For reference, current experimental prototype https://github.com/IQSS/dataverse/tree/3724-extconf

[pameyer]

re "likely makes sense to move ..." - place to move to appears to be edu.harvard.iq.dataverse.util/SystemConfig

[pdurbin]

@pameyer created a pull request at #3830 (thanks!). I'll take a look.

[pameyer]

some initial comments from @pdurbin

• settings keys should be in the setting key enum with the others
• this pull request should also have the DCM url and RSAL url

[pdurbin]

@pameyer yep. Here's a commit you can look at where I added a setting to that enum and documented it, which you should also do: 499e6be

Also, I see you modified SettingsWrapper.java which is fine for UI stuff but it's only used in the UI (JSF). SystemConfig.java is deeper in the system and can be used by the API as well.

Back in the day I added DataCaptureModuleUrl to the enum and here's where I call it in a REST Assured test I'm working on for #3725:

dataverse/src/test/java/edu/harvard/iq/dataverse/api/DatasetsIT.java

Line 868 in 98fdfae

.get("/api/admin/settings/" + SettingsServiceBean.Key.DataCaptureModuleUrl.toString());

[pameyer]

some comments from @scolapasta

• logic should move to Settings
• default values should live in SystemConfig
• more descriptive variable names than xs are preferable
• may make sense to keep xhtml changes for QA (even though they're explicitly not intended to be merged).

[pdurbin]

@pameyer it seems like you've got a growing todo list for this issue so I moved it back from Code Review to Development at https://waffle.io/IQSS/dataverse . Please let me know if I can help at all. As I mentioned, I may add the parts that I need to the branch I'm working on for #3725.

[djbrooke]

Closing this out per a discussion in Sprint Planning today. This work will be completed in #3725.

@pameyer @pdurbin please inform me if this is not correct.

[pdurbin]

@djbrooke it's fine. I just attempted to capture the tasks in this issue as part of the definition of done at #3725 in a comment at #3725 (comment) . I hope what I wrote is clear enough.

[pdurbin]

Pull request #3851 was merged so this is done.