-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display the purpose desc (alias) in rtn req view #1183
Merged
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-4582 > Part of the return requirements set up work When setting up new return requirements, you are required to select one or more purposes. By default, we use the purpose description. But because the returns are intended to reflect what is on the licence document, sometimes there is a discrepancy between how the system describes the purpose and how it was recorded in the document. To deal with this, NALD has the concept of a 'purpose alias'. This is an optional alternate description that should be used when referring to the purpose on a return requirement. This change updates the return requirements page to display the purpose description (alias).
This supports us moving away from database cleaning before each tes.
We can mock the response from the Fetch service without needing to interact with the DB.
We're actually finding and returning a return version. SO, makes sense to rename the service to correspond with what it is doing.
We also do some housekeeping to bring it inline with the `ViewService` and `ReturnRequirementsPresenter` tests.
The properties were renamed to make them less verbose. However, in all other fetch services based on models and their relationships we have stuck with the relationship names. Working on the principle of least surprise we're taking the opportunity to refactor the names to follow the convention of other services.
The changes we made to the seeder broke the test because it depended on the seeder using a hard code licence ID. We've fixed it by having the seeder create the licence properly (avoiding any database conflicts) which has also meant we could remove database cleaner from it as well.
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-4582
When setting up new return requirements, you are required to select one or more purposes. By default, we use the purpose description. But because the returns are intended to reflect what is on the licence document, sometimes there is a discrepancy between how the system describes the purpose and how it is recorded in the document.
To deal with this, NALD has the concept of a 'purpose alias'. This is an optional alternate description that should be used when referring to the purpose on a return requirement.
This change updates the return requirements page to display the purpose description (alias).