[Tech Spec] Allow attorneys and judges to edit decision issues and set dispositions

[anyakhvost]

Currently, attorneys and judges can set dispositions on request issues but have no way of editing these issues. We need to introduce decision issues to allow for that.

Allowed Scenarios:

1. one request issue to one decision issue
2. one request issue to many decision issues
3. one decision issue to many request issue
4. many decision issues to many request issues (maybe?)

Assumptions:

1. There will always be at least one decision issue for each decided request issue
2. There will be no disposition on the request issue. Disposition on the request issue is a function of the decision issues.
3. Remand reasons will live within a decision issue
4. EP will be created based off the decision issues
5. Each request issue must have a decision

Parameter example for scenario 1:

"issues": [{
  "decision_issues": [ 
       { "disposition": "allowed", "description": "something", "request_issue_ids": ["1"] }
   ]
}]

Parameter example for scenario 2:

"issues": [{
  "decision_issues": [ 
       { "disposition": "allowed", "description": "something", "request_issue_ids": ["1"] },
       { "disposition": "remanded", "description": "something", "remand_reasons": [ "code": "incorrect_notice_sent", "post_aoj": "true"  ], "request_issue_ids": ["1"] }
   ]
}]

Parameter example for scenario 3:

"added_decision_issues": [{
  "decision_issues": [ 
       { "disposition": "allowed", "description": "something",  "request_issue_ids": ["1", "2"] }
   ]
}]

Parameter example for scenario 4:

"added_decision_issues": [{
  "decision_issues": [ 
       { "disposition": "allowed", "description": "something",  "request_issue_ids": ["1", "2"] },
       { "disposition": "remanded", "description": "something",  "request_issue_ids": ["1", "2"],
       "remand_reasons": [ "code": "incorrect_notice_sent", "post_aoj": "true"  ] }
   ]
}]

Tech notes:

1. Add BE validation to validate request issue disposition based on the combination of dispositions for the decision_issues
2. Modify case_reviews_controller to accept new parameter format and hide it behind a feature flag in order not to break existing code in production

Additional Columns and migrations:

1. Implement many-to-many relationship for decision issues and request issues: [BE] Create a join model so request issues and decision issues can have many-to-many relationship #7884
2. Implement a migration to create a decision_issue for each request_issue that is currently in production and that has a disposition
3. Currently, remand_reasons table references request_issues. If we start using decision_issues, we need to migrate remand_reasons to reference decision_issues instead.
4. Allow null rating_issue_reference_id in decisions - done

[shanear]

Add benefit_type column to the decision_issues table (clarify this?)

Yeah, there are some additional questions here. Like, can there be a decision with a benefit type different from the request? For HLRs and SCs the benefit type is specified up front.

[shanear]

Implement a migration to create a decision_issue for each request_issue that is currently in production

I would think a request issue would not have a decision issue until it's actually been decided, meaning there should not be a decision issue for all request issues

[shanear]

Add notes column to the decision_issues table

I would prefer to add this when it becomes needed in the UI. I think this ticket should be about setting up required structure

[pkarman]

@shanear wrote:

I would think a request issue would not have a decision issue until it's actually been decided, meaning there should not be a decision issue for all request issues

is it fair to provision a decision issue to hold the disposition ahead of time though? I.e. it would be a placeholder for a decision that will happen eventually. The contention_reference_id is what RatingIssue will look it up by and associate it later.

EDIT: I see that contention_reference_id is only used to locate the original RequestIssue. Provisioning ahead of time requires knowing in advance what the eventual decision rating_issue_reference_id will be. There are ways to make rating_issue_reference_id not null and allow for pre-decision provisioning, if it is important to capture the disposition before the decision is made.

[shanear]

is it fair to provision a decision issue to hold the disposition ahead of time though? I.e. it would be a placeholder for a decision that will happen eventually. The contention_reference_id is what RatingIssue will look it up by and associate it later.

If this helps, I'm cool with this. I just don't think we should create the decision_issue record early without a reason to do so. I don't think holding the disposition that good of a reason, since it wouldn't have a disposition before a decision is made.