-
Notifications
You must be signed in to change notification settings - Fork 496
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
6558 validate files on publish #6790
Conversation
JH.addMessage(FacesMessage.SEVERITY_ERROR, BundleUtil.getStringFromBundle("dataset.publish.file.validation.error.message"), | ||
BundleUtil.getStringFromBundle("dataset.publish.file.validation.error.contactSupport")); | ||
} | ||
/* and now that we've shown the message to the user - remove the lock? */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we want the admin to intercede here we probably don't want to remove the lock, but should we update the edit data button so that if there is a file validation failure the user cannot add files? We would still allow them to make other edits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe use the file validation failure lock to disable the publish button?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we don't want to remove that lock automatically - that was an idea I was entertaining during the development. I should remove that comment.
As for the second comment - that's exactly what that "failed validation" lock does. It disables the publish button, and will prevent an execution of the publish command, if called via API. But it shouldn't prevent the contributor from making changes. But yes, this should be documented clearly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I missed that the lock disables publish because it's if it's locked for any reason, not just file validation failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way that page is dealing with/checking for various types of locks is a little scary.
Added a quick note to the "dataset management"/"publish dataset" section of the user guide.
for (DataFile dataFile : dataset.getFiles()) { | ||
// TODO: Should we validate all the files in the dataset, or only | ||
// the files that haven't been published previously? | ||
logger.log(Level.FINE, "validating DataFile {0}", dataFile.getId()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be desirable to attempt to validate all of the files before throwing an exception. It would make the admins job easier if they knew more than one file failed validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion. I decided to quit on the first invalid file, so that it's faster. And then I tell the admin in the troubleshooting instruction that they need to verify all the files in the dataset.
I just had this idea: I should probably leave the finalizePublication command as is, stopping on the first file that fails - but then I should provide a one step API for the admin, that will validate all the files in the dataset (using the existing code), and spell out to them which ones need to be fixed - ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, this is done.
…QSS/dataverse into 6558-validate-files-on-publish
…ve failed validation, that need to be fixed or removed before the dataset can be published. (#6558)
... from the troubleshooting guide; also moved around the diag. API and the example sections.
@landreev |
OK, will investigate and fix. |
@kcondon
So does the dataset get published or not, w/ develop branch on dvn-build? (not 100 %sure how to read "same scenario" - so checking...) |
@landreev Yes, develop works |
…t's modified during the first stage of the async publishing. #6558.
Checked in fixes, should be ready to re-test. |
It was really "preexisting", in that apparently it wasn't documented at all. I added that mention of it, to both the file reg. and the validation options sections. I wasn't sure it needed its own section, but sure, I just added its own paragraph. |
There's one more thing - whether we want to validate every file, every time, where I was soliciting opinions on how to handle it. I'm leaning towards skipping it for minor versions; but validating every file, new and old on every major version. But this hasn't been implemented yet. |
OK, this has been checked in as well. |
What this PR does / why we need it:
See the issue; and the release note: https://github.com/IQSS/dataverse/blob/6558-validate-files-on-publish/doc/release-notes/6558-validate-files-on-publish.md
Which issue(s) this PR closes:
Closes #6558
Special notes for your reviewer:
Suggestions on how to test this:
Create a dataset, upload some files, mess up one of the files in the dataset directory or in the S3 bucket... try to publish.
Try it with both the synchronous and asynchronous ("too many files") publishing modes.
Does this PR introduce a user interface change?:
There is a new UI error message notifying the user about the failure to publish, explaining to them that some of their files do not pass validation, and telling them that they must contact support in order to fix it, before they can make another attempt to publish.
It uses the standard "red" error banner system at the top of the page.
Is there a release notes update needed for this change?:
yes, above.
Additional documentation: