Support book versioning to support changes in workflow
Context
In original NCBI specifications the ability to change workflow type of a book by System Admin was required because this happens frequently in Bookshelf production.
Proposal
Support users to create a new version in order to change the processing workflow. The complication here is that this use case does not constitute a new scientific record (published version) so it would not be correct to change either the content type
(version name) or version number
. For example, the following would be valid in this use case:
book version 1:
- conversion workflow: PDF
- content type: final-full-text
- version number: V1
- flag: locked
book version 2:
- conversion workflow: XML
- content type: final-full-text
- version number: V1
- flag: current
workflow only change
Change from | Change to |
---|---|
XML | |
XML | Word |
XML | |
Word | |
Word | XML |
Word |
There is no difference in complexity between the possible conversion workflow options, if the processing type remains the same.
Minimal workflow for Option 1
- User publishes OR locks the current book version
- User chooses to create a new version
- User chooses the workflow type for the new version
- BCMS shows confirmation that previous versions will be locked (because of the conversion workflow change)
- User confirms decision
- new book version is created
- previous version is locked
- user is redirected to the new version
- User uploads the relevant files to new version (i.e. the BCMS does not attempt to match files from the previous version to the current one)
Caveats
- On initial review we don't see a technical issue for books created in the BCMS, however since repeating
content type
andversion number
across BCMS book versions is a departure from the original scope, there may be implications we're not thinking of now. We're adding 2 days for code review and scope sign-off. - The updated request above (option 1) asks the BCMS to accommodate a scenario that results in two book versions with the same
book-submit-id
+version-name
+version-number
. Therefore the current FTP spec would need to be reconsidered if NCBI plans to introduce FTP support at a later date. Since we also have theworkflow
information in the meta.xml file, a reasonable solution is to addworkflow
as a require value to match book versions. This is the best proposal we can give at this time and it would need to be validated by Coko and NCBI at the start of the project. As an integration point, this spec change requires input from NCBI and Coko teams. - We think it would be confusing to users to see two versions in the BCMS with the same name. Ideally we should hide all locked versions from all users except Sys Amins. This is not included in this estimate.
Design
Pending
Acceptance criteria
-
System Admin can delete or lock a Book Version in any one Workflow and create a new Workflow Book Version in a different Workflow as long as the processing type remains the same -
When System Admin successfully modifies the Workflow Type for a Book by creating a new Workflow Book Version, then the Files UI will appear according to the specifications correctly for each Workflow Book Version type, AND -
Users can only download files in the Locked Workflow versions
-
-
When System Admin successfully modifies the Workflow Type for a Book by creating a new Workflow Book Version, THEN -
The Locked Workflow version can no longer be Submitted, Reload to Preview, or Published -
The new Workflow version will Convert according to the new Workflow Type Processing Integration specifications
-
Definition of ready
-
BCMS User Story / Context has been well defined -
The priority of the user story is specified and agreed -
Digital assets added (design, database scheme, mockups etc if relevant) -
Coko Technical Proposal approved by NCBI -
Testable Acceptance Criteria approved by NCBI -
Estimate of effort to complete (time or points) -
The issue has been broken down into development tasks (if necessary) -
Requirements Clarified -
The product owner and development team agree that the user story is ready for development -
NCBI adds “Dev_Ready”
Definition of done
-
All coding tasks are finished and implemented -
QA approved -
Deployed and tested on “ncbidev” (by Coko team) -
Deployed and tested on “ncbi” (by NCBI team) -
Acceptance Criteria Met
Implementation
Alternative approaches (if applicable)
Scheduling
-
Milestone is linked -
Iteration is linked -
Dependencies: ("None" or list issue numbers if relevant) -
Development estimate is added to issue time tracking