Roadmap Customization

Post about your customizations to share with others.

Moderators: Developer, Contributor

Post Reply
Pawlo84pl
Posts: 3
Joined: 14 Apr 2017, 17:53

Roadmap Customization

Post by Pawlo84pl »

Hi,
We use close status as task complete and verified. So that’s why I don’t want to see it in roadmap. Resolved status is for us as tasks to be verified. I read documentation that what is shown in roadmap can be customized ( by code but I can’t figure it out how to change it to get effect we would want.)
MantisBT provides the ability to customize the criteria for issues to show up on the roadmap. The default criteria is that the issue has to belong to a version that is not yet released and that the issues is not a duplicate. However, such criteria can be customized by using custom functions as below.
# --------------------
# Checks the provided bug and determines whether it should be included in the roadmap or not.
# returns true: to include, false: to exclude.
function custom_function_override_roadmap_include_issue( $p_issue_id ) {
return ( true );
}
It is also possible to customize the details included about an issues and the presentation of such details. This can be done through the following custom function:
# --------------------
# Prints one entry in the roadmap.
function custom_function_override_roadmap_print_issue( $p_issue_id, $p_issue_level = 0 ) {
$t_bug = bug_get( $p_issue_id );

if ( bug_is_resolved( $p_issue_id ) ) {
$t_strike_start = '<strike>';
$t_strike_end = '</strike>';
} else {
$t_strike_start = $t_strike_end = '';
}

if ( $t_bug->category_id ) {
$t_category_name = category_get_name( $t_bug->category_id );
} else {
$t_category_name = '';
}

$t_category = is_blank( $t_category_name ) ? '' : '<b>[' . $t_category_name . ']</b> ';

echo str_pad( '', $p_issue_level * 6, ' ' ), '- ', $t_strike_start, string_get_bug_view_link( $p_issue_id ), ': ', $t_category, string_display_line_links( $t_bug->summary );

if ( $t_bug->handler_id != 0 ) {
echo ' (', prepare_user_name( $t_bug->handler_id ), ')';
}

echo ' - ', get_enum_element( 'status', $t_bug->status ), $t_strike_end, '.<br />';
}
Some teams manage different branches for each of their projects (e.g. development and maintenance branches). As part of triaging the issue, they may decide that an issue should be targeted to multiple branches. Hence, frequently the request comes up to be able to target a single issue to multiple releases. The current MantisBT approach is that an issues represents an implementation or a fix for an issue on a specific branch. Since sometimes applying and verifying a fix to the two branches does not happen at the same time and in some cases the approach for fixing an issue is different based on the branch. Hence, the way to manage such scenario is to have the main issue for the initial fix and have related issues which capture the work relating to applying the fix to other branches. The issues for porting the fix can contain any discussions relating to progress, reflect the appropriate status and can go through the standard workflow process independent of the original issues.

Best,
Pawlo84pl

Posts: 2
Joined: Apr 14, 2017 12:53 pm
Post Reply