This is the most requested Mantis enhancement in my organization - PLEASE fix. Thanks!

I agree that this would be useful, so I tried to get in there and figure it out. That filter api code is brutal to sift through though. Wow.

If one of the developers knows how to access the current filter's id from the filter_draw_selection_area2 function this would be a simple matter. Here is an example of what the code might look like (using $t_current_filter_id to represent the current filter's id...duh).

./core/filter_api.php:2028

foreach( $t_stored_queries_arr as $t_query_id => $t_query_name ) {
if ($t_current_filter_id == $t_query_id)
{
PRINT '<option value="' . $t_query_id . '" selected="selected">' . $t_query_name . '</option>';
} else {
PRINT '<option value="' . $t_query_id . '">' . $t_query_name . '</option>';
}
}

I couldn't figure out how to access that variable so I wrote a disgusting workaround that still has some issues but works most of the time. Looking forward to a fix or this.

I agree that this would be a great to fix. However, we need to clarify one thing:

• The user selects a save filter.
• The combo box retains the name of the chosen filter.
• The user modifies ones of the criteria!!

What should happen to the filter name? The options are:

• Use [chosen filter name]* (notice the added star to notify that the filter is dirty and it should be updated. Updating filter is a nice feature that is not supported at the moment.

• Use [Reset Filter] as current behaviour.

I think using [chosen filter name]* is the better option.

P.S. I agree that filter code is the most complex and hardest to maintain in Mantis. That's why I don't touch it :)

Or a third option:

Change the dropdown name to placeholder for temporary filters that could read [Unsaved Filter], or [New Filter], or something similar.

If the filter is checked at each load or manual option change (which I think it is), this would work.

Example Scenario:
Two saved filters, "filter1" -> Assigned to = myself; "filter2" -> Assigned to = myself, Reporter = myself

User selects "filter1", dropdown shows "filter1" after applying the filter.
User manually changes the setting for Reporter to myself, filter is applied and "filter2" is displayed in dropdown.
User manually changes the setting for Monitored By to myself, filter is applied and dropdown shows one of the suggested names from above

I just think the more expected function of selecting a filter and then changing options would be to add a new filter rather than updating the selected filter. At least for me, since my filter names are based on the criteria and changing the criteria would mean changing the name which might as well be a whole new filter.

vboctor's solution is closest to what the users here would like to see. Besides wanting to see which filter is currently selected, they also want to be able to modify existing filters. So if a user loads a filter and changes some of the criteria, he/she would also want to save the changes to that filter. There's always the option of selecting [Reset Filter] in order to create an entirely new one.

As for a workaround, I've seen that the code in view_all_set.php gets the selection from the filter list drop-down near the top in the line
$f_source_query_id = gpc_get_int( 'source_query_id', -1 );
but I haven't been successful in getting it back and using it to set "selected" in the list. I'm not an HTML or PHP developer -- this stuff makes my brain itch.

I see that there are other issues involved that I hadn't considered. So since I can't be of much help development-wise, you have my sponsorship.

EDIT: FYI, my version is 1.0.2 and that is what my line numbers are based off of

Here is the hacky-code that I added to filter_api.php to replace the foreach at line number 2027-2031. It has issues though and is not suggested for production/critical systems. As I said previously I would prefer to track down a way to pass the filter id into the function instead but as a temporary ugly hack to get some of the needed functionality, use at your own risk.

Brief description of the process:
Grab all the filter id's and strings from the filters_table
Sanity check to make sure we have records, somewhat redundant
Strip the first 3 characters off of the filter string that came out of the db
Match the trimmed db string to the serialized filter string of the current filter
When it finds a match, assign the filter id to a variable and use that when matching against the loop of available filters to set as selected.

Shortcomings (to name a few):
Haven't added extra limits on the query that is run, so it will grab all your filters to loop through.
If you select a filter, then try to search on that filter, it doesn't remember the selected name for some reason.
I tried adding a break; after it finds the match so it doesn't keep searching but that was not working for some reason.
Haven't really tested it enough to list others but hopefully this could just be a stop-gap solution to passing the current filter id directly to the function..

<?php
$t_filters_table = config_get( 'mantis_filters_table' );
$t_filter_string = serialize($t_filter);
$t_current_filter_id = NULL;
$query = 'SELECT id, filter_string FROM ' . $t_filters_table;
$result = db_query( $query );
if ( db_num_rows( $result ) > 0 ) {
while ( $row = db_fetch_array( $result ) ) {
if ( substr($row['filter_string'],3) == $t_filter_string ) {
$t_current_filter_id = $row['id'];
}
}
}

if ( !is_numeric( $t_current_filter_id ) ) {
$t_current_filter_id = 0;
}

foreach( $t_stored_queries_arr as $t_query_id => $t_query_name ) {
if ($t_current_filter_id == $t_query_id)
{
PRINT '<option value="' . $t_query_id . '" selected="selected">' . $t_query_name . '</option>';
} else {
PRINT '<option value="' . $t_query_id . '">' . $t_query_name . '</option>';
}
}
?>

I fixed this in my local copy of Mantis (well, UMantis actually) by adding "source_query_id" to the filter_string whenever a filter is selected. Then when the filter-selection menu is displayed, the OPTION values are compared and the "selected" value is set.

I made the following two changes:

./view_all_set.php (approximatly around line 433), inserted:

    $t_setting_arr['source_query_id'] = $f_source_query_id;

./core/filter_api.php (approximately around line 2028), changed to:

                                    $t_setting_arr = filter_deserialize( filter_db_get_filter( gpc_get_cookie( config_get( 'view_all_cookie' ), '' ) ) );
                                    $last_known_query_id = $t_setting_arr['source_query_id'];
                                    foreach( $t_stored_queries_arr as $t_query_id => $t_query_name ) {
                                            PRINT '<option value="' . $t_query_id . '" ' . ($t_query_id == $last_known_query_id ? "selected" : "") . '>' . $t_query_name . '</option>';
                                    }

To be sure, I'm an Mantis novice and there may be a better way of doing this. But it seems to be working for me. I also wrote this before I found this discussion, so it does not address the issues of the user modifying the filter but still showing the old filter name. However, I think it is better than nothing.

Eddie

Filter dropdown now displays the name of the active filter. When modifications are made to the filter they are highlighted to indicate that the selections do not match the stored filter.

As this was also an issue in 1.2.x for which several users requested a fix, I backported daryn's changes as well as dhx's subsequent improvement.

Updating target/fixed in version accordingly.

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch