CDR Tickets

BZDATETIME::2012-04-12 14:30:21
BZCOMMENTOR::Bob Kline
BZCOMMENT::1

This is what we came up with in the status meeting:

TypeOfSummaryChange*
@Type (controlled list of valid values)
@Date
Comment*

(after the ComprehensiveReview elements).

BZDATETIME::2012-04-24 10:00:45
BZCOMMENTOR::Bob Kline
BZCOMMENT::2

I have installed the new element on Mahler. I couldn't remember whether you had said you wanted the valid values for the Type attribute to be controlled by a drop-down list in XMetaL, or if so what punctuation you wanted, so the values are given with hyphens:

reformat
comprehensive-revision
major-change
minor-change
editorial-change
new-section
new-summary

Let me know if that's not right.

http://mahler.nci.nih.gov/cgi-bin/cdr/GetSchema.py?id=203

BZDATETIME::2012-04-25 13:34:51
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::3

I couldn't find the new element in the summary document in XMetal. But I see it in the Summary Schema. Do we need a CSS issue to order to see it displayed or I am not doing something right ?

BZDATETIME::2012-04-25 13:36:56
BZCOMMENTOR::Bob Kline
BZCOMMENT::4

(In reply to comment #3)

> Do we need a CSS issue to order to see it displayed ....

Yes.

BZDATETIME::2012-04-27 12:48:25
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::5

Verified on Mahler. Please promote to Bach.

BZDATETIME::2012-04-27 13:05:31
BZCOMMENTOR::Bob Kline
BZCOMMENT::6

Promoted to Bach as requested.

BZDATETIME::2012-04-27 13:10:09
BZCOMMENTOR::Robin Juthe
BZCOMMENT::7

I see that this has been promoted, but I think we need to sort out whether the username should be added as an attribute as we discussed yesterday, and whether storing the type as an attribute as opposed to an element value is best. My vote would be to add the username as an attribute and make the type an element value from a picklist so that the element is not simply a wrapper for comments, as Volker mentioned in the CSS issue. I'd like to get Margaret's opinion on this before any changes are made though.

BZDATETIME::2012-05-09 17:38:16
BZCOMMENTOR::Robin Juthe
BZCOMMENT::8

In last week's meeting, we agreed to make some changes to the schema and re-assign this to Volker.

Basically, we would like the TypeOfChange element to be a wrapper for a block of elements similar to the Processing Status block in media documents.

The Type of Change value should be entering using a CTRL+enter pick-list rather than selected up in the attribute inspector. The other elements in the block will be for the user name, date, and comments. The comments will NOT be in-line (so that they don't all run together).

BZDATETIME::2012-05-09 18:01:42
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

I thought that a new issue to create a macro which populates the new element would be assigned to me.
Maybe I will see that one, too.

BZDATETIME::2012-05-17 15:36:31
BZCOMMENTOR::Robin Juthe
BZCOMMENT::10

Lowering priority.

BZDATETIME::2012-06-13 18:26:38
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

(In reply to comment #8)
> Basically, we would like the TypeOfChange element to be a wrapper for a block
> of elements similar to the Processing Status block in media documents.

I've mimicked the Processing Status for the TypeOfSummaryChanges and adjusted the Schema and CSS accordingly.
We may need to think about how to handle the Comment field because the TypeOfSummaryChange block now includes the UserID and Date, so this information that's also part of the Comment field attributes is redundant.

This is ready for review on MAHLER.

BZDATETIME::2012-06-15 12:25:45
BZCOMMENTOR::Robin Juthe
BZCOMMENT::12

(In reply to comment #11)
> (In reply to comment #8)
> > Basically, we would like the TypeOfChange element to be a wrapper for a block
> > of elements similar to the Processing Status block in media documents.
> I've mimicked the Processing Status for the TypeOfSummaryChanges and adjusted
> the Schema and CSS accordingly.
> We may need to think about how to handle the Comment field because the
> TypeOfSummaryChange block now includes the UserID and Date, so this information
> that's also part of the Comment field attributes is redundant.
> This is ready for review on MAHLER.

This looks good on Mahler, but we have a question about the user name element. If the user name were stored in the attribute inspector, and the date were stored in the type of change block (as it is now), could the macro be used to populate both of these things when the new type of change block is inserted? If so, we think it may be better to store the user name in the attribute inspector in order to save some real estate on the page. (Also, it will usually be the same person entering the change each time.)

We are planning to discuss this element in the next CIS team meeting in order to establish some guidelines for how it will be used before we promote the changes. We would also like to have the macro to enter these elements in place before promoting this (OCECDR-3511).

In the meantime, is there a way to un-promote the previous TypeOfChange schema changes that were promoted to Bach on 4/27?

BZDATETIME::2012-06-15 14:23:03
BZCOMMENTOR::Volker Englisch
BZCOMMENT::13

(In reply to comment #12)
> If the user name were stored in the attribute inspector, and the date were
> stored in the type of change block (as it is now), could the macro be used to
> populate both of these things when the new type of change block is inserted?

Yes.

The attribute inspector lists the attributes associated to the element that the cursor is on. When you're saying "store the user name in the attribute inspector" we need to decide to which element you would like to add the username. I would guess that the username would be listed with the TypeOfChangeBlock.

> If so, we think it may be better to store the user name in the attribute
> inspector in order to save some real estate on the page.

Do you want me to make the change on MAHLER?

BZDATETIME::2012-06-15 14:36:11
BZCOMMENTOR::Volker Englisch
BZCOMMENT::14

(In reply to comment #12)
> In the meantime, is there a way to un-promote the previous TypeOfChange schema
> changes that were promoted to Bach on 4/27?

Bob, it appears to me that you have not yet versioned the SummarySchema that is currently on BACH. Is this correct?
If so I could just restore the version from SVN on BACH in order to remove the first version of the TypeOfSummaryChange block or were there other changes as well?

BZDATETIME::2012-06-15 16:00:19
BZCOMMENTOR::Bob Kline
BZCOMMENT::15

(In reply to comment #14)

> Bob, it appears to me that you have not yet versioned the SummarySchema that is
> currently on BACH. Is this correct?

Right. I was waiting for the dust to settle on what we really wanted (as soon as I promoted it Robin posted her comment raising questions about the requirements).

> If so I could just restore the version from SVN on BACH in order to remove the
> first version of the TypeOfSummaryChange block or were there other changes as
> well?

That works (there's nothing else in my sandbox version).

BZDATETIME::2012-06-15 16:18:24
BZCOMMENTOR::Volker Englisch
BZCOMMENT::16

(In reply to comment #12)
> In the meantime, is there a way to un-promote the previous TypeOfChange schema
> changes that were promoted to Bach on 4/27?

I've restored the version of the schema from before 4/27 on BACH:
SummarySchema.xml - R10290

BZDATETIME::2012-06-15 16:20:21
BZCOMMENTOR::Robin Juthe
BZCOMMENT::17

(In reply to comment #13)
> (In reply to comment #12)
> > If the user name were stored in the attribute inspector, and the date were
> > stored in the type of change block (as it is now), could the macro be used to
> > populate both of these things when the new type of change block is inserted?
> Yes.
> The attribute inspector lists the attributes associated to the element that the
> cursor is on. When you're saying "store the user name in the attribute
> inspector" we need to decide to which element you would like to add the
> username. I would guess that the username would be listed with the
> TypeOfChangeBlock.
> > If so, we think it may be better to store the user name in the attribute
> > inspector in order to save some real estate on the page.
> Do you want me to make the change on MAHLER?

Yes. Please make this change on Mahler. I agree - the attribute should be on the TypeOfChange block. Thanks!

BZDATETIME::2012-06-15 16:38:49
BZCOMMENTOR::Volker Englisch
BZCOMMENT::18

You've never mentioned the Comment Element. Should element still be part of the TypeOfSummaryChange block?

BZDATETIME::2012-06-15 16:40:48
BZCOMMENTOR::Robin Juthe
BZCOMMENT::19

(In reply to comment #18)
> You've never mentioned the Comment Element. Should element still be part of
> the TypeOfSummaryChange block?

Yes, please keep the comment element in the block.

BZDATETIME::2012-06-15 17:00:34
BZCOMMENTOR::Volker Englisch
BZCOMMENT::20

I've modified the schema on MAHLER to move the EnteredBy element to become an attribute.

BZDATETIME::2012-06-20 15:32:22
BZCOMMENTOR::Robin Juthe
BZCOMMENT::21

(In reply to comment #20)
> I've modified the schema on MAHLER to move the EnteredBy element to become an
> attribute.

This looks good. I noticed the ChangeDate element is no longer included in the default TypeOfChange block of elements, but I think this is fine since it will be added and populated using the macro.

BZDATETIME::2012-07-03 16:41:19
BZCOMMENTOR::Robin Juthe
BZCOMMENT::22

(In reply to comment #21)
> (In reply to comment #20)
> > I've modified the schema on MAHLER to move the EnteredBy element to become an
> > attribute.
> This looks good. I noticed the ChangeDate element is no longer included in the
> default TypeOfChange block of elements, but I think this is fine since it will
> be added and populated using the macro.

We decided we would like this block of elements to immediately follow the Date Last Modified element in the schema, rather than fall at the very end of the document (after the Related documents). Could you please make this change on Mahler? Thanks.

We were also wondering if it would be possible to have the element pick-list values appear in another (non-alphabetical) sequence in the dialog box that is called up by CTRL-enter. If so, we would like to place them in a hierarchical order of biggest change --> smallest change. We can provide a list if this is feasible.

BZDATETIME::2012-08-01 16:04:05
BZCOMMENTOR::Volker Englisch
BZCOMMENT::23

(In reply to comment #22)
> We were also wondering if it would be possible to have the element pick-list
> values appear in another (non-alphabetical) sequence in the dialog box

Unfortunately, this doesn't seem to be possible without changes to the schemas and the CDR server. The list-of-values is retrieved by the server from the schema file and automatically sorted.
If these values are for internal use only it may be possible to create the values in the requested sort order by specifying them as
1 - New summary
2 - Reformat
3 - Major change
4 - Minor change
etc.

The TypeOfSummaryChanges block has been moved and the ChangeDate element is displaying again.

BZDATETIME::2012-09-05 18:25:34
BZCOMMENTOR::Volker Englisch
BZCOMMENT::24

If I remember correctly the decision was to keep the alpha sort order and not have the entries sorted by importance.

BZDATETIME::2012-09-05 18:31:34
BZCOMMENTOR::Robin Juthe
BZCOMMENT::25

(In reply to comment #24)
> If I remember correctly the decision was to keep the alpha sort order and not
> have the entries sorted by importance.

That's right.

Made TypeOfSummaryChange a wrapper with multiple child elements as requested by Robin, and without attributes. Please confirm that this is what you want. Installed on DEV.

This looks great, except that we'd like to make a few changes to the list of values in the picklist to simplify things. We have decided not to track minor/editorial changes.

The new list of values is below:

Comprehensive revision
Major change
New summary
Reformat

Valid value list changed on DEV.

Verified on DEV.