| Issue Number | 4676 |
|---|---|
| Summary | [Summaries] Internal summary links not working for new docs |
| Created | 2019-10-22 15:40:42 |
| Issue Type | Improvement |
| Submitted By | Osei-Poku, William (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2020-05-13 14:50:06 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.251383 |
Internal summary fragment links are not working for new summaries that have not been made publishable. Users have to remove all internal links first, make the document publishable and then go back into the document to add all the links back and then make the document publishable again. Could you please look into this as quickly as you can?
Are you referring to the PP report or QC report or are you saying the user is unable to save a document with internal fragment refs?
This is in XMetal only. You would get a validation error message when you try to create a publishable version because you are linking to a document that does not have a publishable version but the document happens to be the same document you're creating the link to (that is internal refs within the same document that has not been made publishable).
I'm guessing this is not a new bug but it has always worked this way, correct?
but the document happens to be the same document you're creating the link to (that is internal refs within the same document
There is no such thing as an internal link. You know that this is an internal link but the software does not. This is a SummaryFragmentRef which gets checked by the validation process. Yes, it is a catch-22: You want to create a (first) publishable version of the document but the links are preventing you because they are required to point to a publishable version. We've solved a similar case with the PP report where the links used to open a new PP-report for the same document. We've implemented a post-process to make these links work as internal links.
Let's discuss this issue during our Thursday meeting and identify how big of a problem this is and what would be the Pros and Cons of changing the behavior.
As a work-around, you probably know that you don't have to remove the links in order to create a publishable version. It's probably faster to insert the Comment tags around such a link (Insert --> Comment) and remove those after the publishable version has been created.
~oseipokuw I think Volker's question from October 24 has fallen through the cracks.
I'm guessing this is not a new bug but it has always worked this way, correct?
Also, can you give me an example of the condition in a summary document on DEV?
I created a sample document on DEV: CDR799644. This document doesn't have a publishable version and contains a SummaryFragmentRef. If you're trying to validate it (link validation) you'll get an error message due to the link.
I'm guessing this is not a new bug but it has always worked this way, correct?
but the document happens to be the same document you're creating the link to (that is internal refs within the same document
~bkline This is a recent problem. It started happened right around Oct, 2019.
I have modified the link validation software to bypass the check for a (publishable) version of the link target if the source and target are the same document. Modification installed on DEV.
Verified on DEV. Thanks!
Verified on QA. Thanks!
This may be another ticket for which opportunities to test don't present themselves for a while, in which case we may want to close this ticket, opening fresh tickets for problems we run into in the future.
Elapsed: 0:00:00.001927