Add new Billing Account change address service #400
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
add-change-address-service
branch
from
1b48d9b to
55c81f8
Compare
Cruikshanks
added a commit
that referenced
this pull request
Sep 4, 2023
https://eaflood.atlassian.net/browse/WATER-4092 We are working on migrating the change billing account address functionality from the legacy code to this project. We previously added migrations to recreate the CRM_V2 tables `addresses`, `companies` and `invoice_account_addresses` in our test DB. But to keep things simple we normally don't bother with constraints as unless we really need them, we prefer to avoid using them. Well, in the [new Billing Account change address service](#400) we're adding we do! 🤦 We depend on the constraints to raise [ON CONFLICT errors](https://www.postgresql.org/docs/current/sql-insert.html#SQL-ON-CONFLICT) for our logic to work. So, in order to test our new service we need to add the missing constraints to our migrations. We're doing that change separately because [Add new Billing Account change address service](#400) is already pretty big 😬.
|
Just need PR #404 to be merged then the tests should pass and this will be ready to go. |
https://eaflood.atlassian.net/browse/WATER-4092 We are working on migrating the change billing account address functionality from the legacy code to this project. This change is the final part of the backend logic! In this change we add the `ChangeAddressService`. It will be responsible for orchestrating the change address process; letting the [Charging Module API](https://github.com/DEFRA/sroc-charging-module-api) know about the change and updating our own DB. It then needs to generate a response the [water-abstraction-ui](https://github.com/DEFRA/water-abstraction-ui) will understand so it can complete the journey for the user. We're making those changes in [Send change address requests to system in future](DEFRA/water-abstraction-ui#2423).
This works and has been tested locally. But we're still sorting out the documentation and need to add tests for it.
This hooks up the service to the controller. The only bit remaining is to update its tests.
Hopefully this all makes sense and is of value to others.
The tests highlighted some mistakes we had made in the implementation.
Cruikshanks
force-pushed
the
add-change-address-service
branch
from
cf14f99 to
cff2bd0
Compare
Cruikshanks
added a commit
that referenced
this pull request
Sep 5, 2023
https://eaflood.atlassian.net/browse/WATER-4092 We are migrating the change billing account address functionality from the legacy code to this project. In our test DB, we previously added migrations to recreate the CRM_V2 tables `addresses`, `companies` and `invoice_account_addresses`. But to keep things simple we usually don't bother with constraints as unless we really need them, we prefer to avoid using them. Well, in the [new Billing Account change address service](#400) we're adding we do! 🤦 We depend on the constraints to raise [ON CONFLICT errors](https://www.postgresql.org/docs/current/sql-insert.html#SQL-ON-CONFLICT) for our logic to work. So, in order to test our new service we need to add the missing constraints to our migrations. We're doing that change separately because [Add new Billing Account change address service](#400) is already pretty big 😬. --- When we did apply the constraints it highlighted we had a flaw in our model tests. The top-level `beforeEach()` should only have been cleaning the DB. The model tests also had to be updated to deal with creating 2 invoice address records using the same default data; we can't have multiple records with the same start date and invoice account ID.
Now changeaddressservice is used in the controller the test can be expanded.
|
@Jozzey @Beckyrose200 @StuAA78 This is a big one and I've broken out as much as I could into other PR's. So, if you need me to walk through it before you review do let me know. |
StuAA78
requested changes
Sep 6, 2023
Comment on lines
+110
to
+112
| * @param {module:AddressModel} address the new address to be persisted (expected to be populated) | ||
| * @param {module:CompanyModel} company the new agent company to be persisted (not expected to be populated) | ||
| * @param {module:ContactModel} contact the new contact to be persisted (not expected to be populated) |
There was a problem hiding this comment.
It took me a little figuring out to realise that when we say "expected to be populated" and "not expected to be populated", it's because agentCompany and contact are optional when calling the service but we always transform the day we receive (empty or not) into companyInstance and contactInstance. A little note in the comments to note why those two may not be populated might be useful.
There was a problem hiding this comment.
Added extra comments. Hopefully that helps.
| @@ -0,0 +1,424 @@ | |||
| 'use strict' | |||
There was a problem hiding this comment.
Just as a general point, all of our tests call ChangeAddressService.go() with agentCompany and contact. Presumably some of these tests are passing in empty values but is it worth having at least one test that doesn't pass these in, just to confirm/document the defaulting of these to empty objects?
There was a problem hiding this comment.
Added a test and it made me think about what the service returns. So, also helped me clean things up a bit. Thank you!
Co-authored-by: Stuart Adair <43574728+StuAA78@users.noreply.github.com>
Based on feedback these extra comments try to explain why we talk about address, company and contact being 'populated' or not.
Feedback in the PR suggested we have an explicit test that covers the service handling a null agent company and contact. After implementing the test we realised the response from the service was 'dirty' and confusing. If you passed in a null `agentCompany` you would expect to get a null `agentCompany` out. So, we also took this opportunity to clean up the response from the service.
Beckyrose200
reviewed
Sep 7, 2023
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-4092
We are migrating the change billing account address functionality from the legacy code to this project. This change is the final part of the backend logic!
In this change, we add the
ChangeAddressService. It will be responsible for orchestrating the change address process; letting the Charging Module API know about the change and updating our own DB.It then needs to generate a response that the water-abstraction-ui will understand so it can complete the journey for the user. We're making those changes in Send change address requests to system in future.