CDR Tickets

Since we don't have Spanish drug info summaries wouldn't it be sufficient to just suppress the element from Spanish glossary terms or should it be made clear that the link goes to a document in English?

That should work. But using the attribute will potentially make it possible to re-use the element in the future.

~volker: please assign story points for this ticket.

It appears that the GK code is assuming to add the link to both languages if the UseWith attribute doesn't exist. That's the default for the RelatedSummaryRef but that default shouldn't be applied for this RelatedDrugSummaryLink.
It may be easiest to add the UseWith="en" attribute for all drug summary links.

We need to identify if the post processing filters may need to be modified as well.

In order to test my suggested approach we will need to update the DTD that is used by Gatekeeper.

Oops! I forgot that the DTD change is release dependent, so I'll have to move the ticket back into hawking.

The following items need to be modified:

• CDR616048: Vendor Filter: GlossaryTermName

• pdqCG.dtd

• pdq.dtd, if we'll include the new attribute "UseWith = 'en'" in the PDQ Partner XML output

• GK DTD

• GK GlossaryTerm XSL

I've tested this approach successfully on DEV using ~oseipokuw's example and discussed the approach with Blair.

Adding ~duganal and ~bennettcc to this ticket since it requires coordination with the WCMS team.

Also, this change will require all GlossaryTerms with RelatedDrugSummary elements to be reprocessed.

The following files have been updated:

• pdq.dtd [hawking fd28d79]

• pdqCG.dtd [hawking fd28d79]

• CDR0000616048.xml [hawking b4bdf7ac]

• GK: pdq.dtd [hawking 3603231]

• GK: GlossaryTerm.xsl [hawking 3603231]

The GlossaryTerms have been reprocessed on DEV for testing. There were 580 changes (on www-blue-dev.cancer.gov).

This is ready for review on DEV.

~volker: You know that the git commit identifiers are only unique within a repository, and that the branch isn't necessary to identify the commit, right? In other words, you might want to replace the branch name with the repo name.

You know that the git commit identifiers are only unique within a repository

I do now. :-)

The addition of the [branch hash] information is more for myself than anybody else. If I'm making changes on multiple release-independent tickets it serves as a link between the ticket and branch and as long as our file names are unique across the CDR repositories I won't have a problem finding my updates.

... as long as our file names are unique across the CDR repositories ...

Well, that's true a lot of the time, but not always. Try {{find my-repos name publishing.py}} for example. :)

Still true for me:

$ find . -name publishing.py
./admin/Inetpub/wwwroot/cgi-bin/cdr/publishing.py

You don't have all the repositories then.

$ find . -name publishing.py
./lib/Python/cdrapi/publishing.py
./admin/Inetpub/wwwroot/cgi-bin/cdr/publishing.py

Here's a more comprehensive list. :-)

./client/XMetaL/Template/Cdr/ClinicalTrialSearchString.xml
./server/Schemas/ClinicalTrialSearchString.xml
./client/XMetaL/Template/Cdr/GlossaryTermConcept.xml
./server/Schemas/GlossaryTermConcept.xml
./client/XMetaL/Template/Cdr/GlossaryTermName.xml
./server/Schemas/GlossaryTermName.xml
./client/XMetaL/Template/Cdr/InScopeProtocol.xml
./server/Schemas/InScopeProtocol.xml
./client/XMetaL/Template/Cdr/Licensee.xml
./server/Schemas/Licensee.xml
./client/XMetaL/DLL/Makefile
./client/XMetaL/CdrClient/Makefile
./client/XMetaL/Tools/Makefile
./client/XMetaL/Template/Cdr/Media.xml
./server/Schemas/Media.xml
./client/XMetaL/Template/Cdr/OutOfScopeProtocol.xml
./server/Schemas/OutOfScopeProtocol.xml
./client/XMetaL/Template/Cdr/PDQBoardMemberInfo.xml
./server/Schemas/PDQBoardMemberInfo.xml
./lib/Python/cdrapi/README.md
./tools/DevTools/Utilities/README.md
./tools/Build/README.md
./client/XMetaL/Template/Cdr/ScientificProtocolInfo.xml
./server/Schemas/ScientificProtocolInfo.xml
./client/XMetaL/Template/Cdr/SupplementaryInfo.xml
./server/Schemas/SupplementaryInfo.xml
./client/XMetaL/Template/Cdr/TermSet.xml
./server/Schemas/TermSet.xml
./lib/Python/cdrapi/__init__.py
./scheduler/__init__.py
./scheduler/util/__init__.py
./scheduler/jobs/__init__.py
./scheduler/tasks/__init__.py
./scheduler/core/__init__.py
./scheduler/core/datastore/__init__.py
./scheduler/core/datastore/providers/__init__.py
./admin/Inetpub/wwwroot/cgi-bin/cdr/check-cdr-tier-settings.py
./publishing/gpmailers/cgi-bin/check-cdr-tier-settings.py
./client/XMetaL/DLL/ReleaseUMinDependency/Cdr.tlog/cl.command.1.tlog
./client/XMetaL/CdrClient/Release/CdrClient.tlog/cl.command.1.tlog
./admin/Inetpub/wwwroot/cgi-bin/cdr/fetch-tier-settings.py
./publishing/gpmailers/cgi-bin/fetch-tier-settings.py
./admin/Inetpub/wwwroot/cgi-bin/scheduler/static/js/views/logs/filter-view.js
./admin/Inetpub/wwwroot/cgi-bin/scheduler/static/js/views/executions/filter-view.js
./admin/Inetpub/wwwroot/cgi-bin/cdr/log-tail.py
./publishing/gpmailers/cgi-bin/log-tail.py
./lib/Python/cdrapi/publishing.py
./admin/Inetpub/wwwroot/cgi-bin/cdr/publishing.py
./client/XMetaL/DLL/resource.h
./client/XMetaL/CdrClient/resource.h
./client/XMetaL/Icons/Cdr/row1.bmp
./client/XMetaL/Icons/Cdr2/row1.bmp
./client/XMetaL/Icons/Cdr/row2.bmp
./client/XMetaL/Icons/Cdr2/row2.bmp
./client/XMetaL/Icons/Cdr/row3.bmp
./client/XMetaL/Icons/Cdr2/row3.bmp
./lib/Python/test/run-tests.py
./server/Filters/test/run-tests.py
./lib/Python/cdrapi/settings.py
./scheduler/settings.py
./admin/Inetpub/wwwroot/cgi-bin/scheduler/static/js/views/jobs/stats-view.js
./admin/Inetpub/wwwroot/cgi-bin/scheduler/static/js/views/executions/stats-view.js
./admin/Inetpub/wwwroot/cgi-bin/scheduler/static/js/views/jobs/table-view.js
./admin/Inetpub/wwwroot/cgi-bin/scheduler/static/js/views/logs/table-view.js
./admin/Inetpub/wwwroot/cgi-bin/scheduler/static/js/views/executions/table-view.js
./admin/Inetpub/wwwroot/web.config
./admin/Inetpub/wwwroot/cgi-bin/secure/web.config
./glossifier/cgi-bin/web.config
./server/api/web.config

~duganal, this ticket has a WCMS dependency that's purely a XSLT filter change. No Blair-time needed.

Verified on QA. Thanks!

~volker It appears related drug info summaries are now being suppressed for some set of English glossary terms.

For example, abiraterone acetate (CDRID 641969).

This can presently be seen on the DT environment at:
https://www-dt-qa.cancer.gov/publications/dictionaries/cancer-terms/def/abiraterone-acetate

vs. production:
https://www.cancer.gov/publications/dictionaries/cancer-terms/def/abiraterone-acetate

That's not good. Let me take a look at the data.

As discussed, the problem was that the glossaries had been reprocessed on Gatekeeper using an existing data set which did not include the new "UseWith='en'" attribute.

We updated the DTD and pushed a new data set from the CDR. The links are now restored on the English terms.

Verified. Thanks!