To support the summary report, the system needs to know the category of a given treatment (preservation, rehabilitation, reconstruction, etc.). While this might be obvious from the current treatment names, nothing prevents a user from entering an ambiguous name such as "Jake Treatment #1". This task would establish a checklist with valid categories where a user could indicate what type of treatment they are entering for categorization in the reporting engine without having to depend on naming conventions or report-based lookup tables.
[ ] Formally define requirements
[ ] Mockup UI
[ ] Determine method for defining category selections
[ ] Determine category logic (at least 1 selected, exactly 1 selected, 1 or none selected, etc.)
[ ] Implement database storage and/or configuration files for categories (i.e., a CATEGORIES table)
[ ] Implement UI
[ ] Implement CRUD APIs for data (or modify existing APIs)
[ ] Implement validation based on logic
[ ] Use data in PennDOT reporting
[ ] Add culvert/non-culvert flag to the database so that the use can select the culvert type from the drop down list.
To support the summary report, the system needs to know the category of a given treatment (preservation, rehabilitation, reconstruction, etc.). While this might be obvious from the current treatment names, nothing prevents a user from entering an ambiguous name such as "Jake Treatment #1". This task would establish a checklist with valid categories where a user could indicate what type of treatment they are entering for categorization in the reporting engine without having to depend on naming conventions or report-based lookup tables.