CDR Tickets

Added ~volker as a watcher.

The two scenarios seem to be at variance with each other. The first appears to imply that changes to a bunch of other documents will happen silently and automatically as part of the save of another document. That seems both expensive and dangerous. The second scenario says that the desired result will be achieved by a global change, which is a much more straightforward approach.

Yes, the variance is intentional. We used to have a user controlled global tool which was taken away during one of the python re-writes. It was a global change tool with a user interface that we used to accomplish global changes. It would be ideal to have a tool like that if not asking for too much here.

It's not clear how such a tool would satisfy the acceptance criteria for the first scenario.

I have removed the first scenario.

We used to have a user controlled global tool which was taken away during one of the python re-writes.

That makes it sound a little bit like I came in and deleted Alan's global change interface in the middle of the night without consulting anyone. 😉

I'm not 100% certain, but I suspect what I would find if I dug back into my email archives and the Jira tickets is that I was asked to remove the tool on the grounds that it was a very complicated tool which was focused primarily (exclusively?) on protocol documents, which we no longer support. 🙂

You realize that what you're editing is ephemeral, and is overridden by the denormalization filters whenever the document is saved or exported, right?

At least in the CDR, when the linking document is saved, the title of the linked document is not replaced in the Summary Ref element, and that is because for the Summary Ref element, we manually type in the title text in the tags.

OK. That's not consistent with what you were saying the other day, when you told me the links in question were not inline, but were cdr:ref links. I took a look at the schema, and the SummaryRef elements use cdr:href links, so they are inline.

So, we'll need answers to some questions.

1. The report you attached has other linking elements than SummaryRef elements. Can you confirm that you only want the program to look at SummaryRef elements?

2. Do you want the software to use the CDR document title of the linked document? The text content of the SummaryTitle element? Some other title?

3. What should the software do if the SummaryRef element contains or is contained by Insertion or Deletion elements? Ignore those?

4. The scenario I am picturing, base on what you have written above, is something like the following. Do you agree?

• The user saves the summary document with the modified title.

• The user brings up the page for this global change.

• The user enters the ID of the document she just saved.

• The software finds the linking documents and modifies the text content of the SummaryRef elements linking to that document.

• The software displays the list of the summary documents modified by the global change, with links to the pages showing the XML for those modified documents.

One possible variation of this, avoiding the need for the form on which the linked summary's document ID is entered, would be to have a context menu item in XMetaL which invokes a macro to run the global change for the summaries linked to the summary just saved.

1. The report you attached has other linking elements than SummaryRef elements. Can you confirm that you only want the program to look at SummaryRef elements?

Yes, The program only needs to look at SummaryRef elements.

One possible variation of this, avoiding the need for the form on which the linked summary's document ID is entered, would be to have a context menu item in XMetaL which invokes a macro to run the global change for the summaries linked to the summary just saved.

Actually the context menu item is preferred but it will be great to be able run a report later on to get a list of all the summaries that were changed.

The macro has been installed on CDR DEV, using the text content of the SummaryTitle element, discarding Insertion and Deletion markup inside the modified SummaryRef elements, and ignoring Insertion and Deletion wrappers around those elements. Working on the report.

The report has been installed on the Summary and Miscellaneous Documents Reports menu.

Thanks! Tested this on DEV. Is it possible to not run the program if the SummaryTitle element contains Insertion and Deletion markup? The presence of the markup within the SummaryTitle element is an indication that the title is not yet ready to go live. So, if a user could get an error message (or the global refuses to run) if an attempt is made to run the program while the SummaryTitle element contains markup, I think that would be great. 

Also, the CDR link in the results page goes to the XML instead of the QC report. Could you please change it so that the link goes to the QC report?

This looks good. Thanks! Could you please make the CDR ID in the report link to the QC report?

I could modify the program so that it parses the linked summary document to find out if there are Insertion or Deletion child elements in the SummaryTitle element. I'm a little puzzled, though. If the step in the workflow immediately before launching this program is saving the changes just made to the summary's title, how would it be possible for the user who is invoking the program not to know whether the title has any such child elements?

I have modified the script so that the links for the summaries modified by the script bring up the QC report instead of the document XML, as requested. By the way, if you have specific requirements for how a request should be implemented, you're allowed to include those requirements at the outset. 😉

Also, I have modified the script so that it doesn't bypass the form. Instead I first bring up the form with the CDR ID field pre-populated with the ID it gets from XMetaL's macro and all the user has to do is click on the Submit button. I did this because we ran into strange and random failures when testing the script which we were eventually able to determine only happen on Chrome, and are likely caused by Chrome submitting the request to the web server more than once. Doing some research, I found some threads which put forward the theory that because the request is a GET request (as are all of the HTTP requests which come from XMetaL), which according to the standard is supposed to be "idempotent" (which basically means it can be submitted multiple times without any side effects) and shouldn't be used for requests which modify the server's state, including any databases (POST or DELETE HTTP requests are supposed to be used for those), Chrome feels it is OK to submit the request more than once, causing the failures we ran into. So I figured that it's worth the extra click to avoid these random failures.

Would it be possible to get a list of summaries to be changed before clicking on the submit button? I recognize that this is a new requirement so I can create a new ticket for Pauling to take care of this modification if it can't be done in this ticket.

Yes, please add a new ticket to Pauling.

Verified on QA. Thanks!