Add copy existing rtn req. option to setup journey #1081
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-4355 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to copy data from an existing return requirement when setting up a new one. However, the option must only appear if one exists to copy. This change adds the logic to check for existing returns and the option to the "How do you want to set up the returns" page.
We're already fetching a bunch of data for the licence during the initiate process. We could have built a service to confirm if return versions exist for a licence. This would then need to be called in the `Setup` and `SubmitSetup` services. But then we'd need another service to actually fetch details for each version in order to have something to display to the user. Of course, this service could support both functions. But then we're fetching the same data twice, but using it only once. Fetching and storing it at this point means we make the call once and then it is always available. There is a chance it isn't used, for example the user bails early or selects a different path. But we think this solution is the simplest and easiest to maintain out of the options.
Using this we can determine whether to show the option or not
Make sure we don't reject the value as invalid!
Cruikshanks
added a commit
that referenced
this pull request
Jun 7, 2024
SHould really have been done in [Add copy existing rtn req. option to setup journey](#1081) 😬😳
Cruikshanks
added a commit
that referenced
this pull request
Jun 9, 2024
SHould really have been done in [Add copy existing rtn req. option to setup journey](#1081) 😬😳
Cruikshanks
added a commit
that referenced
this pull request
Jun 10, 2024
SHould really have been done in [Add copy existing rtn req. option to setup journey](#1081) 😬😳
Cruikshanks
pushed a commit
that referenced
this pull request
Jun 10, 2024
https://eaflood.atlassian.net/browse/WATER-4283 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to copy data from an existing return requirement when setting up a new one. We [made the option available](#1081) in the `/setup` page. When a user selects this option they'll be taken to the `Select an existing return requirement from` page. This change is about completing that page and the feature. - add the controls to the page. These will be dynamically generated based on the licences current return versions - add validation to the page - retrieve the requirements for the selected return version and populate the session with them Once the page has completed it's work the user will be redirected to the `/check` page where they can see the results of their action.
Cruikshanks
added a commit
that referenced
this pull request
Jun 10, 2024
https://eaflood.atlassian.net/browse/WATER-4283 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to copy data from an existing return requirement when setting up a new one. We [made the option available](#1081) in the `/setup` page. We then implemented the logic to fetch the existing data and transform it into a something that can be stored in the session for later persisting back as a new record. One of the new features we're enabling with our takeover is the ability to record where a return requirement is _not_ needed. Our new journey allows for this. When this happens though, we'll need to persist a return version to record it. It will be 'current' but it will have no return requirements linked to it. Because of this we need to tweak the query which fetches which return versions can be copied from to exclude those without any return requirements.
Cruikshanks
added a commit
that referenced
this pull request
Jun 10, 2024
https://eaflood.atlassian.net/browse/WATER-4283 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to copy data from an existing return requirement when setting up a new one. We [made the option available](#1081) in the `/setup` page. We then implemented the logic to fetch the existing data and transform it into something that can be stored in the session for later persisting as a new record. One of the new features we're enabling with our takeover is the ability to record where a return requirement is _not_ needed. Our new journey allows for this. When this happens, though, we'll need to persist a return version to record it. It will be 'current' but it will have no return requirements linked to it. Because of this, we need to tweak the query that fetches which return versions can be copied from to exclude those without any return requirements.
Cruikshanks
added a commit
that referenced
this pull request
Jun 12, 2024
https://eaflood.atlassian.net/browse/WATER-4283 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to copy data from an existing return requirement when setting up a new one. We [made the option available](#1081) in the `/setup` page. We then did the actual work of allowing users to select the return requirements to copy and saving them to the session in [Complete Select existing return requirement page](#895). But we've since learnt that the title we used for the page is not right. This change corrects it.
Cruikshanks
added a commit
that referenced
this pull request
Jun 12, 2024
https://eaflood.atlassian.net/browse/WATER-4283 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to copy data from an existing return requirement when setting up a new one. We [made the option available](#1081) in the `/setup` page. We then did the actual work of allowing users to select the return requirements to copy and saving them to the session in [Complete Select existing return requirement page](#895). But we've since learned that the title we used for the page is not right. This change corrects 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-4355
We want to be able to offer users the option to copy data from an existing return requirement when setting up a new one. However, the option must only appear if one exists to copy.
This change adds the logic to check for existing returns and the option to the "How do you want to set up the returns" page.
Note about where we fetch the return versions
We're already fetching a bunch of data for the licence during the initiate process. We could have built a service to confirm if return versions exist for a licence. This would then need to be called in the
SetupandSubmitSetupservices.But then we'd need another service to actually fetch details for each version in order to have something to display to the user. Of course, the fetch service could support both functions. But then we're fetching the same data twice, but using it only once.
Fetching and storing it at this point means we make the call once and then it is always available. There is a chance it isn't used, for example, if the user bails early or selects a different path. But we think this solution is the simplest and easiest to maintain out of the options.