[patch] Option specifying which search filters should be active by default

[ebray]

I had a user request a trac.ini option to specify a list of search filters that should be active by default. When set, this would override the defaults returned by get_search_filters(), which users otherwise have no control over.

Sure this could be done as a plugin, but I thought it was small and undisruptive enough to suggest as a patch.

[ebray]

A simple patch against r7591 implementing this feature.

[Christian Boos]

Fine by me.

[ebray]

Why am I owner? Do I have commit access?

[Christian Boos]

No, it's simply about giving credits to who wrote the patch, when the patch is likely to be applied without significant rework.

That way, when we look at the milestone page, we can see who actually contributed to that release (and this avoids having a not so informative high ticket count for developers who simply apply patches made by others, like me ;-) ). See for example milestone:0.11?by=owner when Remy was not a committer for most of his tickets.

[Christian Boos]

milestone:0.11.1?by=owner actually

[ebray]

Ah, okay, didn't think so. I never noticed that you were doing it that way before.

[Remy Blank]

I'll test and integrate this shortly.

[osimons]

It sounds useful enough, but I would actually prefer that it was a 'negative' option - meaning turn off the filters you don't want to be enabled by a 'default' search. That way new plugins enabled will work 'out-of-the-box', but can be explicitly disabled by admin.

IIRC the current default list (all) is also the providers used by the Quick Search box, so it may cause some confusion if that search does not return the results that users expect.

[ebray]

Replying to osimons:

It sounds useful enough, but I would actually prefer that it was a 'negative' option - meaning turn off the filters you don't want to be enabled by a 'default' search. That way new plugins enabled will work 'out-of-the-box', but can be explicitly disabled by admin.

IIRC the current default list (all) is also the providers used by the Quick Search box, so it may cause some confusion if that search does not return the results that users expect.

That's a good point—I had thought of that problem, but figured that if an environment administrator were tweaking things that finely to begin with it wouldn't be a problem. Of course there's also the incongruity that having a *blank* value for this option leaves all filters enabled by default, which is inconsistent—you would expect it to disable *all* filters by default.

I'll post an updated patch to make it a negation.

[ebray]

An updated patch that works instead by negation—all filters listed in the disabled_filters option are disabled by default.

[Remy Blank]

Wouldn't it make sense to store the active search filters in session data, in the same way as e.g. the timeline parameters and diff preferences? That way, you would always find the settings from your previous search on the search page.

Erik, would this solution satisfy your user?

[ebray]

Replying to rblank:

Wouldn't it make sense to store the active search filters in session data, in the same way as e.g. the timeline parameters and diff preferences? That way, you would always find the settings from your previous search on the search page.

Erik, would this solution satisfy your user?

For some reason I thought Trac already stored search filters as session attributes, but I guess not. Regardless, that's a different issue. The issue here is that an environment admin wanted to be able to specify the default filters that all users encounter. For some…reason…

I guess one such reason is that there are some environments where the ticket system is being used heavily, but the wiki is not being used very much, and most users only need to search tickets. Now, some of these people are extremely, shall we see, technically challenged. And telling them to deselect "wiki" might make them confused. Or something. That's just my guess as to why this would even be necessary.

[Remy Blank]

Ok, I'll go ahead with your patch, then.

[Remy Blank]

Patch applied in [7691]. I named the option default_disabled_filters instead of disabled_filters, though, and added wording to the help text that this also impacts the quick search function.