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.
  • Add a configuration option for preferred email format (email_format), the default value should be HTML. The possible values should be EMAIL_FORMAT_TEXT and EMAIL_FORMAT_HTML constants that map to values 0 and 1.

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.
  • 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.
  • 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.
  • Support for both html/text emails. In the case of html, issue ids must be hyperlinked to the issue view page.
  • 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.

* 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;
}

* It would be helpful to have a “Next action expected on” date field. It is somewhat similar to “due date” in that it is a time-related field. It is, however, not aimed at registering the date by which the issue is about to be resolved but the date before which progress is unlikely to happen. It is most useful when changes are pending due to something external (eg. scheduled decision, server to ship-in, etc). If filtering would be possible using this field (and/or display it in View Issues, My View, etc), one could avoid having to scan through issues which are pending anyways. Currently there are possible work-arounds to this (hierarchy and a new meta-issue, custom field, continuously updating due date), none of which is quite nice.

mantisbt/due_date_requirements.1171288914.txt.gz · Last modified: 2008/10/29 04:31 (external edit)