Implement mock return review #447
Closed
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
added a commit
that referenced
this pull request
Oct 5, 2023
https://eaflood.atlassian.net/browse/WATER-4152 We are currently working on the SROC two-part tariff bill. The first step of the process in the UI is to review how the returns have been matched. Our superstar design team are working on an improved design for the returns review screen but to do that they need data. This led us to start [Implement mock return review](#447). A requirement that came out of that was the ability to capitalize certain values, for example, loss is recorded in the DB as `high` but when presenting it we want to see `High`. As we start to build views and 'present' the data for them we're going to need this in more and more cases. So, this change adds a`capitalize()` method to our base presenter.
Cruikshanks
added a commit
that referenced
this pull request
Oct 6, 2023
https://eaflood.atlassian.net/browse/WATER-4152 We are currently working on the SROC two-part tariff bill. The first step of the process in the UI is to review how the returns have been matched. Our superstar design team are working on an improved design for the returns review screen but to do that they need data. This led us to start [Implement mock return review](#447). A requirement that came out of that was the ability to capitalize certain values, for example, loss is recorded in the DB as `high` but when presenting it we want to see `High`. As we start to build views and 'present' the data for them we're going to need this in more and more cases. So, this change adds a `capitalize()` method to our base presenter.
Cruikshanks
force-pushed
the
implement-mock-return-review
branch
from
b1a428f to
b5869e9
Compare
|
This was really useful to understand what the existing service is doing with the returns review screens. But with the new design almost complete and the fact it'll need the data in a different way, I'm no longer sure there is any value investing in tidying up and writing unit tests for this. Just going to leave it here for a little while and 'wait-and-see'. Will then make a decision. |
Cruikshanks
added a commit
that referenced
this pull request
Dec 8, 2023
https://eaflood.atlassian.net/browse/WATER-4057 To make the work on two-part tariff and other areas of the service easier in the future we have been undergoing a large scale refactor of our models. We have realised we can make it seem to the project that we have just one schema, and that everything sits in `public` by using [updatable views](https://www.postgresql.org/docs/current/sql-createview.html) for any legacy table we have to deal with. This has led to a whole refactor of the models so they are based on these new views rather than the legacy tables. During [Refactor to use new view based WATER models](#569), the last stage in refactoring, we hit the point we'd have to make a whole series of changes to the services that support generating mock data. For context, we created this to help support the [re-design of the view bill pages](https://eaflood.atlassian.net/browse/WATER-4131). Our design team needed to prototype and test a page that replicated the scenario we were trying to fix; a bill with more than 150 licences linked to it. We created the mock endpoint to generate data that could be copied & pasted by the design team into the prototype. The thought was this would be 'a thing' we'd be asked again and again for in the future. In reality, we've only had 1 additional request, and that was to [generate returns review data based on how the old engine does it](#447). But this was needed to have something to design the new pages around. We've never got round to merging it because it will require a lot of unit testing, for something that will never be used again. We've come to the conclusion generating mock data at best is only ever going to be a one-off exercise. There will be times we need code to generate complex 'data' (bill runs, charge versions, returns etc) in enough quantity to make tests in the prototype realistic. But once we've generated the data there will never be any additional requests. There is no point maintaining these endpoints and increasing our workload. So, this change removes the existing mock endpoint and functionality.
|
Closing this based on the decision I've made to remove the mock data generation feature. See #575 |
Cruikshanks
added a commit
that referenced
this pull request
Dec 8, 2023
https://eaflood.atlassian.net/browse/WATER-4057 To make the work on two-part tariff and other areas of the service easier in the future we have been undergoing a large-scale refactor of our models. We have realised we can make it seem to the project that we have just one schema, and that everything sits in `public` by using [updatable views](https://www.postgresql.org/docs/current/sql-createview.html) for any legacy table we have to deal with. This has led to a whole refactor of the models based on these new views rather than the legacy tables. During [Refactor to use new view-based WATER models](#569), the last stage in refactoring, we hit the point where we'd have to make a whole series of changes to the services that support generating mock data. For context, we created this to help support the [re-design of the view bill pages](https://eaflood.atlassian.net/browse/WATER-4131). Our design team needed to prototype and test a page that replicated the scenario we were trying to fix; a bill with more than 150 licences linked to it. We created the mock endpoint to generate data that could be copied & pasted by the design team into the prototype. The thought was this would be 'a thing' we'd be repeatedly asked for in the future. In reality, we've only had 1 additional request, and that was to [generate returns review data based on how the old engine does it](#447). But this was needed to have something to design the new pages around. We've never got around to merging it because it will require a lot of unit testing, for something that will never be used again. We've come to the conclusion generating mock data at best is only ever going to be a one-off exercise. There will be times we need code to generate complex 'data' (bill runs, charge versions, returns etc) in enough quantity to make tests in the prototype realistic. However once we've generated the data, there will be no additional requests. There is no point in maintaining these endpoints and increasing our workload. So, this change removes the existing mock endpoint and functionality.
Beckyrose200
pushed a commit
that referenced
this pull request
Dec 14, 2023
https://eaflood.atlassian.net/browse/WATER-4057 To make the work on two-part tariff and other areas of the service easier in the future we have been undergoing a large-scale refactor of our models. We have realised we can make it seem to the project that we have just one schema, and that everything sits in `public` by using [updatable views](https://www.postgresql.org/docs/current/sql-createview.html) for any legacy table we have to deal with. This has led to a whole refactor of the models based on these new views rather than the legacy tables. During [Refactor to use new view-based WATER models](#569), the last stage in refactoring, we hit the point where we'd have to make a whole series of changes to the services that support generating mock data. For context, we created this to help support the [re-design of the view bill pages](https://eaflood.atlassian.net/browse/WATER-4131). Our design team needed to prototype and test a page that replicated the scenario we were trying to fix; a bill with more than 150 licences linked to it. We created the mock endpoint to generate data that could be copied & pasted by the design team into the prototype. The thought was this would be 'a thing' we'd be repeatedly asked for in the future. In reality, we've only had 1 additional request, and that was to [generate returns review data based on how the old engine does it](#447). But this was needed to have something to design the new pages around. We've never got around to merging it because it will require a lot of unit testing, for something that will never be used again. We've come to the conclusion generating mock data at best is only ever going to be a one-off exercise. There will be times we need code to generate complex 'data' (bill runs, charge versions, returns etc) in enough quantity to make tests in the prototype realistic. However once we've generated the data, there will be no additional requests. There is no point in maintaining these endpoints and increasing our workload. So, this change removes the existing mock endpoint and functionality.
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-4152
We are currently working on the SROC two-part tariff bill. The first step of the process in the UI is to review how the returns have been matched. Our superstar design team are working on an improved design for the returns review screen but to do that they need data.
Enter our mock data service!
We previously Create endpoint to generate fake data which was focused on a bill run. The design team would love it if we could do the same for the data the current returns review page uses.
This change completes the work started in Add new bill run volume model to take an existing 2PT bill run and generate mock returns review data from it.