Incorrect status showing on licence set up page #1363
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://eaflood.atlassian.net/browse/WATER-4671 An issue has been found during QA where if you find a licence that has no existing returns. Then create 2 or 3 "no return required" journeys followed by a new "return required" journey. That the statuses are not updating correctly. This PR will fix the issue.
Jozzey
requested review from
Cruikshanks,
robertparkinson,
jonathangoulding,
Beckyrose200 and
rvsiyad
Jozzey
added a commit
that referenced
this pull request
Sep 27, 2024
https://eaflood.atlassian.net/browse/WATER-4671 Carrying on from the issue that was fixed in #1363 another issue has been found with the status. The problem can be recreated by: 1. New requirements added with a start date of 01/04/2022 that will have no end date. 2. Another new requirement is added with a start date 1 day later on the 02/04/2022. This will put an end date on the one created in step 1. of 01/04/2022. So the first will start and end on the same day. 3. Set up another new requirement with a start date of the 01/04/2022. This new requirement should replace the first but instead is just added and does not replace anything. There are 2 issues that together appear to be causing this problem. The first was the order in which the checks were being carried out to see where the new return fitted in. The second was that it wasn’t expecting a return with a start and end date to be the same. This PR should fix those problems.
Jozzey
added a commit
that referenced
this pull request
Sep 27, 2024
https://eaflood.atlassian.net/browse/WATER-4671 Carrying on from the issue that was fixed in #1363 another issue has been found with the status. The problem can be recreated by: 1. New requirements added with a start date of 01/04/2022 that will have no end date. 2. Another new requirement is added with a start date 1 day later on the 02/04/2022. This will put an end date on the one created in step 1. of 01/04/2022. So the first will start and end on the same day. 3. Set up another new requirement with a start date of the 01/04/2022. This new requirement should replace the first but instead is just added and does not replace anything.  There are 2 issues that together appear to be causing this problem. The first was the order in which the checks were being carried out to see where the new return fitted in. The second was that it wasn’t expecting a return with a start and end date to be the same. This PR should fix those problems.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/WATER-4671
An issue has been found during QA where if you find a licence that has no existing returns. Then create 2 or 3 "no return required" journeys followed by a new "return required" journey. That the statuses are not updating correctly.
This problem is related to the issue that wasn't quite fixed in this PR #1325
The problem was caused by the logic that determines if there are previous return versions. Previously, it relied on the session data. However, this has proved unreliable when returns have been generated via the "no returns required" journey. Therefore, I have amended this logic to check the actual
return_versionstable rather than the session data.