I second this. Related to 0008268.

Is there a proposed solution to this problem rather than a request for a nebulous feature?

Anything to identify the state of "suspended" would be great. Gray background instead of line-through, for example.

Indeed having suspended out of the roadmap or some other option would benefit the clarity for people looking at the roadmap in real life situation.

The goal of the roadmap is after al to have a quick clear overview of status. Most of the time only look by people not heavily involved in the defec t tracking process. Clarity is there important.

The current implementation is theoretically correct I realize that. BTW IMHO not related to defect 0008268.

Agree with nurikabe's suggestion at 0009020:0017783.
To gray-out background instead of line-through.

Also, suggest to change the wording "resolved" to "suspended" on the roadmap page.

Two more points of interest:

• How could/should this handle custom sets of resolutions?

• If a feature/bug is suspended, shouldn't it's target version be updated to either [no version] or a later/different version? In other words, why are suspended issues still targetting a specific release?

I only ask because I'm interested in the use case and usability aspects; I'd like to find a better solution if possible than arbitrarily handling one resolution different from the rest. Is there a different solution that could better serve this situation?

For us, a suspended issue is a special case: Typically something targeted for a specific release but, for any of a variety of reasons, deemed lower priority and to be rescheduled to a release upcoming.

It is useful to see, at a glance, which features for a release were suspended.

Alternatively (or even in addition) it would be useful to have a section at the bottom of the roadmap showing only suspended issues and the release in which they were suspended.

@jreese: I see your point!

My suggestion would be to count only the combination of status>=resolved AND resolution=fixed as 'fixed' items in the roadmap and counted in percentage display. (Customization must keep in mind not to move the fixed=20 to another value. The same as with resolved >= 80)
All other combinations should yield in an open item. Some of them are good candidates to be removed from the target version's list.

In the roadmap display I would show both attributs: status + resolution.

Edit adds one '>' after the word status and copied the design given in vboctors blog from 2005:

• The issue must have a resolution = FIXED.
• The issue must have a status that is greater than $g_bug_resolved_status_threshold.

I implemented the following changes to get the resolution I suggested:

change in bug_api.php:

--------------------

Check if the bug is resolved

function bug_is_resolved( $p_bug_id ) {
$t_status = bug_get_field( $p_bug_id, 'status' );

ws, 14.08.08: start change

$t_resolution = bug_get_field( $p_bug_id, 'resolution' );

return ( $t_status >= config_get( 'bug_resolved_status_threshold' ) );

return ( $t_status >= config_get( 'bug_resolved_status_threshold' ) && $t_resolution == FIXED );

ws, 14.08.08: end change

}

change of roadmap_print_issue in custom_function_inc.php or custom_function_api.php:
echo ' - ', get_enum_element( 'status', $t_bug->status ), '/', get_enum_element( 'resolution', $t_bug->resolution ), $t_strike_end, '.
';

SORRY: I do not know, how to input the linefeed html-chars '.< br / >'; in this text field. Please don not forget to copy theese from the original source.

I have change in this way:

change of custom_function_default_roadmap_print_issue in custom_function_api.php:
if( !isset( $t_status[$t_bug->status] ) ) {
$t_status[$t_bug->status] = get_enum_element( 'status', $t_bug->status );
}

#MC - Print the Resolution if different from Fixed
$t_resolution = '';
if ( ON == config_get( 'enable_print_resolution_in_status_resolved' ) ) {
    if( $t_bug->status == '80') { #Solved
        if($t_bug->resolution != '20') { #Fixed
            $t_resolution = ' (' . get_enum_element( 'resolution', $t_bug->resolution ) . ')';
        }
    }
}

echo ' - ', $t_status[$t_bug->status], $t_resolution, $t_strike_end, '.<br />';

echo ' - ', $t_status[$t_bug->status], $t_strike_end, '.
';

change in config_defaults_inc.php
$g_enable_print_resolution_in_status_resolved = OFF;

in config_inc.php
$g_enable_print_resolution_in_status_resolved = ON;

In 1.2 this can be handled via a custom function (along the lines of what's been suggested in 0009020:0032028), so there should be no need to update Core.

Hi dregad,
do you mean there are a way to add a custom function without touch the core? if yes can you explain me how to do?
thx

Ever thought about reading the manual ? Highly recommended...

http://www.mantisbt.org/docs/master-1.2.x/en/administration_guide/admin.customize.customfuncs.html