CDR Tickets

BZDATETIME::2010-04-19 10:51:30
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::1

Adding attachment. Got a failed to attach error message the first time round.

Attachment RE Bach Status and Error Report for Weekly Publishing.txt has been added with description: Email

BZDATETIME::2010-04-19 12:13:50
BZCOMMENTOR::Volker Englisch
BZCOMMENT::2

It seems that the title of this issue is a little misleading.

There is a message in the 'Status and Error Report' reporting a warning message for some protocols with the information that a publishable version for this document does not exist. When this situation is detected in the filters, the link is being removed in order to avoid a broken link on Cancer.gov.
This is working properly for GlossaryRef elements in Summaries. However, it appears that this message is being reported incorrectly for (at least) some of the protocols because
a) a publishable document does exist and
b) the ProtocolRef link is not being removed
and the link continues to exist and points at least in the cases that I have seen so far to the correct document on Cancer.gov.

What I do have to identify is why this warning of a missing publishable version is being reported when a publishable document does exists.

BZDATETIME::2010-04-19 12:30:02
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::3

(In reply to comment #2)
> It seems that the title of this issue is a little misleading.
Changed the title of this issue.

BZDATETIME::2010-04-19 13:19:32
BZCOMMENTOR::Volker Englisch
BZCOMMENT::4

It appears we all didn't read the warning message carefully.

Kim was reporting the warning message for CDR514350:

• RelatedProtocols (CDR652028)
  Publishable Version of linked Document does not exist.

Even though this message is almost identical to the ProtocolRef warning message

• ProtocolRef (CDR390333)
  Publishable Version of linked Document does not exist.

it is being created at a different stage in the filter process using a different process than the ProtocolRef message.
When we are creating this message for the RelatedProtocols element we're restricting the search for existing, publishable protocols to InScopeProtocols only. Obviously, this doesn't make sense anymore since we've started transferring protocols.
What the warning message is telling us is that a publishable version for the InScopeProtocol document X does not exist. This is a true statement because the protocol X is now a CTGovProtocol, not a InScopeProtocol.

We should be modifying the vendor filters to not only check against existing versions of an InScopeProtocol document but also a CTGovProtocol document.

BZDATETIME::2010-04-26 16:03:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::5

I modified the following vendor filters:
CDR000108 - Denormalization Filter (1/1): InScope Protocol
CDR000150 - Vendor Filter: InScopeProtocol

The filters will now check both, the InScopeProtocol and CTGovProtocol documents and will drop the link for a RelatedProtocol if the corresponding document is blocked and/or no publishable version exists.

This is ready for review on MAHLER.

BZDATETIME::2010-04-26 17:02:57
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::6

(In reply to comment #5)

> This is ready for review on MAHLER.

How do you suggest I test this on Mahler? Will you be able to generate the status and error report (email) from Mahler?

BZDATETIME::2010-04-26 17:15:13
BZCOMMENTOR::Volker Englisch
BZCOMMENT::7

You will want to find or mark up protocols with a RelatedProtocols link to either a new InScope and CTGovProtocol or a blocked one and confirm that the vendor filter process will create the proper warning message for these and suppress the display of the links to the vendor output.

I can run a publishing job or you can run the vendor filters for the marked-up documents.
I will still run the diff report on FRANCK once it has been checked on MAHLER.

BZDATETIME::2010-04-27 12:38:02
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8

I get the warning when I filter documents

For example:

Validation results for CDR637646
Type Document Line Message
Warning 637646 N/A RelatedProtocols (CDR656283)
Publishable Version of CTGovProtocol does not exist.

ProtocolRef (CDR656283)
Publishable Version of linked Document does not exist

BZDATETIME::2010-04-27 12:51:15
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

Perfect! That's what you would expect, right?
The related CTGovProtocol has been removed from the output and the link to the ProtocolRef document has been dropped and just leaving the document ID.

You probably also want to make sure that the links to InScopeProtocols still work the same, in case you haven't done that yet.

BZDATETIME::2010-04-27 13:24:00
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

(In reply to comment #9)
> Perfect! That's what you would expect, right?
> The related CTGovProtocol has been removed from the output and the link to the
> ProtocolRef document has been dropped and just leaving the document ID.
>
> You probably also want to make sure that the links to InScopeProtocols still
> work the same, in case you haven't done that yet.

Right. But what is the implication of this? I guess it means the InScopeProtocol needs to have the RelatedProtocol link fixed manually before it will pass validation?

BZDATETIME::2010-04-27 15:24:02
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

No. The RelatedProtocolLink has been removed so that the document passes validation and that the document isn't creating broken links.
CIAT looks at the report to identify what would need to be updated in order to publish the documents with warnings the next time publishing runs.

Of course, we could have publishing fail for this document if you feel that it's more important not to publish a document if a link is pointing to a non-publishable document rather than publishing the document without the link.

BZDATETIME::2010-04-27 17:04:00
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::12

(In reply to comment #11)
> No. The RelatedProtocolLink has been removed so that the document passes
> validation and that the document isn't creating broken links.
> CIAT looks at the report to identify what would need to be updated in order to
> publish the documents with warnings the next time publishing runs.
>
> Of course, we could have publishing fail for this document if you feel that
> it's more important not to publish a document if a link is pointing to a
> non-publishable document rather than publishing the document without the link.

Thanks for the explanation. Please proceed to run the diff report on Franck and promote to Bach if there are not problems.

BZDATETIME::2010-04-28 17:29:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::13

Attachment Diff_RelatedProtocols.txt has been added with description: Franck diff report

BZDATETIME::2010-04-28 17:30:18
BZCOMMENTOR::Volker Englisch
BZCOMMENT::14

Attachment FilterFailure8193.html has been added with description: FilterFailure output - old version

BZDATETIME::2010-04-28 17:30:45
BZCOMMENTOR::Volker Englisch
BZCOMMENT::15

Attachment FilterFailure8197.html has been added with description: FilterFailure output - new version

BZDATETIME::2010-04-28 17:52:35
BZCOMMENTOR::Volker Englisch
BZCOMMENT::16

There are several changes that can be identified from the diff and failure reports:
a) For about 20 protocols the ProtocolRelatedLink elements have been removed
from the vendor output created with the updated filters.
These are links to unpublishable protocols.
b) Some InScopeProtocols have been dropped from the FilterFailure report.
These are protocols that previously tried to find a publishable
InScopeProtocol causing the entry in the failure report.
Due to the updated filters these warnings are now gone.
c) Most ProtocolRef warnings are now suppressed because we are now checking
against InScope- and CTGovProtocols instead of InScopeProtocols only.

All changes seen in these diff reports are expected.

BZDATETIME::2010-04-28 17:54:31
BZCOMMENTOR::Volker Englisch
BZCOMMENT::17

The following filters have been copied to FRANCK and BACH:
CDR000108 - R9591: Denormalization Filter (1/1): InScope Protocol
CDR000150 - R9591: Vendor Filter: InScopeProtocol

I will verify the vendor output after tonight's publishing job finished.

BZDATETIME::2010-04-29 15:47:25
BZCOMMENTOR::Volker Englisch
BZCOMMENT::18

The Status and Error report looks OK. I've looked at a few of the warnings which represented either InScope- or CTGovProtocols that are blocked at the moment.

We should probably double-check the report that will be created by the next weekly publishing job and then close this issue.

BZDATETIME::2010-05-03 15:25:00
BZCOMMENTOR::Volker Englisch
BZCOMMENT::19

(In reply to comment #18)
> We should probably double-check the report that will be created by the next
> weekly publishing job and then close this issue.

Everything looked good for the weekly publishing job.
Closing issue.