Rename return-requirements route return-versions #1431
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-4257 > Part of the work to migrate managing returns from NALD to WRLS When we first got started on the work for creating and managing 'requirements for returns', 'requirements' was the term being used in all conversations. So, that is what we used as the root URL for all endpoints related to it. However, things started becoming confused when we realised depending on the context, 'return requirements' can mean two different things. Within the app, and amongst the team, it is a general term that refers to all the details needed to determine how and when a licensee should submit their returns: the 'requirements for returns'. In the code and database, it means the child record of a 'return version'. The return version holds the start and end dates of when the requirements apply, and why they were created. But the child 'return requirements' hold the detail that will be used to generate the return logs licensees will submit against. When you go through the set up journey you are not creating a new return requirement, you're creating a new return version and its child return requirement records. When you click a 'Requirement for returns' entry in the UI, the view is not of a return requirement, but a return version and all its child return requirement records. We've fallen into the same trap as the legacy code of confusing our naming. As the journey is setting up a new return version, `/return-versions` should be the root. The same goes for `GET /return-versions/a8a0dbbd-f7bf-47c0-887f-c4e9ad43ab52` to view a return version. So, this is a housekeeping change to rename the root and ensure associated presenters, services and validators are also correctly named and located.
Cruikshanks
added
the
housekeeping
Cruikshanks
added a commit
to DEFRA/water-abstraction-acceptance-tests
that referenced
this pull request
Oct 22, 2024
https://eaflood.atlassian.net/browse/WATER-4257 DEFRA/water-abstraction-team#126 > Part of the work to migrate managing returns from NALD to WRLS When we first started working on creating and managing 'requirements for returns,' 'requirements' was the term used in all conversations. So, we used it as the root URL for all related endpoints. However, things started getting confusing when we realised that, depending on the context, 'return requirements' can mean two different things. Within the app and amongst the team, it is a general term that refers to all the details needed to determine how and when a licensee should submit their returns: the 'requirements for returns'. In the code and database, it means the child record of a 'return version'. The return version holds the start and end dates of when the requirements apply and why they were created. But the child 'return requirements' hold the details used to generate the return logs that licensees will submit against. When you go through the set-up journey, you are not creating a new return requirement; you're creating a new return version and _all_ its child return requirement records. When you click a 'Requirement for returns' entry in the UI, the view is not of a return requirement but of a return version and all its child return requirement records. We've fallen into the same trap as the legacy code of confusing our naming. As the journey sets up a new return version, `/return-versions` should be the root. The same goes for `GET /return-versions/a8a0dbbd-f7bf-47c0-887f-c4e9ad43ab52` to view a return version. This is a housekeeping change to rename the scenarios and ensure they work after the [changes to water-abstraction-system](DEFRA/water-abstraction-system#1431).
Cruikshanks
added a commit
to DEFRA/water-abstraction-acceptance-tests
that referenced
this pull request
Oct 22, 2024
https://eaflood.atlassian.net/browse/WATER-4257 DEFRA/water-abstraction-team#126 > Part of the work to migrate managing returns from NALD to WRLS When we first started working on creating and managing 'requirements for returns,' 'requirements' was the term used in all conversations. So, we used it as the root URL for all related endpoints. However, things started getting confusing when we realised that, depending on the context, 'return requirements' can mean two different things. Within the app and amongst the team, it is a general term that refers to all the details needed to determine how and when a licensee should submit their returns: the 'requirements for returns'. In the code and database, it means the child record of a 'return version'. The return version holds the start and end dates of when the requirements apply and why they were created. But the child 'return requirements' hold the details used to generate the return logs that licensees will submit against. When you go through the set-up journey, you are not creating a new return requirement; you're creating a new return version and _all_ its child return requirement records. When you click a 'Requirement for returns' entry in the UI, the view is not of a return requirement but of a return version and all its child return requirement records. We've fallen into the same trap as the legacy code of confusing our naming. As the journey sets up a new return version, `/return-versions` should be the root. The same goes for `GET /return-versions/a8a0dbbd-f7bf-47c0-887f-c4e9ad43ab52` to view a return version. This is a housekeeping change to rename the scenarios and ensure they work after the [changes to water-abstraction-system](DEFRA/water-abstraction-system#1431).
Cruikshanks
added a commit
that referenced
this pull request
Nov 15, 2024
https://eaflood.atlassian.net/browse/WATER-4283 Spotted when prepping for a discussion about return versions setup that going back from the 'Use previous requirements for returns' page in the return version setup journey results in a 404. Basically, when we carried out a refactor to [Rename return-requirements route return-versions](#1431) we didn't spot that the back link had been built differently than all the other pages in the journey. So, it is still trying to go back to the defunct route. This changes fixes it.
Cruikshanks
added a commit
that referenced
this pull request
Nov 18, 2024
https://eaflood.atlassian.net/browse/WATER-4283 We noticed when prepping for a discussion about return version setup that going back from the 'Use previous requirements for returns' page in the return version setup journey results in a 404. Basically, when we carried out a refactor to [Rename return-requirements route return-versions](#1431), we didn't spot that the backlink had been built differently than all the other pages in the journey. So, it is still trying to go back to the defunct route. This change fixes it.
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-4257
DEFRA/water-abstraction-team#126
When we first started working on creating and managing 'requirements for returns,' 'requirements' was the term used in all conversations.
So, we used it as the root URL for all related endpoints. However, things started getting confusing when we realised that, depending on the context, 'return requirements' can mean two different things.
Within the app and amongst the team, it is a general term that refers to all the details needed to determine how and when a licensee should submit their returns: the 'requirements for returns'.
In the code and database, it means the child record of a 'return version'. The return version holds the start and end dates of when the requirements apply and why they were created. But the child 'return requirements' hold the details used to generate the return logs that licensees will submit against.
When you go through the set-up journey, you are not creating a new return requirement; you're creating a new return version and all its child return requirement records. When you click a 'Requirement for returns' entry in the UI, the view is not of a return requirement but of a return version and all its child return requirement records.
We've fallen into the same trap as the legacy code of confusing our naming. As the journey sets up a new return version,
/return-versionsshould be the root. The same goes forGET /return-versions/a8a0dbbd-f7bf-47c0-887f-c4e9ad43ab52to view a return version.This is a housekeeping change to rename the root and ensure that associated presenters, services, and validators are also correctly named and located.