As with all things, when facing a deadline we've parked some items that need doing in order to meet it. But we'd still like to tackle them before go live so the service is 'ship shape and Bristol fashion' before starting the next phase of its journey.
For reference, these aren't just 'niggles' that resolving would make us happy. A clean and consistent codebase is the foundation for delivering new features and functions quickly whilst maintaining quality. As more 'cruft' accrues and is not deal with, the slower our rate of delivery as a team will be.
Test suite
[ ] Review test helpers (merge and/or refactor where necessary)
[ ] Determine data generator helpers required (pick tests that depend on populated bill runs for example and aim to refactor them to use the new helpers)
[ ] Fix test/support/helpers/transaction.helper.js method _newLicenceAndInvoice() not passing on overrides (might be superceded by the other test chores
[ ] Review controller tests to be consistent. Stub out underlying services from any that are still calling them
[ ] Add just one 'happy-path' bill run feature test
[ ] Update all tasks to use docker compose instead of docker-compose
Code
[x] Services folder tidy up (grouping; bill_runs, invoices, transactions etc)
[ ] Move to using subfolder index.js convention
[x] Squash down the DB migrations before Go live
[ ] Convert jwt_strategy (authOptions) into a proper class then review #66
[x] Update lib classes to include lib in name and file to match our convention
[x] Support seeding a test authorised system
[ ] Add Completed sending file log message to SendTransactionFileService, similar to howSendCustomerFileService has one.
[x] We call FetchAndValidateBillRunInvoiceService from within BillRunsInvoicesController.delete which fetches then validates the specified invoice; however RequestInvoicePlugin already does some of this so FetchAndValidateBillRunInvoiceService could in fact become ValidateBillRunInvoiceService which just checks that the invoice belongs to the bill run.
[ ] GET Invoice not linked to bill run is a conflict(). Should be a badData() to match regime not linked to bill run
[x] For get requests use view rather than show in controllers and for names of services for consistency
[x] Rename regimeId to regimeSlug throughout to better reflect what the parameter is.
[ ] Rename routes and controllers to reflect our revised naming approach of "use the 'deepest' entity" -- ie. instead of bill_run_invoice.routes.js we have invoice.routes.js. Note that routes are named in the singular (ie. bill_run_invoice.routes.js) and controllers in the plural (ie. bill_runs_invoices.controller.js) so we may want to standardise this.
Documentation
[ ] Add root README to app/ folder to explain what the purpose of each folder is, and any conventions/expectations for the files in those folders
[ ] Update root README in test/ with our testing conventions
[ ] Update this project to reflect change in status of projects: charging-module-api dead, sroc-charging-service redundant, sroc-tcm-admin maintenance-only.
[ ] Rattic is simply a mess but we don't have rights to edit most stuff. Sort permissions with web-ops and then clean it up
We've been hammering away getting the sroc-charging-module-api ready for go-live.
As with all things, when facing a deadline we've parked some items that need doing in order to meet it. But we'd still like to tackle them before go live so the service is 'ship shape and Bristol fashion' before starting the next phase of its journey.
For reference, these aren't just 'niggles' that resolving would make us happy. A clean and consistent codebase is the foundation for delivering new features and functions quickly whilst maintaining quality. As more 'cruft' accrues and is not deal with, the slower our rate of delivery as a team will be.
Test suite
test/support/helpers/transaction.helper.jsmethod_newLicenceAndInvoice()not passing on overrides (might be superceded by the other test choresLocal environment
Nuke DBtaskdocker composeinstead ofdocker-composeCode
index.jsconventionjwt_strategy(authOptions) into a proper class then review #66Completed sending filelog message toSendTransactionFileService, similar to howSendCustomerFileServicehas one.FetchAndValidateBillRunInvoiceServicefrom withinBillRunsInvoicesController.deletewhich fetches then validates the specified invoice; howeverRequestInvoicePluginalready does some of this soFetchAndValidateBillRunInvoiceServicecould in fact becomeValidateBillRunInvoiceServicewhich just checks that the invoice belongs to the bill run.GETInvoice not linked to bill run is aconflict(). Should be abadData()to match regime not linked to bill runviewrather thanshowin controllers and for names of services for consistencyregimeIdtoregimeSlugthroughout to better reflect what the parameter is.bill_run_invoice.routes.jswe haveinvoice.routes.js. Note that routes are named in the singular (ie.bill_run_invoice.routes.js) and controllers in the plural (ie.bill_runs_invoices.controller.js) so we may want to standardise this.Documentation
app/folder to explain what the purpose of each folder is, and any conventions/expectations for the files in those folderstest/with our testing conventionsdead, sroc-charging-serviceredundant, sroc-tcm-adminmaintenance-only.Other
productionbuild_number.plugin.js)