PDQ Issues

Issue Number	3144
Summary	[CTgov Transfer] Macro for extracting PDQ Admin Info
Created	2010-05-07 15:05:21
Issue Type	Improvement
Submitted By	Osei-Poku, William (NIH/NCI) [C]
Assigned To	Kline, Bob (NIH/NCI) [C]
Status	Closed
Resolved	2010-05-26 12:29:56
Resolution	Fixed
Path	/home/bkline/backups/jira/ocecdr/issue.107472

Description

BZISSUE::4827
BZDATETIME::2010-05-07 15:05:21
BZCREATOR::William Osei-Poku
BZASSIGNEE::Bob Kline
BZQACONTACT::William Osei-Poku

Please create a macro for extracting PDQ Admin Information from the InScope Protocol into the CTGov Protocol document.

1. PDQProtocolIDs block
2. FundingInfo block
3. CTGovTransferContactLog block
4. CTGovTransferInfo block
5. PublishedResults block
6. RelatedPublications block
7. ProtocolSpecialCategory block

Comment entered 2010-05-10 16:18:19 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-10 16:18:19
BZCOMMENTOR::Bob Kline
BZCOMMENT::1

Can you provide a little more information about this request? Will the macro really be a single macro, rather than work the way the pair of macros for copying the PDQIndexing block from an InScopeProtocol document and pasting it into another (CTGovProtocol) document do? If so, please provide a specification for how the software knows which documents are the source and target documents. What should the software do if the block already exists in the target document?

Comment entered 2010-05-12 12:43:36 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-12 12:43:36
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::2

(In reply to comment #1)
> Can you provide a little more information about this request?
>Will the macro really be a single macro, rather than work the way the pair of >macros for
> copying the PDQIndexing block from an InScopeProtocol document and pasting it
> into another (CTGovProtocol) document do?

Yes, it will work as a pair of macros just like the one for copying and pasting the PDQIndexing block.

In terms of providing more information, are you referring to providing the mapping of the elements in the two document types?

>If so, please provide a
> specification for how the software knows which documents are the source and
> target documents.

Could you please expound on this request?

>What should the software do if the block already exists in
> the target document?

Typically, the macros will be used for documents that do not already have the PDQAdminInfo block. In the case that the block already exist, provide feedback to the user to either replace or cancel the replacement.

Comment entered 2010-05-12 13:15:19 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-12 13:15:19
BZCOMMENTOR::Bob Kline
BZCOMMENT::3

(In reply to comment #2)

> > Will the macro really be a single macro, ...
>
> Yes, it will work as a pair of macros ....

I'm going to assume you meant to say "No, it will work as a pair of macros ...."

> In terms of providing more information, are you referring to providing the
> mapping of the elements in the two document types?

No. Your original request had asked for a single macro. The only way I could think of a single macro doing what you were describing would be to invoke it on one of the documents and have the software figure out what the other document was, and I was asking for the logic which should be used to do this. Now that you have clarified (I think) that this isn't what you had in mind, but instead were asking for a pair of macros, the question goes away.

> > If so, please provide a
> > specification for how the software knows which documents are the source and
> > target documents.
>
> Could you please expound on this request?

The request started off "If so, ..." which was a shorthand way of saying "If the processing must be performed by a single macro, ...." I think you're trying to tell me that you didn't really want just a single macro, right?

Comment entered 2010-05-12 16:11:42 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-12 16:11:42
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::4

(In reply to comment #3)
> (In reply to comment #2)
>
> > > Will the macro really be a single macro, ...
> >
> > Yes, it will work as a pair of macros ....
>
> I'm going to assume you meant to say "No, it will work as a pair of macros
> ...."

That is correct. My apologies for the confusion.

>
> > In terms of providing more information, are you referring to providing the
> > mapping of the elements in the two document types?
>
> No. Your original request had asked for a single macro. The only way I could
> think of a single macro doing what you were describing would be to invoke it on
> one of the documents and have the software figure out what the other document
> was, and I was asking for the logic which should be used to do this. Now that
> you have clarified (I think) that this isn't what you had in mind, but instead
> were asking for a pair of macros, the question goes away.
>
> > > If so, please provide a
> > > specification for how the software knows which documents are the source and
> > > target documents.
> >
> > Could you please expound on this request?
>
> The request started off "If so, ..." which was a shorthand way of saying "If
> the processing must be performed by a single macro, ...." I think you're
> trying to tell me that you didn't really want just a single macro, right?

That is correct.

Comment entered 2010-05-18 11:16:52 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-18 11:16:52
BZCOMMENTOR::Bob Kline
BZCOMMENT::5

The macros have been implemented on Mahler; ready for user testing.

Comment entered 2010-05-19 10:28:14 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-19 10:28:14
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::6

(In reply to comment #5)
> The macros have been implemented on Mahler; ready for user testing.

For the <PublishedResults> block and the <RelatedPublications> block, the values for the cdr: ref (The CDR ID) of the <Citation> element and the <RelatedCitation> element respectively, are either not copying over to the CTGovProtocol or they are not inserting in the attribute inspector. This makes the document invalid until I have re-linked the citations.

Comment entered 2010-05-19 10:39:31 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-19 10:39:31
BZCOMMENTOR::Bob Kline
BZCOMMENT::7

Oops! The macro was stripping cdr:ref attributes instead of cdr:id attributes. Fixed on Mahler. Please try again.

Comment entered 2010-05-19 11:12:13 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-19 11:12:13
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8

(In reply to comment #7)
> Oops! The macro was stripping cdr:ref attributes instead of cdr:id attributes.
> Fixed on Mahler. Please try again.

Verified on Mahler. Please promote to Bach.

Comment entered 2010-05-19 11:18:06 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-19 11:18:06
BZCOMMENTOR::Bob Kline
BZCOMMENT::9

Unless there's an urgent need to extract and promote these macros separately by hand, they can be promoted along with the macro (and server & DLL modifications) implemented for task #4839.

Comment entered 2010-05-19 11:36:46 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-19 11:36:46
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

(In reply to comment #9)
> Unless there's an urgent need to extract and promote these macros separately by
> hand, they can be promoted along with the macro (and server & DLL
> modifications) implemented for task #4839.

There is no urgent need to promote this. It can wait for OCECDR-3152.

Comment entered 2010-05-25 13:13:44 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-25 13:13:44
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::11

(In reply to comment #10)
> (In reply to comment #9)
> > Unless there's an urgent need to extract and promote these macros separately by
> > hand, they can be promoted along with the macro (and server & DLL
> > modifications) implemented for task #4839.
>
> There is no urgent need to promote this. It can wait for OCECDR-3152.

Would it be possible to promote this to Bach today?

Comment entered 2010-05-25 14:02:33 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-25 14:02:33
BZCOMMENTOR::Bob Kline
BZCOMMENT::12

(In reply to comment #11)

> > There is no urgent need to promote this. It can wait for OCECDR-3152.
>
> Would it be possible to promote this to Bach today?

I can take care of this tonight. Again, the priority setting is your friend. I have 20 tasks in my queue, and not a single one has a priority higher than P5. It's difficult to believe that it makes no difference which order I address them in.

Comment entered 2010-05-25 14:07:46 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-25 14:07:46
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::13

(In reply to comment #12)
> (In reply to comment #11)
>
> > > There is no urgent need to promote this. It can wait for OCECDR-3152.
> >
> > Would it be possible to promote this to Bach today?
>
> I can take care of this tonight. Again, the priority setting is your friend.

Thanks!

> I have 20 tasks in my queue, and not a single one has a priority higher than
> P5. It's difficult to believe that it makes no difference which order I
> address them in.

I can certainly change the priority but we discussed in one of our meetings that we should be addressing the priority of issues in the CDR meetings. The only time I assign a higher priority is when there is a bug or an error that needs to be fixed ASAP.

Comment entered 2010-05-25 14:21:29 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-05-25 14:21:29
BZCOMMENTOR::Volker Englisch
BZCOMMENT::14

> I can certainly change the priority but we discussed in one of our meetings
> that we should be addressing the priority of issues in the CDR meetings.

FYI:
You could still adjust the severity of a bug without changing the priority in order to adjust the order in which the issues should be addressed. Our default is 'enhancement' but one could certainly use 'trivial, normal, major, etc.' as well.

Comment entered 2010-05-25 16:00:05 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-25 16:00:05
BZCOMMENTOR::Bob Kline
BZCOMMENT::15

(In reply to comment #14)
> > I can certainly change the priority but we discussed in one of our meetings
> > that we should be addressing the priority of issues in the CDR meetings.
>
> FYI:
> You could still adjust the severity of a bug without changing the priority in
> order to adjust the order in which the issues should be addressed. Our default
> is 'enhancement' but one could certainly use 'trivial, normal, major, etc.' as
> well.

That's good advice, but please only apply it to bugs. If an issue is for an enhancement to the software, rather than a failure of the software to behave according to the existing requirements, please use 'enhancement' for the issue instead of one of the values reflecting an actual bug. The online definitions for the severity levels are a helpful guide.

Comment entered 2010-05-26 11:05:08 by Kline, Bob (NIH/NCI) [C]

BZDATETIME::2010-05-26 11:05:08
BZCOMMENTOR::Bob Kline
BZCOMMENT::16

Promoted to Bach; please check (and close if OK).

Comment entered 2010-05-26 12:29:56 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-26 12:29:56
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::17

(In reply to comment #16)
> Promoted to Bach; please check (and close if OK).

Verified on Bach. Issue closed. Thank you!

Elapsed: 0:00:00.000533

CDR Tickets