Closed lpciferri closed 5 years ago
@laurjpeterson @sneha-pai @lowellrex I thought through a couple of options here.
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:
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:
Let's discuss a bit, and then if we go the second route, I can mock something up.
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?
@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.
@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.
Looks good! Can you remind me what the user clicks on to get to this modal? What do you think that should look like?
Yes @laurjpeterson ! I should've referenced #7903 . The user would trigger this modal by clicking Edit next to the Document ID field.
Thanks! Added this screenshot to the main ticket too. This one's good to go!
Hello! While trying to understand how I would implement this, I came up with a few questions:
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
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.
@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
sounds good - thank you!
Related - document ID validations ticket: https://github.com/department-of-veterans-affairs/caseflow/issues/5993
Opened a new ticket to implement next steps
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:
AC