-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow AVLJs to perform judge tasks on legacy appeals #11977
Conversation
Code Climate has analyzed commit 022329f and detected 0 issues on this pull request. View more on Code Climate. |
def json_tasks(tasks, role) | ||
::WorkQueue::LegacyTaskSerializer.new(tasks, is_collection: true, params: { role: role }) | ||
def json_tasks(tasks, user, role) | ||
::WorkQueue::LegacyTaskSerializer.new(tasks, is_collection: true, params: { user: user, role: role }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ensures the current user gets passed to task.available_actions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I understand this enough to approve, but if a legacy appeals issues all have dispositions is the way to determine if the attorney is done, this makes sense as a way to determine the class type. I am confused about the part where the task type would change if it's not a judge that is logged in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like Sally, I'm not sure I understand the subtleties of the business rules. Mostly I think if the logic can be encapsulated in well-named methods on the affected classes, that will help clarify.
@@ -27,7 +27,7 @@ def tasks_from_vacols_tasks(vacols_tasks, user = nil) | |||
vacols_tasks.zip(vacols_appeals).map do |task, appeal| | |||
user = validate_or_create_user(user, task.assigned_to_css_id) | |||
|
|||
task_class = (user&.vacols_roles&.first&.downcase == "judge") ? JudgeLegacyTask : AttorneyLegacyTask | |||
task_class = (user.judge_in_vacols? && appeal.attorney_case_review) ? JudgeLegacyTask : AttorneyLegacyTask | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Crux of the change. If a legacy case is assigned to an avlj in vacols and the case has already been reviewed by an attorney, we will consider this task to be a JudgeLegacyTask.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤠 approve!
The changes look correct to me, but I'm not sure the feature test is the best way to exercise them. What about a test on tasks_for_user
and/or tasks_by_appeal_id
in legacy_work_queue_spec.rb
? If the complete flow demonstrated in judge_checkout_flow_spec.rb:298
is necessary, keep it, but it seems to me you just need to test whether the LegacyWorkQueue returns the correct task type when the user's a judge in VACOLS and the appeal has an associated AttorneyCaseReview.
Resolves #11971
Description
Due to the way we determine task type for legacy work queues, acting judges have been receiving judge tasks, but cannot act upon them. This PR classes any appeal with an associated AttorneyCaseReview assigned to someone with a judge vacols_role as a JudgeTask, allowing AVLJs to review legacy cases.