CDR Tickets

It appears the same problem affects the use of the gene tags as well. They are displayed in QC reports but not PP and Cancer.gov.

It is correct that none of the markup in KeyPoints is preserved. It may be a bug - which is easy to fix - or it may be deliberate because the Gatekeeper processing also doesn't preserve any markup for KeyPoints.

~volker: I have avoided moving any of the tickets marked "WCMS Dependencies" into Gauss. Can you go through these tickets and provide links to WCMS tickets on which they depend, or group together into a single Sprint those which can be deployed in a single release/patch, or some combination of these. As it is, there's no indication that our tickets aren't just floating out in the void, without a connection to a process which will ensure that they get taken care of.

Thanks!

The markup is submitted to the Gatekeeper but the GK code drops it.

There is nothing that needs to be done on the CDR side of things. I've submitted a GK Jira ticket.

I'm not sure I understand the motivation for putting this in Gauss. I can see incentives for (a) closing this ticket, since there's nothing for us to do on the CDR side; or (b) keeping it open (so we can maintain the awareness of the problem) and moving it to the WCMS Dependencies block. But I think of Gauss as containing the issues for which we will release solutions all bundled together on a certain date, and since we have little or no control over when the next Gatekeeper release will be, this wouldn't seem to be a good match for Gauss. I sort of lean toward (b). Convince me otherwise. :-)

The changes on the GK side don't require an actual release build. The change necessary is in a single XSL file that I have full control over. Once I've made the change and it has been tested all we have to do is to add one step to the instructions for CBIIT:

• Copy XSL file to E:\Content\Gatekeeper\XSL

Convinced?

Yes, that makes sense. Thanks!

~oseipokuw, I'm trying to find examples of this problem but following your example (CDR256657) I do see the emphasis properly displayed in the KeyPoint headers on Cancer.gov as well as the PP and the QC reports.

Is this still an issue?

~volker: please assign story points for this ticket.

~oseipokuw: did you see Volker's question above (from last September)?

~duganal, based on the comments to this ticket there is a WCMS dependency that can be fixed via XSLT filter changes. I would need to talk to ~learnb to find out if there are any limitations imposed by Percussion not to include HTML markup in KeyPoint titles.

By the time the summary gets to Percussion, KeyPoints are just part of the page body. The entire page body is HTML, so that shouldn't be a problem.

I'm not up to date on how KeyPoints are handled in GateKeeper, but from a quick search of the code, it looks like only XSL is involved.

This has been updated in the WCMS ticket and is ready for review on DEV.

Verified on QA. Thanks!

The key points are displaying in all caps for me on QA. I'll post a screenshot. I'm not sure if this is a result of the current PP work-around Volker described in OCECDR-4449. Are you seeing this too ~oseipokuw?

Yes, it appears to be a result of the CSS on the DT Gatekeeper. I did not know there are these type of differences between the servers but the CSS on DT is converting key-points to uppercase.

Yes, I see the same thing. It looks like Volker confirmed that it is affected by OCECDR-4449.

I've reprocessed the Spanish version of Delirium on Cancer.gov:
https://www.cancer.gov/espanol/cancer/tratamiento/efectos-secundarios/memoria/delirium-pdq

Please verify that the markup is showing for the keypoint sections and close this ticket.

Please note, for any summary currently with markup (which isn't showing) the document will either need to be reprocessed on GK or we'll have to re-submit a re-publish job from the CDR. For all documents with new markup, the markup will show automatically going forward.

Verified. Thanks!