Change Details

Currently, a project's workboard shows: - columns for the project itself, containing tasks in the project; and - columns for the project's milestones, containing tasks in the milestones. Subproject columns are not currently shown. The major reason for this is that a task may be in multiple subprojects simultaneously (for example, a task describing a conflict between routing power to the warp drive and the shields may be in both {nav Engineering > Shields} and {nav Engineering > Warp Drive}). If it is, the card will appear //twice// on the board, once in each column, and dragging it will mean different things depending on //which copy// you drag. Because this added a significant amount of complexity to the display and transaction code, we opted to hold this back from the initial projects iteration, both to make sure this was a reasonable way to move forward and to make sure our other decisions about subprojects and workboard behavior were generally reasonable. I think we're generally pretty happy with where things are in terms of other product decisions, and work connected to T6027 has also cleaned up some of the underlying transaction code. However, there is still a nontrivial amount of work here to make the display code work correctly and resolve weird cases like: - dragging a copy of a task into another column which already has a copy of the task; - highlighting (and animating?) other copies of tasks to make relationships more clear; - updating all copies of a task when one copy is edited; - warning about the consequences of dragging a subproject task currently in multiple subprojects to a superproject column or a milestone column? Some of the adjacent work mentioned on T10349 under **Workboard Updates after Edits** and in preparation for T4900 may also need to happen here. This would expose us to more types of potential edits that could leave a workboard in a confusing state, and greater potential confusion from those edits. I generally wrote the code with this change in mind, so the pathway should not be a particularly long one, but it's not just flipping a switch either.

Currently, a project's workboard shows: - columns for the project itself, containing tasks in the project; and - columns for the project's milestones, containing tasks in the milestones. Subproject columns are not currently shown. The major reason for this is that a task may be in multiple subprojects simultaneously (for example, a task describing a conflict between routing power to the warp drive and the shields may be in both {nav Engineering > Shields} and {nav Engineering > Warp Drive}). If it is, the card will appear //twice// on the board, once in each column, and dragging it will mean different things depending on //which copy// you drag. Because this added a significant amount of complexity to the display and transaction code, we opted to hold this back from the initial projects iteration, both to make sure this was a reasonable way to move forward and to make sure our other decisions about subprojects and workboard behavior were generally reasonable. I think we're generally pretty happy with where things are in terms of other product decisions, and work connected to T6027 has also cleaned up some of the underlying transaction code. However, there is still a nontrivial amount of work here to make the display code work correctly and resolve weird cases like: - dragging a copy of a task into another column which already has a copy of the task; - highlighting (and animating?) other copies of tasks to make relationships more clear; - updating all copies of a task when one copy is edited; - warning about the consequences of dragging a subproject task currently in multiple subprojects to a superproject column or a milestone column? Some of the adjacent work mentioned on T10349 under **Workboard Updates after Edits** and in preparation for T4900 may also need to happen here. This would expose us to more types of potential edits that could leave a workboard in a confusing state, and greater potential confusion from those edits. I generally wrote the code with this change in mind, so the pathway should not be a particularly long one, but it's not just flipping a switch either. --- See also PHI1335.

Currently, a project's workboard shows: - columns for the project itself, containing tasks in the project; and - columns for the project's milestones, containing tasks in the milestones. Subproject columns are not currently shown. The major reason for this is that a task may be in multiple subprojects simultaneously (for example, a task describing a conflict between routing power to the warp drive and the shields may be in both {nav Engineering > Shields} and {nav Engineering > Warp Drive}). If it is, the card will appear //twice// on the board, once in each column, and dragging it will mean different things depending on //which copy// you drag. Because this added a significant amount of complexity to the display and transaction code, we opted to hold this back from the initial projects iteration, both to make sure this was a reasonable way to move forward and to make sure our other decisions about subprojects and workboard behavior were generally reasonable. I think we're generally pretty happy with where things are in terms of other product decisions, and work connected to T6027 has also cleaned up some of the underlying transaction code. However, there is still a nontrivial amount of work here to make the display code work correctly and resolve weird cases like: - dragging a copy of a task into another column which already has a copy of the task; - highlighting (and animating?) other copies of tasks to make relationships more clear; - updating all copies of a task when one copy is edited; - warning about the consequences of dragging a subproject task currently in multiple subprojects to a superproject column or a milestone column? Some of the adjacent work mentioned on T10349 under **Workboard Updates after Edits** and in preparation for T4900 may also need to happen here. This would expose us to more types of potential edits that could leave a workboard in a confusing state, and greater potential confusion from those edits. I generally wrote the code with this change in mind, so the pathway should not be a particularly long one, but it's not just flipping a switch either. --- See also PHI1335.