CDR Tickets

One possibility is to use an "external link" icon. 

I thought the external link icon gets created automatically by C.gov for all non-.gov sites.

We need to find out what changes need to be made to the ElasticSearch structures for the glossary.

We will hold off on deployment to production until all of the sites have been identified and mapped.

William will provide a list of the sites, with identifying URL portion, attribute token, and display text for each site.

It looks like this is the list of domains currently used:

• espanol.cdc.gov

• ghr.nlm.nih.gov

• medlineplus.gov

• rarediseases.info.nih.gov

• www.cancer.gov

• www.coronavirus.gov

• www.genome.gov

• www.hhs.gov

I created a sample of - what Margaret calls - a good solution (as opposed to the perfect solution) which would not need any changes besides the global to add the extra text to the external links:

Thanks for the list Volker! We will remove some of the URLs like hhs.gov and ghr.nlm.nih.gov (which is really an older URL) because they are not commonly used. There may be one or more terms linked to them so we can handle them manually. I will update on what finally decide on those.

More Information Links.xlsx

I have attached the draft spreadsheet containing the URLs and descriptions. I added two columns that contain sample links to the content we are linking to. The sample links contain more than just the base URL. I also added another column (UseWith) which is the attribute to indicate the language the more information link is created for in the concept document.  

We may have to use a combination of the information from the SourceKey and UseWith to come up with the list of values so that each one will be unique.

Were you going to capture the details of the requirements for the interim solution you decided to have implemented, ~oseipokuw?

I think we need to discuss this again in the CDR meeting so that we are all on the same page on what we need to do next as I am not sure if we decided to hold off on implementing the desired solution of having the text in parenthesis not being linkable (just plain text) or in the interim, having the text linkable until later when we can implement the plain text in parenthesis solution.

It looks like we decided to go with Option 2:

2. Add a new optional attribute to the related external ref element with a list of values. The value selected for each link will indicate which web site name from the list above is displayed in the CDR and on cancer.gov.

I will create a new ticket for the schema change so that we can track only the global change in this ticket. I will provide additional information for the global.

More Information Links_DEC16_2021.xlsx

I have attached an updated spreadsheet (added a new column - BASE URL). So, for the global I will suggest that the program looks for links in the GTCs that match the provided links in the BASE URL column. If they match up to the base URL, then assign the corresponding SourceKey from the SourceKey (values) column and also append the corresponding description (in parentheses)  from the DESCRIPTION column to the information in the Related External Ref element.

I guess I was confused looking at your last two comments, because option #2 only talks about adding the new attribute and having the global change populate it, not about also having the global change also add the parenthetical description to the element's text as well. If the global is going to actually do the modification of the text content stored in the element (rather than having that happen in the publishing filter) what is the purpose of the value in the new attribute?

It is for the reason that users want to see the descriptions in the CDR as stated in the initial request. Also, as I suggested in the initial request, perhaps a combination of having the global modify the text content as well as having the filters use the new values to send the descriptions to cancer.gov is the way to proceed. It will be redundant and it is possible that the information in the text content may not match exactly what is on the website  but I don't think that is a problem since the most accurate information will be available on the website. Alternatively instead of modifying the text content, we could have CSS (??) display a label of the description when a SourceKey value is selected. This way, the information on the website will always match what is in the CDR.

Well, let's think for a moment about what you want to happen when we reach the real solution, beyond this interim workaround. Once that happens we'll be sending this extra information to the ElasticSearch server for the dictionary in a separate field, instead of including it the text which will be wrapped with the link markup, so that it can be displayed outside of the link markup, right? Wouldn't it be preferable to keep the information separate now, having the filter add it when we export the document, so that when the web site is ready for the solution you really want we won't have to run another global change to pull the extra information back out of the element's text content, using parsing which tries to identify that extra information by finding parentheses (and hoping it doesn't stumble on parentheses which are there for a different reason)? If we have the current global just do what option #2 originally said it was going to do, we wouldn't need a second global change at all.

I do not have any problems with keeping the information (description) separate. I assume that will be in new element, in which case we will need a schema change.

No, if we do what the original second option said, we wouldn't need to do anything else to the CDR documents. The interim filter change adds the parenthesized information to the link's text. The permanent solution removes that change from the filter and has the loader add the field to the ElasticSearch records, mapping the attribute values to the exported values, using the same mapping the interim filter will use. For both the interim and permanent solutions, only one global change is necessary, and when we transition to the solution you really want we don't need to do anything to the CDR documents.

I'm pretty sure Volker will be able to modify the display in XMetaL (if this would be helpful) so users can see the attribute's value without needing to bring up the attribute inspector.

~oseipokuw: Please confirm that you understand my latest explanation, and that you agree (and if you want the enhancement to the XMetaL CSS I mentioned, please add a ticket for ~volker to take care of that as well).

Hi ~bkline Yes, I understand the latest explanation and will create a ticket for ~volker to update the XMetal CSS.

William will check with Amy about whether this ticket should be in Ohm (to accommodate the need for an additional CSS ticket).

Global change run on DEV.

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2022-01-07_12-50-36

Have you created the ticket for ~volker to modify the relevant filters, ~oseipokuw?

I have consulted with Amy and Linda and they are OK with moving the global forward now. The other changes can then wait for the Ohm release. I assume then that OCECDR-5076 and OCECDR-5090 will need to be moved to Ohm, right?

I assume you understand that if I run the global change on production before OCECDR-5076 gets promoted, then all of the documents that I change will be invalid. So I'm guessing that by "moving the global forward now" you mean "move it forward into Ohm now," right?

That was what I was confused about. So, it looks like what we can implement now without a release is only OCECDR-5090. The others will need to be moved into Ohm.

I think you're still confused.

You're the one who said OCECDR-5076 will need to be moved to Ohm. If OCECDR-5076 is done in Ohm then this ticket has to be done in (or after) Ohm. Do you understand why?

My confusion lies in knowing what can be done in a release and what cannot. Will we be able to add the new attribute OCECDR-5076  without a release? I assumed that OCECDR-5076  cannot be done without a release because it is a schema change, and that is why the global (the current ticket (OCECDR-5037) which will add the new attribute and the XMetal CSS changes OCECDR-5084 , which will display the descriptions in XMetal will need to be done in Ohm. That leaves  the filter change  OCECDR-5090 which can be done outside of a release.  This is my understanding of the changes. Please let me know if I am missing anything.

As I reminded you last week, we can update a schema without a release (we built a web admin tool to do that a few years ago). You have decided in most (but not all) cases not to take advantage of that, but to wait instead for a release so that the change can be accompanied by enhancements to the XMetaL CSS (which do require a release) corresponding to the schema change. Ring any bells?

In that case we can proceed with OCECDR-5076 and the global for this ticket while the XML CSS ticket waits for a release.  OCECDR-5090  can also proceed with the filter change. I was aware that you could update the schema without a release but I thought it was not in every single case. Now I know 😃.

Please proceed to run the global in live mode on DEV. Thanks!

Have you created the ticket for ~volker to modify the relevant filters, ~oseipokuw?

Yes.  OCECDR-5090

~bkline  I do not see a comment about the live run on DEV but I think it is done. Could you please confirm?

Yes, it did finish. Sorry about that. 😛

No problem. Please run in test mode on QA. I assume  OCECDR-5076 will be copied to QA first before the global is ran.

I assume  OCECDR-5076 will be copied ...

Well, sure, when you add a note to that ticket indicating that it's been approved on DEV and asking for promotion to QA. The most recent "progress" comment in the ticket is my "installed on DEV" note.

Run completed.
{{   Docs examined    = 667}}
{{   Docs changed     = 0}}
{{   Versions changed = 606}}
{{   Could not lock   = 0}}
{{   Errors           = 0}}
{{   Time             = 0:56:01.039002}}

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2022-02-09_12-37-58

Verified. Please run in live mode on QA.

2022-02-09 17:36:41.141 [INFO] Run completed.
{{   Docs examined    = 667}}
{{   Docs changed     = 202}}
{{   Versions changed = 420}}
{{   Could not lock   = 0}}
{{   Errors           = 0}}
{{   Time             = 1:02:26.064663}}
Specific versions saved:
{{  new cwd = 1}}
{{  new pub = 202}}
{{  new ver = 16}}
{{  old cwd = 10}}

Looks good on QA. Please run in test mode on PROD.

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2022-02-14_11-43-53

2022-02-14 12:39:18.608 [INFO] Run completed.
{{   Docs examined    = 744}}
{{   Docs changed     = 0}}
{{   Versions changed = 612}}
{{   Could not lock   = 0}}
{{   Errors           = 0}}
{{   Time             = 0:55:24.879568}}

Test data verified. Please run in live mode on PROD.

2022-02-15 16:28:04.449 [INFO] Run completed.
{{   Docs examined    = 746}}
{{   Docs changed     = 204}}
{{   Versions changed = 418}}
{{   Could not lock   = 0}}
{{   Errors           = 0}}
{{   Time             = 1:04:46.393584}}
Specific versions saved:
{{  new cwd = 1}}
{{  new pub = 204}}
{{  new ver = 10}}
{{  old cwd = 11}}

Verified on PROD. Thanks!