API now has a "document store" class bean #65
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… and justifications, change config property to 'document-store.root', works but needs to be able to copy files on proposal clone.
…hs to the correct location in the store, change config property name to document-store.proposals.root
… of file extension strings is empty or null
AllanEngland
deleted the
63-java-class-or-classes-needed-for-document-store
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have created a "ProposalDocumentStore" class bean. This can create the necessary store path locations, save and delete files, write a string to a file, list files in a given directory, and copy one directory to another. This is used internally only i.e., there is no client exposure.
Using this new class, the API can now copy the supporting document and justification files when cloning a proposal.
Noticed that I have changed the 'uploadSupportingDocument' implementation such that it either adds a new supporting document OR it overwrites an existing file if the file-upload filename matches an existing file in the Store. This was prompted by the need to simplify the location where the supporting document files are stored that in turn made the cloning of proposals easier. Instead of saving supporting document files to individual subdirectories using their DB id, they are more simply stored directly in the "supportingDocuments" subdirectory of the store. As a consequence, the "replace" supporting document api call is now obsolete so I have removed it.