CDR Tickets

As discussed in that linked ticket, the solution implemented was a path forward to follow the requirements and get the documents published without a release.  For a more appropriate solution I suggest a schema change to add an additional attribute identifying a document to be a "do-not-push-to-Drupal" SVPC or modifying the attribute values of the existing SVPC and/or PartnerMergeSet attributes.  This change would require an additional schema change.

Obviously, a discussion about this change should also include the question on how far we're willing to go in terms of creating band-aids with every new round of SVPC publishing sets in order to create the currently available one-document-partner-output when it doesn't present a mirror image anymore of what's currently presented on Cancer.gov.

Sure. I am OK with making a schema change. Would it require a release?

A new attribute, Do-Not-Push-To-Drupal has been added to the summary schema OCECDR-5251. Thanks!

~oseipokuw , would this change be included in the next Quinn release or is it expected to keep the change outside of a release?

It is expected to be outside of a release. In fact, it looks like we want to get it out ASAP so that the partners get the updated information from the Drupal Pages.

I'm seeing a little bit of a problem here regarding the publishing of the documents.  

It will be possible to make the necessary adjustments to the filters in order to include the "Drupal content" in the partner output.  However, that change is only one half of the equation.  Getting the partner documents published is one part, the other part - for this "Drupal content" approach is to not have the SVPC documents published.  Maybe it's possible to exclude these documents by adjusting the publishing documents which select the documents that need to be published but I can't completely rule out at this point that we won't need additional changes to the publishing software to suppress those documents from being pushed back to Cancer.gov.  This change would require a release.

~oseipokuw , from the description it is not clear if the requested filter changes should be replacing the previous filter changes or if this change is supposed to be yet another publishing path. In other words, will we have only partner documents build with SummaryModuleLinks or will we in addition to those also have the recently published partner documents without SVPC?

It is supposed to be a replacement to the current path. The current path leaves the partner summaries un-updated. The "Drupal" solution is to get the partner summaries updated with the most current live data. So, once this replacement path is available, we wouldn't need the current path.

So, to be clear, you will go back to edit those partner documents we just published without SVPC documents to convert them so that this new filter change will pick those up.  Is that correct?

Yes, I would want to see how labor intensive it is to get the XML directly into the existing partner summaries so that there wouldn't be the need for any changes. I will let you know once I have tried it out.

~volker explained to me that the incentive for creating documents for the individual summaries created as nodes directly in Drupal is because we will in some cases need to include some of those in more than one partner merge document. If that's true, then it seems to me that you should just mark those individual summaries as ModuleOnly.

Bob and I discussed the different approaches and identified that we can go forward with the individual SVPC approach if we mark those documents as ModuleOnly. Those summaries will never be pushed on their own to Cancer.gov.  This approach will not require a release because the publishing software already handles ModuleOnly documents correctly.

In addition, a document that is marked as a SVPC and ModuleOnly will have it's origin in Drupal.  Therefore, the extra attribute to mark these SVPCs won't be necessary.

OK. Thanks! I am glad you thought about the ModuleOnly option (I will update OCECDR-5245 to see if this (ModuleOnly) can be included as part of the XML). The other incentive for having the individual SVPC summaries has to do updates. Updating the individual summaries would be much easier than having to update them in the merged partner summaries.

Thanks! That is good to know.

~volker  So, it looks like we don't need this ticket anymore, right? If that is the case, should I close it?

Based on the latest email from ~duganal we still want to keep Option 4 from the diagram available.  The latest "SVPC filter changes" require for a partner document that's not created from existing SVPC documents to not include top-level SummaryModuleLink elements.  With the new approach of marking Drupal documents pulled into the CDR as ModuleOnly documents we're able to distinguish between these "Drupal SVPCs" and the "CDR SVPCs" and we can update the filter to eliminate the requirement for SummaryModuleLinks.

The ticket that we won't need anymore is the one requesting the new "Do-not-publish-to-Drupal" attribute. That ticket can be closed and the schema changes reverted.

~oseipokuw , it might be a good idea for you to create a sample set of the new documents (SVPC) as those are imported from the Drupal side.

I could just mark a few documents as ModuleOnly to start out with but we wouldn't catch any other special differences that might trip up the filter process.  Also, make sure you either keep in place the Stomach Cancer summary as a PartnerMergeSet without importing SVPCs or you create a new such document, so we still have one test case for this situation.

I created and made publishable all new documents (English and Spanish), and didn't touch the existing Stomach Partner summaries. With the recent refresh on DEV, I think we will have all of them. 

ALL ON DEV"

SVPC 

CDR0000812694
CDR0000812695

CDR0000812696
CDR0000812697

Partner Merge
CDR0000812698
CDR0000812699

~oseipokuw , could you please create these documents also on QA?  I will then run my before/after diff tests on QA.

When you create the partner documents on QA, please make sure not to insert the SummaryModuleLinks inside a SummarySection.  The SummaryModuleLinks should be siblings of a top SummarySection and not children.

These are the test documents on QA. 

Partner
CDR0000812127
CDR0000812128

SVPC
CDR0000812125
CDR0000812126

CDR0000812123
CDR0000812124

I ran a diff report for the vendor output on QA and only one of the documents came out with differences.  This is the summary that was used for testing the new Special Consideration MiscelaneousDocLink.  That will be handled with a different filter change/ticket.

This means we now have 4 slightly different paths for creating partner documents:

• Legacy summary document

• Legacy document marked as PartnerMergeSet (not build by combining SVPCs)

• Partner document build by SVPCs (modules that are published to CG)

• Partner document build by SVPCs (module-only, build in Drupal)

This is ready for review on QA.

I forgot to add the filter names that were modified for this change:

• CDR000157 - Vendor Filter: Summary

• CDR712005 - Denormalization Filter: Summary Module

https://github.com/NCIOCPL/cdr-server/commit/5f47ae7

The filter changes have been copied to STAGE and PROD.

Please verify and close this ticket.

Verified on PROD. Thanks!