IQSS-4778 generate DOIs only for published files

[qqmyers]

New Contributors

Welcome! New contributors should at least glance at CONTRIBUTING.md, especially the section on pull requests where we encourage you to reach out to other developers before you start coding. Also, please note that we measure code coverage and prefer you write unit tests. Pull requests can still be reviewed without tests or completion of the checklist outlined below. Thanks!

Related Issues

• connects to The /registerDataFileAll API endpoint generates DOIs for all files including those in draft/unpublished datasets #4778 : The /registerDataFileAll API endpoint generates DOIs for all files including those in draft/unpublished datasets

Pull Request Checklist

• Unit tests completed
• Integration tests: None
• Deployment requirements, SQL updates, Solr updates, etc.: None
• Documentation completed
• Merged latest from "develop" branch and resolved conflicts

[coveralls]

Coverage decreased (-0.001%) to 13.236% when pulling 2f7b0ae on QualitativeDataRepository:4778-registerDataFileAll_for_published_files_only into 51e67e6 on IQSS:develop.

[pdurbin]

Please see comments inline.

[pdurbin]

I just spoke with @sekmiller about adding the check for isReleased and we agree that it's more consistent how new datasets are created and published. I'm sort of wondering why there was a change to findUserOrDie. Also, should these changes be made to the registerDataFile method above as well?

[qqmyers]

@pdurbin - Sorry - the findAuthenticatedUser is a separate issue (which I meant to remove from this pull). Since I didn't - let me explain:

findUserOrDie appears to first check the submitted key to see if it from a privateUrl and then call findAuthenticatedUserOrDie (and if there's no key, it returns the guest user). Since a privateUrl wouldn't work for multiple datasets and a guest user would also not be allowed, it seemed that calling findAuthenticatedUserOrDie() directly would be better. I have not checked to see what happens with the original code if no key is sent or a privateURL is used - I assume permissions gets checked somewhere along the way - but it seemed simpler to just reject early if a valid superuser apikey was not available.

I think the same change could/should be made to registerDataFile, unless using a privateUrl was intended to be OK there.

Feel free to edit directly or let me know and I can remove/add it to registerDataFile...

[pdurbin]

@qqmyers thanks, I haven't been very close to this part of the code so I'm fine with others weighing in on whether the pull request needs more work or not.

[kcondon]

@qqmyers Do you mind refreshing from /develop? We've recently updated the version of the war file. Thanks!

[pdurbin]

@kcondon done (by @qqmyers ) in abfe0fd

[kcondon]

@qqmyers thanks for updating. I've tested it and it works as described but do you mind making a tweak to the logging on start and end counts?

For example, I have 7 files that are unregistered: 3 published, 3 unpublished, 1 harvested. You correctly register the published ones and leave the others alone. However, the start count and end count messages are a bit confusing:

[2018-07-02T13:56:18.775-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid:
_ThreadID=34 _ThreadName=http-listener-1(5)] [timeMillis: 1530554178775] [levelValue: 800] [[
Starting to register 7 files. Mon Jul 02 13:56:18 EDT 2018]]
[2018-07-02T13:56:23.912-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=34 _ThreadName=http-listener-1(5)] [timeMillis: 1530554183912] [levelValue: 800] [[
4 of 7 files were already registered. Mon Jul 02 13:56:23 EDT 2018]]
[2018-07-02T13:56:23.912-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.api.Admin] [tid: _ThreadID=34 _ThreadName=http-listener-1(5)] [timeMillis: 1530554183912] [levelValue: 800] [[
3 of 7 files registered successfully. Mon Jul 02 13:56:23 EDT 2018]]

It's up to you but perhaps it could say:
7 files are unregistered. Only unregistered, published files will be registered.

and then ending it could day:
4 of 7 files registration was not attempted.
3 of 7 files registered successfully.

[qqmyers]

Sure - I'll take a look.

[qqmyers]

@kcondon - see what you think. Since the # of unregistered, published files is unknown to start (unless we loop through all of them to count), the incremental counts are out of the overall total, but I'm logging all three (already registered, not yet published, and to register) as they are processed and then report all three categories at the end, along with the # of successes out of the # that should have been registered.

[kcondon]

OK will check it out. Thanks!

[kcondon]

That looks great, thanks!