CDR Tickets

Issue Number 3609
Summary Global Change Links error
Created 2013-05-23 15:15:16
Issue Type Improvement
Submitted By Osei-Poku, William (NIH/NCI) [C]
Assigned To alan
Status Closed
Resolved 2013-08-08 10:52:38
Resolution Fixed
Path /home/bkline/backups/jira/ocecdr/issue.107937
Description

BZISSUE::5308
BZDATETIME::2013-05-23 15:15:16
BZCREATOR::William Osei-Poku
BZASSIGNEE::Alan Meyer
BZQACONTACT::William Osei-Poku

The following error occurred while testing a Global Change (Global Change Protocol Links) on the Bastion Host this morning.

"GlobalChangeLinkBatch failed: 'ascii' codec can't decode byte 0xc2 in position 13430: ordinal not in range(128"

In case you want to reproduce the error message, here is the selection criteria below:

Document type: CTGovProtocol
Element: Diagnosis
Old link: CDR0000585059 / HIV infection;Index term;Disease/diagnosis
Replacing old link: Yes
New link:
CDR0000041695 / HIV-associated Hodgkin lymphoma;Index term;Legacy-cellular type;Neoplasm diagnosis
Change cdr:refs: Yes
Email results to:
oseipokuw@nih.gov

Comment entered 2013-05-27 00:14:03 by alan

BZDATETIME::2013-05-27 00:14:03
BZCOMMENTOR::Alan Meyer
BZCOMMENT::1

It appears from the messages that you were not actually running the "Global Change Protocol Links", but the similar program named "Global Change Links", a program that can change any links, not just protocol links, though it doesn't have all of the specialized logic for protocols.

I did some testing and, from what I can tell, the "Global Change Protocol Links" program does not have this bug. I suspect that that "Global Change Link" does have the bug but it was usually used with simpler documents, not protocols, that do not have non-ascii characters in them. I'm also guessing that the program has not been used in a very long time in production. In fact, I see it on the "Developers/System Administrators" menu, but not on the "CIAT/OCCM Staff" menu.

I also checked the Global Change log on Bach which goes back five years and don't see any Unicode errors - which either means that this program has not been run in five years, or was not used on the complex documents like protocols and summaries that are most likely to have non-ascii characters.

I'm therefore thinking this is lower priority at the moment. I propose to do other work for the CBIIT Migration and get to this as time permits.

In the meantime, I'm lowering the priority a bit.

Does that seem reasonable?

Comment entered 2013-05-28 13:27:51 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2013-05-28 13:27:51
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::2

(In reply to comment #1)
> In the meantime, I'm lowering the priority a bit.
>
> Does that seem reasonable?

Yes. It does. Bret wanted to document the steps in running the Global and also test to make sure that it works. I will let him know that we should use the Global Change Protocol Links instead for his documentation.

Comment entered 2013-07-16 20:33:15 by alan

I believe that this is now fixed in DEV and can be tested there.

I think the problem was introduced when I made some changes to handle the new session management by storing session identifier strings in the database instead of storing userid + password, as we used to do. The session information coming back from the database was in Unicode, and that caused a library function that combined session strings with commands (cdr.wrapCommand()) to implicitly try to decode everything being sent - which caused the error.

I fixed the problem with a modification to the wrapCommand function to check for Unicode session strings and convert them explicitly and correctly.

This should also fix similar bugs (if any) affecting other batch programs where we haven't noticed this bug, but for which it might have been present.

The fix (if it tests out okay) will be put into production the next time cdr.py is promoted.

Comment entered 2013-07-16 20:33:45 by alan

Ready for user test.

Comment entered 2013-07-17 14:08:36 by Osei-Poku, William (NIH/NCI) [C]

Verified on the development server. It worked without any problems.

Comment entered 2013-08-08 10:51:15 by chengep

Going to make some administrative changes. This fix will go into release 3.0.1. I am reopening only so that I can mark it as part of the proper release. Will close it immediately after.

Comment entered 2013-08-08 10:52:38 by chengep

This was already fixed. But we know now that it will go with the deployment of patch release 3.0.1

Comment entered 2013-08-20 13:21:37 by chengep

Verified by users on DEV

Comment entered 2013-09-23 11:15:22 by Kline, Bob (NIH/NCI) [C]

Any reason we shouldn't close this ticket?

Comment entered 2013-09-23 23:00:58 by alan

The work is done, the issue is now closed.

Elapsed: 0:00:00.001602