fix: CE-1150-multiple-action-taken-saved-to-the-same-complaint

[dk-bcps]

Description

This PR fixes an issue when the app does not handle well concurrent changes in complaint actions

Fixes # (CE-1150)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Open a CEEB complaint that does not have a decision section populated for edit in two browser tabs. Enter decision data and click save. Enter different decision data (select different action) in the second tab. When you click save on the second tab the app displays an error message and recommends to refresh the page.
  In the complaint list try to filter by the action you entered in the first tab. The app should find your complaint.
  In the complaint list try to filter by the action you entered in the second tab (that gave you an error). Your complain should not appear in the list.

Checklist

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Further comments

---

Thanks for the PR!

Deployments, as required, will be available below:

• Frontend
• Backend

Please create PRs in draft mode. Mark as ready to enable:

• Analysis Workflow

After merge, new images are deployed in:

• Merge Workflow

[afwilcox]

I discussed this change with @nayr974 and we both agree that we think that this validation should be moved out of the reducer and into the case management backend

I'm guessing that the case management backend is probably doing an upsert and you just need to make sure that the action doesn't exist before inserting it (and then you can return a message if it did)

[nayr974]

I discussed this change with @nayr974 and we both agree that we think that this validation should be moved out of the reducer and into the case management backend

I'm guessing that the case management backend is probably doing an upsert and you just need to make sure that the action doesn't exist before inserting it (and then you can return a message if it did)

To elaborate a bit, having the validation in the back-end:

• Prevents an extra round trip between the front end back end
• Significantly reduces the chance of a timing issue, if somebody is on a cell connection and it takes many seconds to fetch the record, validate, and send the update another user could commit a change during that window that avoids the validation
• Removes business logic from the Redux reducers. I don't think it's a good pattern to put validation and logic in the reducers, for code maintainability they should be as simple as possible and having validation here is outside of their intended purpose

Let us know if you want to chat or make a case against moving it to the back-end :)

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud