Caseflow: Edit document ID in Queue

[laurjpeterson]

Background

We've gotten 3 different attorneys asking how to edit Document ID. How might we help attorneys edit Document ID in Case details?

Mocks

Context: These mocks show what editing individual data points in Case Details could look like. As we're reviewing these designs, let's consider how they would scale across different editing scenarios.

User first clicks "Edit" from Case details:

Editing modals in case details consist of a:

• Header (format: "Edit" + "(data being edited)"
• Optional instructional text to describe what the user is editing and the impact (if applicable)
• Text field pre-filled with the values being edited
• Save/cancel actions

• When the modal opens, we display a focused view of the text field so that the user can quickly edit.
• We enable the save button when the user changes something in the text field. This is a visual queue to reinforce that we acknowledge their change.

• Error state (above).
  
  
  
  • Open question: How can we make this error message more helpful? From my understanding of the document ID formats in #5993, they can vary based on new and old cases. Ideally, we would give the user the correct format so they can fix the error. How many possible formats are there?
  
  

AC

• When a user clicks Edit next to the Decision Document ID field, the modal (above) appears on top of the Case Details page.
• When the modal appears, the text field is displayed in a focused state.
• When the user makes any edit, we enable the save button.
• Clicking "Save" validates the document ID field (see #5993 for validations that were implemented in the attorney-judge checkout flow).
  
  
  
  • If the format is invalid, present an error message.
  
  
• Clicking "Save" returns the user to the Case Details page where they will see the change reflected.
• Clicking "Cancel" or "x" returns the user to the Case Details page where they won't see any change reflected.

[allyceh]

@laurjpeterson @sneha-pai @lowellrex I thought through a couple of options here.

1. In-line editing: Document ID is styled like veteran ID field. I created a couple of mocks on the veteran ID field to demonstrate what in-line editing behavior could be.

We could remove the outline around the document ID and veteran ID fields (for visual consistency).

When the user hovers over an editable field, the grey box around document ID would appear, indicating to the user that the field is editable. This would be a new pattern.

When the user clicks into the field, it would turn grey, indicating that it's being edited. A cursor would appear, and they could edit the number. They would press enter to save and update the document ID.

Open questions:

• Is this accessible?
• Is this a pattern that we would want to continue using across queue?

1. Edit in a modal: Edit document ID in the Edit AOD modal.

We could move the "Edit" link away from "Type" to next to "About the case". When the user clicks "Edit", they would see a re-designed modal that allows them to either grant AOD or edit the document ID number.

Open questions:

• Granting AOD feels a bit disconnected from editing the document ID number, so I might question putting it all in one modal. However, this design would nest all "the things" that a user needs to edit or take action on in one modal.

Let's discuss a bit, and then if we go the second route, I can mock something up.

[laurjpeterson]

I agree that in option 2, granting AOD seems disconnected from editing document ID.

I prefer option 1, but how would users know to click to edit it? Would it be too crowded to have the edit pencil icon near the copy icon? When the edit pencil icon is clicked, then the inline edit you designed would be there.

Another note I just thought of - we should have the same validations that exist when the attorney enters the document ID in their checkout flow to ensure it's in a valid format. Could we use the existing Caseflow error patterns if a user inputs a doc ID in the wrong format?

[allyceh]

@laurjpeterson They would know that any field in Caseflow is "editable" when they see a grey box appear around it. That would be their cue that it's clickable/editable. I don't think they'd know by looking at the document ID field initially (and without hovering over it) that it's editable. It's more of a feature they "discover"; so, that might not be the approach we want. But, it does save us some space and crowd the page less.

I will explore using the pencil icon next to the document ID field as well as validations. @sneha-pai and I were just chatting today about situations where we'd use the word "edit" versus "edit" with a pencil icon versus just the pencil icon. Perhaps this is a good opp to define use cases around those and preferred approaches.

[allyceh]

@laurjpeterson @lowellrex Mocks + AC have been updated (above) for document ID editing! I have a couple of open questions documented.

@sneha-pai Would love your eyes on this too as this is what editing could look like across Case Details.

[laurjpeterson]

Looks good! Can you remind me what the user clicks on to get to this modal? What do you think that should look like?

[allyceh]

Yes @laurjpeterson ! I should've referenced #7903 . The user would trigger this modal by clicking Edit next to the Document ID field.

[laurjpeterson]

Thanks! Added this screenshot to the main ticket too. This one's good to go!

[monfresh]

Hello! While trying to understand how I would implement this, I came up with a few questions:

• To confirm, this would appear on a page such as http://localhost:3000/queue/appeals/fc17e01c-4469-41a9-9568-1fabf3b71846, right?
• Are the terms "appeal" and "case" interchangeable?
• The mocks on this issue suggest that an appeal/case can only have one Document ID, and that the Document ID is a main attribute of an appeal/case, just like Docket Number, for example. Is that correct?
• Does this issue apply to both legacy and AMA appeals? If not, which one does it apply to?

If an appeal can only have one Document ID, then the app isn't designed that way currently. From what I can tell, the Document ID is an attribute of an "attorney case review". So, in order to get the Document ID associated with an appeal, we have to go through the appeal's attorney_case_reviews which is not a direct association, but a helper method that fetches the attorney case reviews that belong to the appeal's tasks.

So, an appeal has many tasks, and tasks have many attorney case reviews, which have an attribute called document_id. Based on the data in the local setup, it looks like all tasks associated with an appeal all have the same Document ID. Similarly, it looks like all appeals only have one attorney case review because although an appeal can have multiple tasks, only one task is an attorney task. The code suggests that it's possible for a task to have multiple attorney case reviews, but I haven't seen an example of that locally.

Will that always be the case in real life? If so, would it make more sense to save the Document ID on the Appeal model? It would certainly be more efficient.

Thoughts?

cc @aroltsch

[aroltsch]

To confirm, this would appear on a page such as http://localhost:3000/queue/appeals/fc17e01c-4469-41a9-9568-1fabf3b71846, right?

Yes.

Are the terms "appeal" and "case" interchangeable?

Yes.

The mocks on this issue suggest that an appeal/case can only have one Document ID, and that the Document ID is a main attribute of an appeal/case, just like Docket Number, for example. Is that correct?

The document ID lives on the attorney_case_reviews table. An appeal can have many attorney_case_reviews with the latest being the valid one.

Does this issue apply to both legacy and AMA appeals? If not, which one does it apply to?

It applies to both. attorney_case_reviews table contains both legacy and AMA attorney reviews. When it comes to legacy, we will also need to update the document ID in VACOLS (decass table)

Would it make more sense to save the Document ID on the Appeal model? It would certainly be more efficient.

I think it makes perfect sense. I think it also makes sense to have appeal_id in attorney_case_reviews table instead of a task_id but we can change that at a later day when we deprecate VACOLS DAS system (decass). For legacy cases task_id is a pointer to a Vacols decass table, for AMA it is a pointer to Caseflow tasks table.

[aroltsch]

@allyceh @laurjpeterson Moncef and I chatted about this ticket yesterday and we will tackle this ticket in multiple steps:
step 1. Allow editing of the latest document ID for AMA cases. Attorneys and judges would be able to edit a document ID at any point in time.
step 2. Allow editing of the latest document ID for legacy cases. This will update attorney_case_reviews table and decass table.
step 3. Only allow attorneys who wrote up a case review to edit a document ID and only a judge who is reviewing a case.

cc @monfresh

[laurjpeterson]

sounds good - thank you!

[laurjpeterson]

Related - document ID validations ticket: https://github.com/department-of-veterans-affairs/caseflow/issues/5993

[aroltsch]

Opened a new ticket to implement next steps