Content
View differences
Updated by Aaron Contreras about 3 years ago
TODO:
* API
* [x] project\_statuses endpoint
* GET /api/v3/project\_statuses/:id
* [x] Ensure spec coverage for ^
* [x] project/status\_representer.rb
* Modify translation keys to match table structure.
* [x] Ensure spec coverage for ^
* [x] [ ] projects endpoints
* POST /api/v3/projects
* PATCH /api/v3/projects/:id
* GET /api/v3/projects/:id
* [x] [ ] Ensure spec coverage for ^
* [x] projects\_representer.rb
* resource :status
* reference represented directly instead of represented.status\_attributes
* property :status\_explanation
* switch to formattable\_property like done for `description`
* `from_hash` hack - remove
* [x] Ensure spec coverage for ^
* [x] projects services:
* SetAttributesService:
* `with_hack_around_faulty_enum` and `update_status` adapt to no longer nest status
* UpdateService:
* `persist_status` remove
* [x] [ ] Ensure spec coverage for ^
* [x] [ ] projects contracts:
* BaseContract
* `validate_status_code_included` adapt to no longer nest status
* [x] [ ] Ensure spec coverage for ^
* [x] projects/schemas/project\_schema\_representer.rb needs updateing the `writable?` property on both `status` and `status_explanation` to match the attributes defined on base\_contract.
* [x] Ensure spec coverage for ^
* app/models/queries/projects/filters/project\_status\_filter.rb
* Will most likely need to re-purpose this filter to no longer work on a joined table and instead become a more "standardized" filter as others are with just same-table column filters. Would like a little intro into the "Query" concept and "Filters".
* app/cells/projects/table\_cell.rb
* Simple replacement of the caption for `status_explanation`
* app/helpers/projects\_helper.rb references former yml translation.
* Extend database tables (code and explanation columns)
* projects
* project\_journals
* [ ] Migrate the existing data
* projects: Write values from project\_statues into table
* project\_journals: Write current values into existing journal files
* API
* [x] project\_statuses endpoint
* GET /api/v3/project\_statuses/:id
* [x] Ensure spec coverage for ^
* [x] project/status\_representer.rb
* Modify translation keys to match table structure.
* [x] Ensure spec coverage for ^
* [x]
* POST /api/v3/projects
* PATCH /api/v3/projects/:id
* GET /api/v3/projects/:id
* [x]
* [x] projects\_representer.rb
* resource :status
* reference represented directly instead of represented.status\_attributes
* property :status\_explanation
* switch to formattable\_property like done for `description`
* `from_hash` hack - remove
* [x] Ensure spec coverage for ^
* [x] projects services:
* SetAttributesService:
* `with_hack_around_faulty_enum` and `update_status` adapt to no longer nest status
* UpdateService:
* `persist_status` remove
* [x]
* [x]
* BaseContract
* `validate_status_code_included` adapt to no longer nest status
* [x]
* [x] Ensure spec coverage for ^
* app/models/queries/projects/filters/project\_status\_filter.rb
* Will most likely need to re-purpose this filter to no longer work on a joined table and instead become a more "standardized" filter as others are with just same-table column filters. Would like a little intro into the "Query" concept and "Filters".
* app/cells/projects/table\_cell.rb
* Simple replacement of the caption for `status_explanation`
* app/helpers/projects\_helper.rb references former yml translation.
* Extend database tables (code and explanation columns)
* projects
* project\_journals
*
* projects: Write values from project\_statues into table
* project\_journals: Write current values into existing journal files