Move return-logs-edit into return-logs folder #1592
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-4805 In preparation for quarterly returns and as part of our continued efforts to migrate all existing features from the legacy code base, we are rebuilding the internal return log 'edit' journey. The first change that has gone in added support for the [Editing a return log session data](#1590). Quite rightly, we are keeping it and the subsequent edit pages separate from the general return logs pages for viewing return logs. However, the initial services should have gone into an `/edit` folder inside `/return-logs`, not in a standalone folder. This change resolves the issue.
In the main, when we are interacting with a 'thing' we do it on a route that matches. Viewing a bill run or return version? Then its `/bill-runs` and `/return-versions`. In the case of when we come to view a return log, it will be `/return-logs`. When we come to setup a 'thing', we put it on a `/setup` path _under_ the main path, for example, `/bill-runs/setup`. So, we rename the route that was setup for return logs and the routing to match. BTW we rename to setup because this feature, though called `edit a return log` isn't actually doing that. The first time we complete this journey, we will actually be setting up the first return submission for the return log. Any subsequent edits are just 'setting up' new versions of the return submission. So, we change to `/setup`, not only to match existing conventions but also to give us some linguistic flexibility as we build out this feature.
Cruikshanks
added
the
housekeeping
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-4805
In preparation for quarterly returns and as part of our continued efforts to migrate all existing features from the legacy code base, we are rebuilding the internal return log 'edit' journey.
The first change that has gone in added support for the Editing a return log session data. Quite rightly, we are keeping it and the subsequent pages separate from the general return logs pages for viewing return logs.
However, the initial services should have gone into a subfolder inside
/return-logs, not a standalone folder.Also, the routing should have followed our existing conventions.
In the main, when interacting with a 'thing', we do it on a matching route. Viewing a bill run or return version? Then it's
/bill-runsand/return-versions.When we have finished building view a return log, it will be
/return-logs.When we set up a 'thing', we put it on a
/setuppath under the main path, for example,/bill-runs/setup. To keep things consistent we update the routing to match this.This may be at odds with a feature called 'edit a return log'. But it is worth bearing in mind we never actually edit the return log. The first time we complete this journey, we will set up the first return submission for the return log. Any subsequent edits are just 'setting up' new versions of the return submission.
So, a change to
/setupwill match existing conventions and give us some linguistic flexibility as we build out this feature.