Content
View differences
Updated by Alexander Coles 4 days ago
There have been many devs working on this epic and related Sprint topics. Because we have put new functionality behind a feature flag, this has introduced a lot of branch logic - and thus, extra complexity - in the various backlogs controllers that live under `modules/backlogs/app/controllers/`
It has also introduced some bugs - with drag and drop breaking due to incorrect or incomplete git merge conflict resolution.
These are the controllers to concentrate on:
* `rb_master_backlogs_controller.rb`
* `rb_sprints_controller.rb`
* `rb_stories_controller.rb`
* `rb_taskboards_controller.rb`
Ideally, we would:
1. Tidy up naming - `new_sprint_` vs `legacy_` for old stuff. We should optimise naming for the "new" (scrum projects active) paths, since the old code will be removed in a version or two.
2. Split the controllers, if it makes sense.
3. Guard features at a routing level (in the same vein as [https://github.com/opf/openproject/pull/22348)](https://github.com/opf/openproject/pull/22348\)) [https://github.com/opf/openproject/pull/22348)](https://github.com/opf/openproject/pull/22348\))
With regards to naming controllers, we should aim to move away from the `Rb` constant prefix and just stick to regular Rails conventions as as far as possible.
It has also introduced some bugs - with drag and drop breaking due to incorrect or incomplete git merge conflict resolution.
These are the controllers to concentrate on:
* `rb_master_backlogs_controller.rb`
* `rb_sprints_controller.rb`
* `rb_stories_controller.rb`
* `rb_taskboards_controller.rb`
Ideally, we would:
1. Tidy up naming - `new_sprint_` vs `legacy_` for old stuff. We should optimise naming for the "new" (scrum projects active) paths, since the old code will be removed in a version or two.
2. Split the controllers, if it makes sense.
3. Guard features at a routing level (in the same vein as [https://github.com/opf/openproject/pull/22348)](https://github.com/opf/openproject/pull/22348\))
With regards to naming controllers, we should aim to move away from the `Rb` constant prefix and just stick to regular Rails conventions as as far as possible.