CDR Tickets

I am unable to reproduce either of these problems on DEV (don't want to mess with the documents on the production server). Are you able to reproduce them on DEV and if so, can you give me the exact sequence of steps used to do so?

Thanks.

On DEV, I retrieved CDR0000619355 as read only and tried to validate it and it validated fine. I tried to validate it a second time and then it reported 4 errors pointing to elements in the processing status block. You can try doing the same thing with CDR0000619360. It seems like many of the GTCs and GTNs that have multiple processing status values may be able to produce the error message.

This is promising to be an interesting problem. I cannot reproduce the problem with either of those two documents. Between them I've tried a couple dozen times, using every possible combination of the checkboxes in the validate dialog box, and both tags-on and tags-off views, on two different computers. Let's start by having you send me your copy of %APPDATA%\SoftQuad\XMetaL\9.0\XMetaL90.ini and I'll compare it with mine.

I have attached my copy of the .ini file you requested.

There don't seem to be any clues in your .ini file, which is essentially the same as mine, with a couple of additional settings which aren't related to actions which would alter the documents. Next step is to have you demonstrate how to reproduce the behavior after tomorrow's status meeting.

Please try this to see if you can reproduce the error message.
1.On DEV retrieve (as read-only) a GTC CDR0000619383 with multiple processing status values.
2.Validate it to ensure that it is valid.
3.Click on Plain Text Display option in XMetal
4.Immediately go back to Normal View and try to validate again, the errors should show up.

This is not the normal way the errors shows up but I did see the error messages after doing the above. Here are a couple of IDs with multiple Processing Status Values to try:
CDR0000619385
CDR0000619386
CDR0000619389
I will also attach a file containing transcripts and screenshots from windows screen capture (PSR). I am not sure how helpful that would be. If you still can reproduce the problem, I will send you a video capture.

Aha! If you're going into Plain Text display, all bets are off. We've known since the beginning of the CDR project that XMetaL mangles documents in that view. I believe you can avoid the validation problems by using Control-Z (Edit > Undo) repeatedly until the mangling is backed out (in fact, Control-Z will bring you back to your original view.

I was trying to find the best way to reproduce the problem on DEV for you to see it and noticed that going into the Plain Text View produces the same problem. The problem comes up for users when the document is checked out in Normal view. I will try to see if I can reproduce the same process on DEV as on PROD.

I was unable to reproduce the problem on DEV without clicking on the Text View. Perhaps you can look at Version 6 of CDR0000782480 on PROD which has 4 errors from previously entered processing status values. The error were fixed in Version 7. There is no obvious reason why there should be errors in Version 6.

There is no obvious reason why there should be errors in Version 6.

It appears that the document has been saved after going into Text View. See the newlines XMetaL inserted inside the ProcessingStatus values when that happened:

<ProcessingStatus><ProcessingStatusValue>Ready for Spanish
peer review</ProcessingStatusValue></ProcessingStatus>
<ProcessingStatus><ProcessingStatusValue>Ready for
translation</ProcessingStatusValue></ProcessingStatus>
<ProcessingStatus><ProcessingStatusValue>Ready for
publishing</ProcessingStatusValue></ProcessingStatus>
<ProcessingStatus> <ProcessingStatusValue>Ready for English
OCCM review</ProcessingStatusValue> </ProcessingStatus>
</ProcessingStatuses> <TermType>Diagnosis</TermType>

Story points just reflect the remaining work of verifying that the observed problem only occurs when the document is viewed in XMetaL's raw text mode, which is strongly discouraged. If it can be established that the validation failures are introduced without the raw text view, then we'll increase the LOE estimate as appropriate.

I have no evidence to indicate that the problem occurs other than the document being viewed in text view mode.