CDR Tickets

Holding off on estimating LOE for this ticket until we have requirements.

Workflow Management.docx

I have attached a draft document outlining what we expect for this report. The attached document relates to only summaries. The part of the report related to Glossary and Media will follow the same pattern. When we've discussed the attached document and things have become clearer, I will update the document taking into consideration the other document types. On the other hand, we can separate out the different documents types and treat each as its own report, although users desire to have everything in one place.

Replaced the Word doc with an updated one.

I have a proposed approach which I will present at tomorrow's CDR meeting.

I have attached an updated version of the the draft specs.

I'm confused. I thought the next step was for me to come up with a proposed approach which stores the workflow information in database tables instead of in the CDR summary documents.

We agreed in yesterday's weekly status meeting that – even though the requirements posted yesterday made no mention of the possible approach which uses database tables to store the workflow information – this approach will be presented to Linda for consideration, as it provides the most complete support for the individual requirements, in particular the real-time notification when a translation job transitions from one state to the next, as well as the ability to store earlier states (such as "translation pending") for new summaries which do not yet have a Spanish CDR summary document.

William will get answers for the following questions (assuming the table-based approach is adopted):

1. Should the software automatically delete a job prior to running a report or bringing up the queue management interface when it is detected that the job has a state of "Translation Complete" and a publishable version of the Spanish summary has been created on or after the date of that state? Or should there be a button for purging all such jobs under user control (to allow the user to first create a report which includes such jobs)? Or should the users delete each job separately when it is appropriate to do so?

2. Assuming the "Assigned To" drop down should not really contain every single CDR user account, which users should the list currently contain?

3. Should the pick list for new translation jobs contain all published English summaries which have a summary type which gets translated (e.g., excluding Genetics) and for which a translation job is not in the system? Or should a flag be added to each English summary which should be included on the pick list? (This question needs to be discussed with Margaret.)

4. Should the default value for a new translation job for an English summary which has an existing translation be based on the value in the latest "type of change" block of the English summary document if there are any such blocks? Or should the default for such jobs be "Editorial Change"? Margaret made a convincing argument for ignoring the "type of change" information blocks for this purpose. (The default for a summary which does not yet have a Spanish translation will of course by "New Summary.")

5. What should the order of the list of existing jobs be for the queue management page? (Remember that it's the reporting module which has the options for choosing what the sort order for the requested report should be. The queue management page will have a fixed sort order.)

Again assuming the table-based approach is adopted, Bob will:

1. Implement a button in XMetaL which can be used to bring up the translation job queue management page for the currently active window's summary document. The button would work from either the original English document or the Spanish translation document (assuming there is one yet). This would probably be the easiest way to create new translation jobs (as well as edit or view existing jobs), which makes it less critical to narrow the pick list of summaries for new jobs in the queue management interface.

2. Implement the email alerts to go out when a job is created or transitions to a new state. We agreed that we would not send the alert when the user creating the job or changing the state is the same as the "Assigned To" user.

3. Add the new columns from the latest requirements to the report.

4. Add the new workflow states from the latest requirements.

Linda Looooooves this :-).

Here are responses to the questions above:

1. The button for purging completed jobs is preferred (with the option to create a report of jobs included).
2. The assigned to field should have the following users:
1. Linda Saucedo
2. Isabel Lansberry
3. Victoria Victoria Imas-Duchovny
4. Monica Adler
3. A flag in the English doc is preferred with the option to also add a comment as well
4. This should be based on the Type of Summary Change element. For the Patient summaries, the default should be "Editorial Change"
5. The queue should be sorted by the "Translation Status" and then by "Assigned To".
_______

1. Implement 3 buttons in XMetal. One for the queue form interface, one for the queue itself and one for the report interface. The queue management form interface window popup as a smaller window that doesn't take over the whole screen?
2. All Translators should have access to the workflow management tools and they should be able to perform all tasks except only Linda should be able to clear completed tasks.
I believe this should cover most if not all the questions but please let me know if you have more questions or need further clarifications on the responses provided.

The queue management form interface window popup as a smaller window that doesn't take over the whole screen?

All of the buttons in XMetaL will open a page in Internet Explorer, without control over the size of the browser window. We could investigate the possibility of having the button on the queue page open the editing page for an individual job do so in a separate window with smaller dimensions, but I'm not sure what the real benefits of that would be, and whether it would be worth it. For one thing, that would mean different behavior for the same page depending one where the button was which brought up the page, and its been made very clear in the recent status meetings that introducing such inconsistencies is frowned upon. :-)

I'm glad Linda likes the prototype. I will proceed with fleshing it out.

> A flag in the English doc is preferred with the option to also add a comment as well ...

I trust you saw the note above that this decision needs to be made in consultation with PCIB. Margaret pointed out that the approach of adding such a flag to all of the English summaries which require translation (and removing the flag at the appropriate time) would involve some extra work which could perhaps be avoided. You might want to consider that the most frequent method of adding a summary to the translation queue will probably be clicking the new Translation Job button in XMetaL from the English summary document in XMetaL. If this is true, you could avoid the work of modifying the schema and adding a "let this document show up on the pick list" flag to each such document. This way, you could just let the software put any (non-genetics) published English summary which wasn't already in the queue on the pick list for the less common approach of selecting a summary for a new job without using the new XMetaL button. If there is a need for a comment, perhaps it could be added to the translation job table, as well as the page which displays the details for a particular job.

If you don't agree, and Margaret approves the decision to modify the schema and only allow summaries on the pick list for which this new flag is present, please let me know precisely what the schema changes should be.

Thanks,
Bob

Another question – now that we have the new state Translation Made Publishable, is it appropriate to add the logic for finding a publishable version later than the last state in order to have the new Purge button remove such a job from the queue? To ask it another way, when would someone set the job's state to say that the translation had been made publishable when the translation had not in fact been made publishable. Remember, if the user creates the new publishable version for the translation, and then moves the job's state to Translation Made Publishable – which is the natural sequence of events – and we make the software wait until it finds a publishable version later than the current state for the Purge button to do its work, that wouldn't happen until the user creates a second publishable version, later on. Surely that's not really what you want, is it?

The short version of all of this is: I'm recommending that the Purge button drop all the jobs which are in the Translation Made Publishable state (thus assuming that state means what it says).

Here's a progress report.

✔ implement the button for purging completed jobs
✔ populate the group for the assigned-to field with the new list of users
✔ populate the default value for the change field as requested
✔ sort the queue page by status, followed by the assigned-to field
✔ implement a button in XMetaL for the translation queue reports
✔ implement a button in XMetaL for the translation queue interface
✔ implement a button in XMetaL for the translation job form
✔ control permission for the actions as requested
✔ implement an interface for modifying the data in the valid values control tables
✔ implement email alerts for transitions between states as described above
✔ expand/modify the report columns as requested in the second version of the requirements document
✔ expand the set of workflow states
✔ replace the test data set to match the new states/users

Scheduled reports will be implemented once I have

1. confirmation that they're still needed, in light of the functionality which has already been implemented; and

2. the pending requirements for the parameters for those reports.

I believe all the remaining tasks are waiting for answers to my earlier questions.

To control who gets the test alerts on the lower tiers (just DEV right now), add/remove users to/from the Test Translation Queue Recips group.

> Implement the email alerts to go out when a job is created or transitions to a new state ...

I propose that (provided the current user and the "assigned to" user are not the same) we send the alert if any of these three conditions are in effect:

1. the job is new

2. the state has changed

3. the "assigned to" user has changed

Does this seem reasonable? It would seem unreasonable to me if we did not add this third condition.

Yes, this sounds good to me.

If there is no further feedback by the end of today, I will move this task into the "Completed" column, assuming that

1. no scheduled reports/notifications are needed, given the functionality which has already been provided;

2. no modifications to the schema will be made to support additional filtering of the picklist for summaries, since we anticipate that the standard method for creating a new translation job will use the new button in XMetaL; and

3. the Purge button will drop all jobs which are in the Translation Made Publishable state.

We need a little more time to address the above issues. I will enter a comment as soon as possible.

I propose that (provided the current user and the "assigned to" user are not the same) we send the alert if any of these three conditions are in effect:
the job is new
the state has changed
the "assigned to" user has changed
Does this seem reasonable? It would seem unreasonable to me if we did not add this third condition.

Yes, this is fine.

I see your new comment, but it addresses a question which had already been settled last month, not the assumptions itemized in my previous comment from today.

Scheduled reports will be implemented once I have
1. confirmation that they're still needed, in light of the functionality which has already been implemented; and
2. the pending requirements for the parameters for those reports.
I believe all the remaining tasks are waiting for answers to my earlier questions.

1. Yes, the scheduled reports are still needed.
2. Weekly (Monday Morning - 5:00 am), email to users who have work work assigned to them that does not have a status of "Translation Complete".

1. This has been addressed in one of the comments I posted this morning.
2.Yes, let's stick with the the new button for creating new translation jobs.
3. Yes, this is fine. The Purge button should purge Translation Made Publishable jobs.

1. With the translation queue, we want to be able to see only one translation status, Ready for Translation, for example. Seems like a simple user interface that users can use to limit what is displayed will be helpful.

2. When a job is submitted and there is an existing/matching Spanish summary, the Spanish title is displayed. Can you display the English title instead or both the English and Spanish titles?

3. With regards to the Icons, could you set it up in a way that when you're in the English Summary and you click on the job queue icon, it will open the Translation Job interface with the current summary selected? And in the Spanish summary, it will open the Edit Translation job interface?

When you accidentally submit a duplicate job, the following error message is displayed. Could you please change the message to indicate that a duplicate job has been submitted?

"502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server."

Please add the following to the list of translation statuses:

•Translation Pending – Trados
•Translation Peer-Review Pending – Trados

I am presenting the states in logical, rather than alphabetical order, so it would be good to know where these should fall, relative to the states we already have.

This is the complete list in the order in the correct order:

• Ready for Translation
• Translation Pending
• Translation Pending in Trados
• Translation in Progress
• Translation Complete
• Translation Peer Review 1 Pending
• Translation Peer Review 1 Pending in Trados
• Translation Peer Review 1 in Progress
• Translation Peer Review 1 Complete
• Translation Peer Review 2
• Translation Peer Review 2 Complete
• Implement Changes from Peer-Reviews
• Translation Made Publishable

Can you provide the steps which led up to this message? If it is caused by clicking on the Save button a second time while the original request is underway, there may not be any way to catch that condition and replace the browser's message with something prettier.

I think I have found some very tricky JavaScript techniques which will prevent an impatient user from submitting the same job twice. Please test thoroughly, to make sure we're not getting too tricky!

Is it intentional that the former state Translation Peer Review 2 Pending is now called Translation Peer Review 2?

The states have been updated (but see request for confirmation above).

I just saw these new requirements. We're going to have to push this ticket into Iteration II. We can discuss these new requirements in tomorrow's status meeting.

No. That was not intentional. Please keep former.

We think Linda meant "Translation Made Publishable" instead of "Ttranslation Complete" for the state to exclude from the weekly reports. Please confirm, ~oseipokuw.

William is going to confirm or override the request for an additional page for the translation queue, forcing the users to pick states they'd like to see. The users may change their minds when there aren't so many translation jobs in the queue.

"Translation Made Publishable" is what Linda meant. Sorry about the confusion.

Is the list of users in the Assigned to field controlled by a CDR Group? Apparently, others beside the translation team are involved in the process so we need to add them.

You can add them to the "Spanish Translators" group (as we discussed in one of the status meetings).

Thanks!

I have attached a word doc with proposed changes to the text of the email notification.

Please make the following changes to the report interface.

1. Change "States" to "Statuses" in the second (States) section.
2. Under the "Sort By" section of the report interface, please rename "State Date" to "Status Date"
3. Under the "Sort By" section rename "Processing State" to "Processing Status".

Also with regards to the icons and reports please make the following changes:

1. The job queue icon hover/tip text in XMetal, the report title on the menu and the report title should read "Translation Job Queue" for consistency.
2. The icon hover text of the translation job report in XMetal, the report title on the menu and the report title should read "Translation Job Workflow Report".

These changes have been made on DEV.

I was a little confused by the second part ("... please make the following changes ...") because it looked to me as most of the places you identified already do what you want. For future similar requests please identify the parts which need to be changed explicitly (e.g., "please change A from X to Y to be consistent with Z on B"). I think I have done what you want here, but you'll need to check carefully.

The notification job is scheduled to run at 5:00 am Monday morning on DEV. To control who gets the test email messages from that job, adjust the membership of the "Test Translation Queue Recips" CDR group.

Can we get this decision today? I believe this is the final piece before we can declare this ticket completed, right?

We decided not to proceed with the change but rely on the sort order of the queue to always have the Ready for Translation status at the top. It seems that is how it is at the moment if I am not mistaken.

That's correct. The rows are grouped by status (in logical order, following the sequence you provided above, in which "Ready for Translation" is at the top), then within the same status by user, then within the same user by the date on which the job entered the status.

Completed on DEV.

For deployment to upper tiers:

• create database tables

• create scheduled job for 5:00 am Monday morning

Is it possible to clear the test data on DEV so we can have a clean plate to continue testing ?

Done.

Thanks!

Sometimes, it is important to let the translator know the specific version (Final Markup Version) to use for translation. Is it possible to modify the Add/Create Job interface to include a field for the version which either lists the version history (of the English Doc) or allow free text for users to type in the version number to use translation? The version history from the CDR doc is preferred.

Please change the "State" label of the Create Job interface to to read "Status"

Don't forget to move the ticket back from "Development Completed" to the "To Do" column of the sprint when the requirements change, so it doesn't fall through the cracks. I've done it for this change.

Thanks.

Sorry. I had forgotten about that.

With regards to the "Translation Job Workflow Report", it doesn't appear to display the history of steps or statuses when you run it. It seems to show only the current state or status of what is assigned. Let me explain with an example:

Yesterday, Tana Smith was assigned a summary (62763) with a status of "Translation Peer Review 1 Pending". When I run the report by selecting Tana Smith with a date range from yesterday to today's date. The report only shows that currently the summary is assigned to Tana Smith but with a status of "Translation Peer Review 2" which is the status currently of the summary assigned to her. Is it possible to also get the history of what statuses were assigned in the past and not only what is currently assigned?

The original requirements indicated that only the current state of the workflow should be stored for a given English summary. We'll need to remove this ticket from the release in order to make this change to the requirements and design this late in the game. Please move the ticket to the backlog.

We can add this change to a future release.

In the email notification, please include information about who assigned the job or changed the status of the job that triggered the email.

Done.

Done.

(It looks like I've stumbled across another bug in JIRA. I posted this comment as a reply to William's request above for a new field where the users can indicate which version of the English document should be the basis for translation, but instead of displaying this reply immediately under the comment to which I was replying, it shows the reply as if it were a separate comment, for removed from the context which made it clear what I was talking about.)

I'm going to use a free text field, partly because it's less expensive to implement (particularly this late in the release cycle), and partly because it allows the user to supply more information. Some questions:

1. Do you want a single-line text field of a multiple-line textarea field?

2. What do you want the (short) field label to be (I suggest something more general like "Notes" rather than the more restrictive "Version" in case the users need to put other things in there)?

1. Multiple-line text field is preferred.
2. "Comments" should be fine.

When can I clear out the test data to install the new table definitions?

Please proceed to do it now.

Support for the new field has been installed.

Please add the new field as the last column of the translation job queue.

Per William:
Please add the new field to the report.

In both the report and on the queue, please truncate the display of comments that are too long with an ellipsis.

Column added to report and queue pages.

Please change the "Change Type" label of the Add Job window to read "Type of Change". Also, please make similar changes to the corresponding column in the Job queue page and the column in the translation queue report.

Modification implemented on DEV.

The column headings look good but the text label on the form flows to the next line thus affecting some of the labels below it. They are not aligned well.

That's why I used "Change Type" on the form.

Okay. Then switch it back to "Change Type" on the form.

Done.

As a general note, we can have a discussion at some point about modifying the common style rules for the reports and their forms. There are always tradeoffs (for example, if you make the width available for field labels too large, most forms – with the size of labels we typically use – will look silly). I'm happy to make such general changes as long as everyone agrees on them. The one path I'd like to avoid going down is customizing each report/form to have its own style rules.

Verified on DEV.

Verified on QA

On STAGE, when you attempt to submit a job without making any changes to the Change Type and Assigned To fields, you get the following error message. It appears to be the same error message on QA. I understand that there shouldn't be any email generated in such circumstance but it would be good to have the error message say so. I am not reopening this ticket because I assume it is probably too late to make changes at this point.

502 - Web server received an invalid response while acting as a gateway or proxy server.

There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.

I am unable to reproduce this behavior.

I was able to reproduce the error a few minutes ago on stage. See attached screenshot.

You may try this:

1. Go to the Translation Job Queue
2. Click on the CDR ID of any of the jobs in the queue.
3. Make no changes but hit the submit button at the top of the page. The error should display.

Duplicate Post.

Ah, I see. I had tried to reproduce it "without making any changes to the Change Type and Assigned To fields" but as you pointed out in your later comment, you can only reproduce it if you make no changes at all. This is indeed a bug, but not a terribly serious one, as there's not much incentive for saving the record if there are no changes to be saved. Too bad we didn't catch this during UAT.

I don't know if you fixed the problem but it doesn't come up again on QA and PROD. I haven't checked STAGE.

When trying to add a Module document to the translation queue, "invalid english_id('751850')" is displayed (see attached screenshot). It appears that we failed to test with modules on the lower tiers as the same error is on QA.

That's because we decided to only include published English summaries in the set of documents to be included, and the modules don't show up in the pub_proc_cg table (which is where we look to see what's published).

Since modules go through the same translation process, can we modify what is included so that adding modules don't return error messages? I think it would be good to include "publishable" documents instead of just "published" documents.

Sure, but you'll need to open another ticket to do that.

Will do. Thanks!