User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:due_date_requirements

This is an old revision of the document!


Due Date Requirements

Author: Victor Boctor

Introduction

Mantis currently tracks very well the project versions and issues status, however, it currently (up to 1.0.x) doesn't track progress relative to time. This is not a big issue for a bugtracker, but it may be a useful tool that helps with project management and also is very useful for scenarios where Mantis is used to manage things like tickets, to do lists, fullfilment of customer orders, etc. Hence, this feature is about assigning a due date for an issue. This due date doesn't have to be in line with any planner release or milestone.

Database Changes

  • Add an optional due_date field to the issue table.

Configuration Changes

  • Add a configuration option for the threshold required to be able to set the due date.
  • Add a configuration option for the threshold required to view the due date.

Currently threshold can take either a threshold (e.g. DEVELOPER) or an array of allowed access levels (e.g. array(DEVELOPER, SENIOR_DEVELOPER) - in this case developer and senior developer but not manager, viewer, reporter, or updater).

General Changes

  • Support “due_date” as a column that can be viewed in all outputs.
    • View Issues page
    • Print Issues page
    • Issue View Advanced page (eventually will be customizable through templates).
    • Issue Update Advanced page (eventually will be customizable through templates).
    • CSV export
    • Excel export
    • Word export
  • Support an “overdue” column which is typically an icon that is shown for issues that have due date, due date already passed, and the issue status is less than the configured resolved status. In the case of csv export, use a 1/0 flag to indicate if an issue is overdue or not. We may also want to consider having this as a field with a value equal to number of days to due date, which turns negative after the due date.
  • Support for filtering by due date, this is by specifying a date range to match against.
  • Support a new block in My View page which shows overdue issues (Overdue Issues). This should not be shown by default.
  • Support a new block in My View page which shows overdue issues assign to the current logged in user (My Overdue Issues). This should not be shown by default.

Reminders

  • Provide a script that can be called from a cronjob to send reminders for due / overdue issues. I'm think this can be done from the same script that sends queued emails, in such case we make want to save the “last executed” timestamp as a token.
  • Each user that is a handler in one or more projects and has one or more issues that are due or overdue should receive only one email whenever this script is called.
  • The recommendation will be to execute this script once every morning.
  • The formatting of each issue should be done through a custom function that takes the issue number and the user preferred format as an input.
  • The reminder layout will look as follows:
  * Issues Due Today
    * Project 1
      * 20345: summary (status)
  * Issues Overdue 
    * Project 1
      * 12345: summary (status, due date).
    * Project 2
      * 11111: summary (status, due date).
      * 22222: summary (status, due date).

Integration Features

These are nice to have features:

  • It would be nice to allow users to click on an icon to download a calendar (e.g. iCal) or todo entry that automatically gets added to user's todo list or calendar (e.g. Outlook). The entry should include the due date, issue summary, and issue description.
  • It would also be nice to have some sort of integration with online calendars (e.g. Google, Live, Yahoo, etc).

Feedback

Please add your comments and feedback in this section.

* The due date of tasks should also be integrated with the Roadmap/Version Deadline, see Roadmap Requirements. Probably there should be some consistency checks when the target version, issue deadline, or version deadline is changed.

* My suggestion is to be able to assign two time limits for each priority (by project). The inactivity timeout is the time an issue can stay without updates. The “SLA” timeout is the time an issue is expected to be resolved. Whenever one of this timers expires an email is sent to (configurable): the reporter, the assigned developer (if any) and the project manager.

* Would suggest that the Due date could be calculated by Mantis based upon a set number of days in config_inc.php or even better based upon a number of days set by project/category. Obviously when calculating the new date, we should only allow for working days, function can be found below:


#
# This function calculates the next date only using business days
# @param startdate The start date
# @param duedays   Number of days to add
#
function calcduedate( $p_startdate, $p_duedays ) {
    $t_datecalc = $p_startdate;
 
    $i = 1;
    while ( $i <= $p_duedays ) {
        $t_datecalc  += 86400; // Add a day.
        $t_date_info  = getdate( $t_datecalc );
 
        if ( ( $t_date_info["wday"] == 0 ) or ( $t_date_info["wday"] == 6 ) )  {
                $t_datecalc += 86400; // Add a day.
                continue;
        }
 
        $i++;
    }
 
    return $t_datecalc;
}
mantisbt/due_date_requirements.1204015564.txt.gz · Last modified: 2008/10/29 04:31 (external edit)