Identify chapters that are duplicated in the TOC in move modal UI
Context
Issue #1482 (closed) extends the current "move" functionality of chapter-processed books, however there is one case that has not been handled:
- A book that has parts can have chapters that are repeated in more than one part.
- If users select to move items Above or Below another chapter that is repeated, which part should the moved items be placed in?
Proposal
Include the part title with the duplicated chapter title so that users know which part the items will be moved to. This option would require:
- Showing a result for each chapter that is duplicated
- Including the part title with each result
Design
Acceptance criteria
-
If a User has "Group chapters into parts" toggled on in the chapter-processed Book Settings, when they click on "Move," and enter a term in the "Move" modal, such as "diabetes" for book domain endotext
, then the search results will indicate:-
which of those results are a part if a part via a label tag, and -
if a result is a chapter, what part that chapter is within in the table of contents as a similarly styed label, and -
those labels are not indexed as part of the search results
-
-
If the string text of search results AND their labels are longer than the width of the Move modal, then it will be clear in the design to users the start and end of each result that can be selected to move, based on NCBI user testing with stakeholders -
All other Move and Repeat functionality will behave according to existing supported requirements (e.g, see #211 (closed) for Repeat)
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 by Coko -
All unit / end-to-end tests are written and run by Coko -
QA approved by Coko -
Deployed and tested on “ncbidev” (by Coko team) -
Deployed and tested on “ncbi” (by NCBI team) -
NCBI confirms 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