@lathrops1 @DioneMentis - cc @rorris
Bookshelf can load all chapter-processed TOCs and expect them to display as they currently do with complete metadata.
We should always show the chapter label on the TOC, regardless of the ordering setting applied to the book 2) we should fetch chapter publishing metadata from <pub-date>
and tag as necessary to render on NCBI web pages (see specifications below)
Chapter dates are not tagged in the TOC xml for <pub-date>
as necessary for rendering on Bookshelf web pages.
Chapter labels are not present in the TOC xml, when the chapter ordering setting applied to the book is not order by: Chapter Number descending
[Provide browser name and version and if you're working from a PC or Mac]
Chapter Labels
Final Rendered TOC Example: https://www.ncbi.nlm.nih.gov/books/NBK425793/
Sample converted chapter XML file:
Ordering spec
XML element used to order content and target to write in TOC.XML
Syntax - {string_name} {Arabic number} where {string_name} is case insensitive and can be more than one word in string AND {Arabic number} may or may not be preceded by a # symbol
Note: the text or symbols preceding the number should not have to be specified.
Example:
<label>STATISTICAL BRIEF #542</label>
Target to write in TOC.XML is complete label in converted XML - see example:
<toc-entry>
<label>STATISTICAL BRIEF #541</label>
<title>Any Use and &#x201C;Frequent Use&#x201D; of Opioids among Elderly Adults in 2018&#x2013;2019, by Socioeconomic Characteristics</title>
Pub Date
There is a PI for epub, but it needs to be written as to display.
Per Martin when investigating, NCBI expects 'date-e/ppub' to render these dates.
Y, for deployment
[To be completed by Coko once dev is done]
[Provide a general summary of the issue in the title above]
[Tell us what should happen. Link to the developed feature issue that describles the expected behaviour if possible]
when search for a collection by pmcid/domain name there are no results, only get the result if search for the partial id up to the last digit
127.0.0.2_3390_-_Remote_Desktop_Connection_2022-08-19_13-43-41
[Provide browser name and version and if you're working from a PC or Mac]
[Not required. Suggest a fix for the bug]
[Select "Y" or "N" and provide an explanation]
[To be completed by Coko once dev is done]
User should not be able to trigger TOC publication while the TOC is in active status publishing
user can trigger a TOC publication and immediately trigger it again. it creates a Task manager session for each ocurrence
127.0.0.2_3390_-_Remote_Desktop_Connection_2022-08-19_12-28-12
[Provide browser name and version and if you're working from a PC or Mac]
Make sure page is refresh as per #1382, so that statuses and actions available are up to date.
[Select "Y" or "N" and provide an explanation]
Update published version
button is disabled until the collection TOC is published[Tell us what should happen. Link to the developed feature issue that describles the expected behaviour if possible]
When try to upload a converted file, get error "the converted file you uploaded is not correct"
127.0.0.2_3390_-_Remote_Desktop_Connection_2022-08-12_11-02-16
Y, for MVP deployment
[Tell us what should happen. Link to the developed feature issue that describles the expected behaviour if possible]
ampersand character in copyright statment in book-meta modal causes invalid xml
[Provide browser name and version and if you're working from a PC or Mac]
[Not required. Suggest a fix for the bug]
[Select "Y" or "N" and provide an explanation]
"© 2018 by Taylor & Francis Group, LLC"
All links require a http/https prefix or pure doi value, but collections don't provide these validations
collection fields do not have the same validation as book fields for “Publisher URL” & “Self-citation URL” . In book settings user gets error message if the entry is not - urls starting with http/https or “doi”
also minor note, the header text for this field is differnt, “Self-citation URL” vs "citation self url"
? - these are also domain attributes so we can run scripted reports on our NCBI backend to find any errors that come up before it is fixed to cleanup
Users want support files when conversions fail to troubleshoot
Word conversion files are not in the support section of the BCMS when conversion fails – the files only show when conversion was successful
[Provide browser name and version and if you're working from a PC or Mac]
[Not required. Suggest a fix for the bug]
[To be completed by Coko once dev is done]
Navigation does not loop
If i navigate to a collection then click the "<-back to xxx" button in the bcms (not the browser button) it takes me back to the org page (which I expected), then if i click the "<-back" again it takes me to the same collection, and then it’s just a loop (see video)
---- vs If click “<-back” from a book that has no collection, it takes you back to the org, and then the back button disappears
---- additionally having this back button in the org replaces the org name, which means that when I’m on the org dashboard, there’s no way to know WHERE i am… this is not the case when there is no collection
• When navigate from collection to org • vs when navigate from book (without collection) to org
127.0.0.2_3390_-_Remote_Desktop_Connection_2022-08-02_14-02-58_Trim
Does not affect content or migration - this can wait until after deployment
We need to remove back button on the collection dashboard. If user wants to go back they can user browser back button. The reason for this is to show the Org name and to prevent a loop.
Further changes here won't affect URLs.
Settings URL fields allow spaces in the URL - "Publisher URL" ; "Citation Self URL" ; "Self-citation URL" ; "Special Publisher Link URL"
URLs should be valid
User can enter invalid URLS
https://ncbi.cloud68.co/organizations/ada36b4e-2d30-42d5-b8a6-3f754fc43342/bookmanager/126a0fec-ba30-4241-9574-7779f48d870c
These are domain attributes - we can run report post-deployment to see if there are any invalid URLs and do cleanup. We can't wait long after deployment for this fix to make manual cleanup too difficult.
[To be completed by Coko once dev is done]
PC - chrome
This is cosmetic - can wait until have a series of milestones to improve display and transparency of transaction history, etc
[To be completed by Coko once dev is done]
hi @ChristinaTromp I tested this for the 3 cases in the QA instructions :
For "book template" and "collection templates" the blank value is not retained, which leads to errors when the user tries to edit another setting. see attached video. 127.0.0.2_3390_-_Remote_Desktop_Connection_2022-08-02_12-30-18
Display heading level & Expand heading level book setting fields should support all values in our PMCBook Domain attribute fields so that we don't break rendering for legacy content we are migrating to the new CMS.
Based on current domain tool data, we should at least support
Display heading level |
---|
99 |
1 |
2 |
3 |
5 |
1:nojava |
2:nojava |
3:nojava |
<blank> |
Expand heading level |
---|
1 |
2 |
<blank> |
Display heading level - only allows digits (up to "4") & is a required field that does not allow blanks
Expand heading level - is a required field that does not allow blanks
Display heading level |
---|
1 |
2 |
3 |
4 |
5 |
99 |
1:nojava |
2:nojava |
3:nojava |
<blank> |
Note when the user selects <blank>
in the dropdown, the value should be saved as empty and therefore sent to NCBI empty, not as the string <blank>
.
Note that the domain default appears to be 4, so that can remain the default value, which the user can change via the dropdown.
Expand heading level |
---|
1 |
2 |
3 |
4 |
<blank> |
Note when the user selects <blank>
in the dropdown, the value should be saved as empty and therefore sent to NCBI empty, not as the string <blank>
.
Note that the domain default appears to be 4, so that can remain the default value, which the user can change via the dropdown.
This breaks our migration scripts so is required for deployment
<blank>
.<blank>
.@ChristinaTromp - I am able to save without an error in "citation URL" and "Special Publisher Link URL" fields a text string that begins with "doi", e.g "doiabcs". The string should be limited to exactly "doi"
Hi Evgeny,
We converted a word document AND it is breaking conversion and stopping the pipeline. This one document fails every time and clogs the pipeline.
books_extyles_convert
step since then, it seems to have created an error but did NOT fail the TM session.Failed: Timeout
at 2022-06-23 11:25can switch between chapter published versions
when in CHAPTER version V2, if click V1 the screen turns blank and cannot refresh - have to click back on browser or change url to main site to be able to get back to bcms
127.0.0.2_3390_-_Remote_Desktop_Connection_2022-06-24_10-42-53
in Word book Chapter
@lathrops1 enter
[To be completed by Coko once dev is done]
Display heading level & Expand heading level book setting fields should support all values in our PMCBook Domain attribute fields so that we don't break rendering for legacy content we are migrating to the new CMS.
Based on current domain tool data, we should at least support
Display heading level |
---|
99 |
1 |
2 |
3 |
5 |
1:nojava |
2:nojava |
3:nojava |
<blank> |
Expand heading level |
---|
1 |
2 |
<blank> |
Display heading level - only allows digits (up to "4") & is a required field that does not allow blanks
Expand heading level - is a required field that does not allow blanks
Display heading level |
---|
1 |
2 |
3 |
4 |
5 |
99 |
1:nojava |
2:nojava |
3:nojava |
<blank> |
Note when the user selects <blank>
in the dropdown, the value should be saved as empty and therefore sent to NCBI empty, not as the string <blank>
.
Note that the domain default appears to be 4, so that can remain the default value, which the user can change via the dropdown.
Expand heading level |
---|
1 |
2 |
3 |
4 |
<blank> |
Note when the user selects <blank>
in the dropdown, the value should be saved as empty and therefore sent to NCBI empty, not as the string <blank>
.
Note that the domain default appears to be 4, so that can remain the default value, which the user can change via the dropdown.
This breaks our migration scripts so is required for deployment
<blank>
.<blank>
.The videos documented that we are getting false positive agreement check errors for collection and chapter-processed TOCs even though they are linked to an agreement
on the NCBI-managed migration dev site - seeing errors when trying to publish the TOC for collections.
"Agreements Check 1 - An Error occurred failed"
127.0.0.2_3390_-_Remote_Desktop_Connection_2022-05-25_19-26-52
as shown in beginning of video, collection is linked to agreement in ncbi publisher portal
@lathrops1 add
[To be completed by Coko once dev is done]
[Tell us what should happen. Link to the developed feature issue that describles the expected behaviour if possible]
chapter based book meta allows non-digits in publication history month field
Looks like this fix was made and in QA
Going to say needed for deployment - but if we'd get a loading error for this use case, it could wait