Due date

Phase one

“Due date” and “wait until” date are confusing and difficult to use properly.

Wait until

This will be moved into its own section called “snooze” and is documented with Dependencies.

Target date

Change the label in the UI from ‘due date’ to ‘target date’. The field is not a text entry box but rather a text string like this:

Target date: 12 January override

• The ‘override’ link is very small text and clicking it will cause the “12 January” date to be replaced with a text field for entering an alternative date. That date will be stored in the existing “due date” field.
• Target date will be calculated as follows

def targetDate
  return dueDate  if dueDate != nil
  return task.milestone.date if task.milestone.date != nil
  return nil
end

BTW, we already have method Task#due_date, database field, where due date is stored, is named tasks.due_at

def due_date
    due_at || milestone.try(:due_at)
end

If nil, then it displays “Not set”.

• A rollover on the target date field will show:
  • “From milestone ABC”, or
  • “Manually overridden”

Repetitions

The existing due date field supports repetitions (eg “every month”). This functionality would be completely removed since it as no place in a project management system. Outlook or other reminder systems are more suited to these sorts of tasks with no workflow (eg are never closed).

Phase two

The following features can come after the above is developed.

Estimates

Every task will need to be given an estimate if the user has no assigned one. To do so, add a new field project.default_estimate. Any task without an estimate will be given a default estimate. Note that it is important to see the difference between a real estimate assigned and an estimate given by default, so ideally the never store the default estimate in the task but just get it through the join to project.

User hours

Every user is given a grid of 7 boxes with days of the week. They can type a number (float) in that box to designate the number of hours in that day they expect to work. Holidays and other improvements can come in the future, so write code with that in mind. We need an accessor function like:

user.getWorkingHours(date)

For now, we just translate date to day-of-week but later we may deal with real dates and holidays.

Task estimated date

( A new database field in the task table called “estimatedDate”.

• when weight is recalculated each night, each task is put in order and the task time estimate used to calculate an expected estimate date for that task unless one is already assigned. That is, take the tasks assigned in order. Then the first task gets an estimatedDate of today. The next task also gets today, and the next until a day’s worth of tasks are allocated, then the next task gets tomorrow.

If a tasks’ weight is altered (say a user changes the priority), then we immediately recalculate the task estimate by looking at the task immediately higher than it in the weight queue and using the same date. It will probably be too intensive to shift every task in the system at this time, so that might need to wait until the nightly run. Or hourly run if it is fast enough.