-
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
Refactor billing account contact details to model #1444
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-4057 We currently display a billing account's contact details when viewing a bill in a bill run. This is achieved by the `FetchBillingAccountService` and the `ViewBillPresenter`. We have to show the _exact_ same details in the _exact_ same format as part of reviewing the return match and allocation results in a two-part part tariff bill run. And we strongly suspect there will be more pages in the coming months that will also need to display this. We've already started a [tidy up of our two-part tariff review code](#1443). Moving both the fetch _and_ the presentation logic to somewhere reusable will help with that and put us in a better position for future changes. Previously, when we have needed to fetch various pieces of data in order to make a determination about something on a model we've done it on the model directly using modifiers and instance methods. This change refactors our existing billing account detail logic to follow this pattern.
Cruikshanks
added
the
housekeeping
Refactoring, tidying up or other work which supports the project
label
Oct 24, 2024
This is a pattern we've been updating our model tests to as we have been dropping in and making changes to them. It helps reduce the possibility of unnecessary data breaking other tests as well as speeding things up.
We no longer need to call the FetchBillingAccountService. However, it seems unnecessary at this time to tag it onto the Bill in `FetchBillService`. So, we replace it with a simple private function instead.
It was doing everything `FetchBillingAccountService` was doing. So, we can use the `contactDetails` modifier we've added instead.
I used my executive powers 💪 to merge even though CI was failing! We have a known issue with 4 of the return cycle tests that is being resolved. |
Merged
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-4057
We currently display a billing account's contact details when viewing a bill in a bill run. This is achieved by the
FetchBillingAccountService
and theViewBillPresenter
.We have to show the exact same details in the exact same format when reviewing the return match and allocation results in a two-part tariff bill run.
We strongly suspect that more pages will need to display this in the coming months.
We've already started a tidy up of our two-part tariff review code. Moving the fetch and the presentation logic to somewhere reusable will help and put us in a better position for future changes.
Previously, when we needed to fetch various pieces of data to make a determination about something on a model, we've done it on the model directly using modifiers and instance methods.
This change refactors our existing billing account detail logic to follow this pattern.