Use abstraction data to create return requirements #1107
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
Cruikshanks
force-pushed
the
ret-req-use-abstraction-data
branch
5 times, most recently
from
edcc181 to
1df7ab7
Compare
https://eaflood.atlassian.net/browse/WATER-4442 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to generate return requirements from the licence's abstraction data. On the `/setup` page they can select this option and the service is expected to generate return requirements using the source abstraction data against the licence. The other options are copy existing return requirements or set them up manually. This change is about implementing the logic behind the scenes for when 'Start by using abstraction data' is selected. To look at the licence's abstraction data, generate return requirements and add them to the session before redirecting the user to the `/check` page.
We are going to need these in what we are building so move them to static lookups where they can be reused.
We don't need a separate service to return this information. We can do it at the same time we fetch the rest of the licence's abstraction data.
Tests coming on a bit! (Got it working and don't want to lose the work!)
Keeps things consistent and avoids any confusion that this returns the data 'as-is' from the DB.
Looking at the tests we going to find it easier if we split the fetch from the transform. But that means adding another service which is specific only to setup so now seems a good time to move things into a /setup folder.
This should make writing the tests much easier.
Cruikshanks
force-pushed
the
ret-req-use-abstraction-data
branch
from
701a6e7 to
15d2a3d
Compare
We need _so much_ data in _so many_ places to test this service we've opted to add a seeder.
Cruikshanks
force-pushed
the
ret-req-use-abstraction-data
branch
from
15d2a3d to
98d2a4b
Compare
This was what caused us to do all the model fixes! Need to work out the collection and reporting frequencies correctly.
Cruikshanks
added a commit
that referenced
this pull request
Jun 19, 2024
https://eaflood.atlassian.net/browse/WATER-4512 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to generate return requirements from the licence's abstraction data. On the `/setup` page, they can select this option and the service is expected to generate return requirements using the source abstraction data against the licence. We added support for this in [Use abstraction data to create return requirements](#1107). But after double checking the test scenarios we've made a mistake in the logic. We've determined a return requirement will be linked to a purpose that is two-part tariff purely based on the purpose's two-part tariff flag. This effects what collection and reporting cycle we pick for the return requirement. But the purpose can only be interpreted as two-part tariff if the licence also has a two-part tariff agreement. So, the purpose might be spray irrigation, for example, which is flagged as two-part tariff. But if the licence doesn't also have a two-part tariff agreement we need to ignore that when determining the cycles for the return requirement. This change fixes our logic in `GenerateFromAbstractionDataService`.
Cruikshanks
added a commit
that referenced
this pull request
Jun 20, 2024
https://eaflood.atlassian.net/browse/WATER-4512 > Part of the work to replace NALD for handling return requirements We want to be able to offer users the option to generate return requirements from the licence's abstraction data. On the `/setup` page, they can select this option, and the service is expected to generate return requirements using the source abstraction data against the licence. We added support for this in [Use abstraction data to create return requirements](#1107). But after double-checking the test scenarios we've made a mistake in the logic. We've determined a return requirement will be linked to a purpose that is two-part tariff purely based on the purpose's two-part tariff flag. This effects the collection and reporting cycle we pick for the return requirement. But the purpose can only be interpreted as two-part tariff if the licence also has a two-part tariff agreement. So, the purpose might be spray irrigation, for example, which is flagged as two-part tariff. But if the licence doesn't also have a two-part tariff agreement we need to ignore that when determining the cycles for the return requirement. This change fixes our logic in `GenerateFromAbstractionDataService`.
Cruikshanks
added a commit
that referenced
this pull request
Jul 10, 2024
https://eaflood.atlassian.net/browse/WATER-4442 > Part of the work to replace NALD for handling return requirements In [Use abstraction data to create return requirements](#1107) we added the logic to the return requirements set up journey that allows a user to generate return requirements from a licence's existing abstraction data. One of the scenarios we had to tackle was how to populate the site description for a return requirement that has multiple points. At the time, we went with concatenating them all using ' - '. After some additional testing, it has been decided it is clearer if we just use the first available site description. What ever we opt for we can see users will change it anyway. Just picking one at least improves how the return requirement is displayed on the page.
Cruikshanks
added a commit
that referenced
this pull request
Jul 10, 2024
https://eaflood.atlassian.net/browse/WATER-4442 > Part of the work to replace NALD for handling return requirements In [Use abstraction data to create return requirements](#1107) we added the logic to the return requirements set up journey that allows a user to generate return requirements from a licence's existing abstraction data. One of the scenarios we had to tackle was how to populate the site description for a return requirement that has multiple points. At the time, we went with concatenating them all using ' - '. After some additional testing, it has been decided that it is clearer if we just use the first available site description. Whatever we opt for we can see users will change it anyway. Just picking one at least improves how the return requirement is displayed on the page.
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-4442
We want to be able to offer users the option to generate return requirements from the licence's abstraction data. On the
/setuppage, they can select this option and the service is expected to generate return requirements using the source abstraction data against the licence. The other options are to copy existing return requirements or set them up manually.This change is about implementing the logic behind the scenes when 'Start by using abstraction data' is selected. We fetch the licence's abstraction data, generate return requirements from it, and save them to the session before redirecting the user to the
/checkpage.