Stage

Currently state is just another task attribute without any special meaning. We propose to promote that attribute to its own db schema and rename it from 'state' to 'stage'.

Schema

A stage model can be used across multiple projects. Each project must have exactly one model. Although a model right now is just a set of stages, we expect later for it to also have a set of stage transitions (ie. instructions for what happens when you move from one stage to another).

[ stage_model ]
company_id
name
id
-> projects (one to many join)

The model is made up of multiple stages. We map this as a many-many join between the model and the stage because it makes sense to reuse common stages. This also makes it easier to change the model for a project or change the project for a task without losing the data if they share the same stages.

[ stage ]
company_id
id
name
sort
-> stage_model (many to many join so they can be reused for several workflows) 
defaultDays (int)

Each task can now have an estimate per stage.

[ task_stage_estimate ]
-> task
-> stage
-> work_estimate (minutes?)

And of course the project default needs to be per status.

[ project_stage ]
-> project
-> stage
-> work_estimate (minutes?)

We need to know which stage the task is currently at.

[ task ]
-> current_stage

And let's record the stage which the task was pointing to when the worklog was created. If you change the stage and save worklog at the same time, then this should point to the old stage.

[ work_log ]
-> stage

Milestone start and end is now broken down per status.

[ milestone_stage ]
company_id
-> milestone
-> stage
start_at
due_at

Migration

Any existing 'properties' named "state" should be migrated to the new schema. One Workflow model should be created called "default" which contains all the stage attributes. Any existing task_estimate should be attached to the stage called "development" if there is one, or just the first stage if there isn't. We'll also attach all work_log to that same status.

If there is not properties named 'state' (for example when creating a new tenant or new db), just create a default workflow with stages:

• Review
• In progress
• Testing
• Documentation

Stages

A simple UI in the left menu of the company edit page called "Task stages". This lets you add/edit/delete stages in a list. Deleting a stage should be prohibited if that stage is used in any workflow model.

Stage model

Another UI page under 'task stages' with the menu title 'Task stage workflow'. This let's you create/edit/delete stage models and for each you can attach stages. Editing or deleting a model should not be allowed if it is attached to any project.

Project edit UI

• A dropdown for "Stage workflow"
• The default estimate will now need to be per stage. The default value for this when creating a new project should be 1 hour.

Switching workflow models

If you change the workflow model for a project, we might not have the same stages. We need to have a UI to handle how to migrate existing worklogs, estimates and tasks to the new model. For this early implementation, we can skip creating that UI and come back to it.

Task edit UI

Currently we have one estimate field per task. Now we'll be needing one per !stage.defaultDays.nil.

Task list UI

When displaying the estimate in any other part of the UI (such as the task list) we should display the estimate as 4/12 (where 4 is the estimate for the current stage and 12 is the sum of the estimate for all stages including the current state).

Work log

When logging work time, we need to track which stage that time was logged against. This will then be displayed grouped in the UI to the left of the task edit view. Rather than grouping by user (as currently) we group and display only by stage.

Milestone dates

Currently milestones have a start and end date. We'll move those attributes from the milestone to the milestone_stage join table so that each stage can have its own start and end dates. There is no need to perform validation to ensure they don't overlap and some stages can have no dates at all, or just one date.

When creating a new milestone we allow the user to enter the first starting date and then calculate the rest based on stage.defaultDays.