CDR Tickets

I'm going to try and configure DEV so that the CDR client can be launched using either XMetaL 4.5 or XMetaL 9.0, in order to minimize disruption to the availability of DEV for normal user testing of work on other requests. In order to accomplish this goal, I will:

• Ask CBIIT to restore the CdrSetup9.0 on the common desktop for the DEV bastion host

• Ask CBIIT to reinstall XMetaL 9.0 on the DEV bastion host

• Experiment to determine whether a single DLL, built with the xmetal90.h/cpp API files, will work correctly under XMetaL 4.5

• If that experiment fails, implement a technique to swap back and forth between the two versions of the CDR DLL

• Implement a technique to swap back and forth between the two versions of the macro file: one for XMetaL 4.5 and the other for XMetaL 9.0

• Temporarily retain the name of the desktop icon which launches XMetaL 4.5 as "CDR" and use "CDR9" as the name of the icon used to launch XMetal 9.0 (I'm hoping by the time we get to QA, we'll be able to convert exclusively to the use of XMetaL 9.0)

Are there any current activities on DEV which are critical enough that I should refrain from doing any of this work now and avoid any risk of temporarily breaking the ability to use XMetaL on that tier?

Are there so few activities currently on DEV that I shouldn't bother with implementing the techniques to swap back and forth between the two versions of XMetaL, and should instead convert that tier to just use XMetaL 9.0?

Are there any current activities on DEV which are critical enough that I should refrain from doing any of this work now and avoid any risk of temporarily breaking the ability to use XMetaL on that tier?

The one thing from my site that's ongoing would be the changes to the filters but if CIAT would need XMetaL for testing we could just use QA.

Are there so few activities currently on DEV that I shouldn't bother with implementing the techniques to swap back and forth between the two versions of XMetaL, and should instead convert that tier to just use XMetaL 9.0?

Given the fact that we had XMetaL 9.0 running on DEV reasonably welI during the evaluation I do think the XML-switcher may be a little overkill.

I believe the only issue we are testing on DEV is the one Volker mentioned above regarding the filter changes.

I was reminded, looking over the tickets for the proof-of-concept work on the upgrade, that the vendor told us that XMetaL won't work properly with multiple versions of the software installed on the same machine, so you won't have both versions of XMetaL available on the DEV bastion host. However, the client files currently installed on DEV have been modified so that the same versions of the macro file, custom CDR DLL, and CDR loader should work correctly with either version of XMetaL.

I have submitted the request for CBIIT to uninstall XMetaL 4.5 on the DEV bastion host, install XMetaL 9.0, and put the setup folder for CDR XMetaL 9.0 back on the common desktop:

https://tracker.nci.nih.gov/browse/WEBTEAM-5232

As far as I can tell, no one but myself is using DEV right now, and CBIIT is ready to switch XMetaL 4.5 out for version 9.0, so I'm going to tell them to go ahead. I will let you know when the switch is complete.

It looks like there's at least one connection to XMetaL still active. I'm going to guess it's William's, since Volker and I have logged out of XMetaL, and none of the other regular CDR users show up in the list of users connected to the DEV bastion host. So I'm going to have CBIIT drop your connection to nciws-d035-v, William.

I am logged off now. However if my connection still shows up as active, feel free to drop the connection. Thanks!

XMetaL has been upgraded on the DEV bastion host. Please test. Here are the steps:

1. Double-click on the CdrSetup9.0 folder on the desktop

2. Double-click on the InstallCdrClientFiles executable

3. Press any key to dismiss the console window which appears

4. Double-click the CDR icon installed on the desktop

5. Submit your CDR credentials

6. When prompted to register the software, enter the following location for the license file:

   %appdata%\SoftQuad\XMetaL\9.0\XMES.lic

   Please let me know if you encounter any problems, or if you can think of any improvements that could be made to these instructions.

I think one step is missing in your instructions:

1. Double-click on the CdrSetup9.0 folder on the desktop

2. Double-click on the InstallCdrClientFiles executable

3. Press any key to dismiss the console window which appears

4. ...

I'm seeing the following pop-up message after I've entered my CDR credentials:
Unable to activate printing component. Printing functionality may be impaired.

I think one step is missing ...

Good catch! Fixed. :-)

I was able to log in after the printing error message and the movie :-). It looks like we're missing the Server name customization in XMetal.

I haven't been prompted to enter a license key but it seems I'm able to access the CDR documents just fine after watching the show The Dancing Icons.

Unable to activate printing component ...

Hmm. I didn't get that, and I'm not sure what it means (neither what the message itself means, nor the significance of the fact that one of us sees the message and one of us doesn't). Googling doesn't turn up anything useful. The fact that we can't print from the bastion host anyway makes me less worried about this popup, though I would hope users wouldn't see it every single time they started XMetaL. I'll ask Derek if he can shed any light on this (though he's out today).

I've tried to modify my default printer but the message is still coming up. I also tried to print a document (to a file) and that was working OK, so the only problem that I see is the annoyance of the initial pop-up when XMetaL starts.

When you click the print icon in XMetal, you get a message indicating that there is a known bug that prevents using the icon to print (attached). Maybe they are related. We've always known not to use the print icon.

I am getting a "HTTP Status code from update server: 403" (screenshot attached) error which is preventing me from logging into the CDR.

Yep, same here.

Please try again. I ran the refreshManifest.py and that fixed it for me.

My fault. I'm trying to juggle the steps for three different tickets for the security remediation set, and it's tricky to get them all in the right order. The CDR traffic encryption ticket requires that all the CDR client requests go through the new HTTPS tunnel. The NIH Active Directory ticket requires that we do the login through Windows authentication. In order for the second requirement to be effective, we have to prevent a hacker from invoking the the CdrLogon command with the NIH domain account name to create a new CDR session, without the Windows authentication step to verify that the user supplied complete credentials (including the account's password). So I modified the tunnel to send back a 403 status code if it found a CdrLogon element in the request. But that's not going to work until we have modified the CDR loader to log in using the mechanism which goes through the Windows authentication check by IIS. And we can't do that until I get the NIH account names for the active CDR users (or at least the ones who will be testing on DEV) and plug them into the win_usr table. So I modified the tunnel script to check instead for the element which contains the NIH domain account name and block that, allowing the loader to log in using the old method (for now). Please give it another try.

Please try again. I ran the refreshManifest.py and that fixed it for me.

It worked. Thanks!

I ran the refreshManifest.py and that fixed it for me.

It was just a coincidence that it worked after you ran RefreshManifest.py (see previous comment).

It was just a coincidence that it worked after you ran RefreshManifest.py

I don't care. I'll take the credit anyway if anybody is asking. :-)

I heard back from Derek about the Unable to active the printing component ... error. Here's what he said:

This is a known issue if the installation is running on Citrix. If you are not running on Citrix the symptom is identical so I think we should try a hotfix we released. In a Citrix environment the issue is caused by some sort of permissions issue when attempting to write the license file RenderX XEP uses. We have to write the file out each time we launch and delete it when we shut down in order to meet our licensing agreement with RenderX.

The hotfix was created for a client running our software in a Citrix environment so I'm not sure it will be the same fix, but the symptom is identical so I think it probably will work. You need to apply this by hand, manually replacing the xmetal90.exe file in your installation with this copy.

We could install the hotfix on DEV, and if it introduces no new problems (and we're not worried that branching would complicate the process of getting other bug fixes) we could just use the hotfix version of XMetaL on all the tiers. Or we could leave it alone, and see if the error message (a) disappears when we're not running on the bastion host; or (b) doesn't represent any real loss in functionality (so we'd just be dealing with an occasional annoying popup); or (c) both.

I'll wait a couple of days for everyone to think about the options, and if no serious objections are raised, I'll go ahead and have CBIIT install the hotfix version of XMetaL on DEV.

It sounds to me that all we have to do is replacing the *.exe file, right? If that's the case we should be able to restore the current version of XMetaL9 easily in case we do find other problems. Given that it's still many months before we may be off the bastion host I would definitely want to try and see if the hotfix get's rid of the printer error message.

I had CBIIT install the patched version of xmetal90.exe. Here's what I wrote to Derek after some preliminary testing:

Well, I have lots of news, some promising, some not so much.

1. Haven't seen the error message about the printing component (yet). That's encouraging, but not conclusive, as we didn't get the message every single time before installing the patched version.

2. The toolbars aren't dancing any more. I suspect that the code is still going through the motions of drawing and hiding the toolbars, but invisibly now. I say this because there's still more of delay than there was with 4.5 when switching between documents or opening a new document, but it's much less of a delay than we got when the dance was actually drawing pixels on the viewport. So if not a complete victory, this would be a big win.

3. Not so encouraging is the fact that now when you switch between documents the child windows are resized in subtle ways, and the result is that sometimes when you come back to a document you can no longer get to the controls at the bottom for switching between views unless you enlarge the entire application window. I have attached a series of screen shots to illustrate this problem. The first shows the Summary document, with the bottom controls visible. In the second we have clicked on the tab to select the other (Person) document. Note that the controls for both windows are visible. In the last we have clicked on the tab to return to the first document, and the controls are no longer visible. As a side note, I don't remember seeing so much white space around the top-level tag in the tags-on view as we now see around the Summary tag, but I won't swear to the reliability of my memory on this point. I only mention it in case it's a possible clue about the problem.

4. XMetaL appears to be confused about whether it's running Enterprise or Essential. Help > About says "Essential," but as you can see from the screen shots, the Repository menu is present. As you may recall, you had recommended switching to Essential as a way to eliminate that menu.

We'll keep testing and I'll add to these notes as appropriate, while you consult with your developers about what might be causing some of these behaviors.

Thanks,

Bob

Note in particular the encouraging bit about the disappearance of the dancing toolbars. I will attach the screen shots I sent him.

Screen shots for Derek.

Derek suggested a workspace reset (holding down the Control key on startup), which eliminated the disappearing view controls and unwanted Repository menu. He confirmed my suspicion that this patch was built against the stable code base for the forthcoming version 10, not version 9, which explains why the dancing toolbars are gone, very good news indeed.

Are we allowed to log in now? I am getting the "HTTP status code update server :403 message"

Make sure you've installed the current XMetaL 9.0 CDR client files using the steps posted above on December 31, and that you're using your NIH domain account credentials to log in.

I am in after re-installing the files. Thanks!

Good. I was holding off on the invitation to test this full bore until I've had a chance to look into the server branding problem, but you're welcome to do some advance poking around.

For the server branding - if we're talking about the same thing - I believe we had this same discussion several months ago. In order to get XMetaL to let me control what's in your application title bar, you have to tell it to use the XP visual theme. To get to the visual theme, press Alt+Shift+S:

Yes, I did that. Thanks!

Just wanted to report a couple of things that I have found when testing XMetaL 9 on QA:

1. I am unable to get Publish Preview to come up for the Genetics of Breast and Gynecologic Cancers summary (CDR62855). I'm getting a "This page can’t be displayed" error message.

2. I was able to get Publish Preview to come up for the much smaller Cancer Genetics Overview summary (CDR517309); however, it doesn't look very good (spacing issues, font sizes, table gridlines do not display). I don't know if this is an XMetaL 9 issue or an NVCG-related issue. I'm using the default browser (IE).

I also just realized that Publish Preview of CDR517309 is also displaying some content twice.

It has replaced one section with another section.... See the "Structure and Content of PDQ Summaries" section.

And links (e.g., to other summaries or to other sections/images within this summary) do not display.

I don't see how this could be related to the XMetaL upgrade. Probably best to open a separate ticket and assign it to Volker.

Thanks, Bob. I have opened OCECDR-3891.

I'm not sure if this has been reported, but IE is opening in the background in XMetaL 9.

Here are two data problems and I CSS problem we came across while testing:
1. Some of the HP summaries have extra text "-for health professionals" at the end of the titles. Example CDR0000062907
2. Some summary alt titles are duplicated. Example CDR0000062906
3. When some new elements are added to CTGov documents, the instructionational text in blue font and braces that guide the user about what can be entered in the field are missing. Example, when you add new intervention block.

I have added an attachment with screenshots of the issues above.

Some of the HP summaries have extra text "-for health professionals"

Actually, all of the HP summaries have extra text except for those that were locked when I ran the global change. Since you are looking at the QA data you're looking at some of the changes for NVCG and what you're reporting is one of those changes. All HP summaries will have the title modified to add the text for health professionals.

Some summary alt titles are duplicated.

This, too, is part of the NVCG update. One of the alt titles has the type="short" and one has the type="navlabel". The second alt title is needed for NVCG.

Hi Volker, I just want to make sure I understand about the health professional titles. The actual title of the summary isn't going to have --for health professionals added to it is it? I know that is something we have to have for Cancer.gov, but I thought that they would append that. We don't want to have those titles showing up other places, and in our reports. I may be misunderstanding because I haven't looked at the data in the CDR.

I just looked and much to my horror I realize that that IS what is happening! We definitely have to talk about this. We don't want that to be the permanent title for the health professional summaries. No one told me that this was how those titles were going to be created.

Yes, that's correct. I had been tasked to write a global change program to update every HP summary in the CDR so that it modifies the summary title by adding this string "– for health professionals" (where "--" is an n-dash on the site).

Here are a few other things we have noticed:
1. We are unable to run PP for some DIS. I think this is to be expected, though, since it isn't working on prod either. Is that right?
2. I am not able to get a summary mailer preview to come up. I checked and I do have Ghostscript installed on my computer.

I also wanted to revisit the fact that I am unable to get Publish Preview to come up for the Genetics of Breast and Gynecologic Cancers summary (CDR62855). I'm getting a "This page can’t be displayed" error message. Volker thought this problem might be related to the new encryption software.

Volker asked me about the pub preview for 62855 earlier, and I reported back to him that I was able to run PP for that document successfully. It took about seven minutes (times two, since the first time came back with the "mixed content" problem and I had to submit the request again to see the page with the CSS).

OK. I'm still not able to get it to come up (same for the Genetics of Colorectal Cancer summary - CDR62863). The "page cannot be displayed" errors come up in less than 5 minutes I'd say.

I think I have a workaround for the toolbar bug. Please test (on QA).

The missing default prompts for new elements was reported last spring. The vendor removed that functionality some time after version 4.5. For the future, you'll want to have Volker implement prompts manually in our customization files for the ones you can't do without.

I believe the only thing remaining before we can mark this ticket as "Resolved" is for the users to test my workaround for the toolbar bug on QA. If that's not right, please let me know what else needs to happen.

I have put the CDR client setup files under version control:

• R13141 /branches/cdr-security-remediation/XMetaL/Setup

I think I have a workaround for the toolbar bug. Please test (on QA).

The toolbar appears to be working very well. Toolbars are pre-selected upon opening a new document (type) and doesn't disappear after saving the document. When you manually deselect the toolbar, it is removed from the window and after saving the document, it doesn't appear until you deselect and re-select the toolbar.

I should have mentioned that my comments above apply to the custom menus only. The default toolbar behaves the same way; it disappears after saving the document. However, that should not be a problem because many of us do not use the default toolbar.

I also tested the toolbars and everything looks great - the appropriate toolbars are showing up by document type and they're no longer disappearing after saving or closing a document and/or opening a second document of the same type. Thanks!

The missing default prompts for new elements was reported last spring. The vendor removed that functionality some time after version 4.5. For the future, you'll want to have Volker implement prompts manually in our customization files for the ones you can't do without.

I created OCECDR-3901 to address this issue.

QA has completed and the ticket has been submitted to CBIIT for deployment to stage, after which an appscan will be requested.