By default, hide bugs without any activity for the last 2 years
Categories
(bugzilla.mozilla.org :: Extensions, enhancement)
Tracking
()
People
(Reporter: Sylvestre, Unassigned)
References
Details
Attachments
(1 file)
155.88 KB,
image/png
|
Details |
Both in the simple and advanced search
And please give the option in the search to bring the full search
Comment 1•6 years ago
|
||
This will be a user profile setting, not a per query default, correct?
It will be simply a filter on the search page. For example, Feedly searches articles posted in the last 30 days by default (see the screenshot). I’m thinking of the same thing.
Comment 3•6 years ago
|
||
Is it possible to consider having a user profile setting instead of a per-query setting which needs to be selected every time?
I expect that for many users of Bugzilla (e.g. many engineers) they would probably want to use this setting at all times, since the criteria of whether a bug has had any activity in the past N months is often uninteresting when querying Bugzilla looking for technical information. I'm afraid that having a per-query setting would create a situation where people may end up forgetting to set it once in a while and as a result miss some of the search results that they would have found otherwise (something that is impossible to know it's happening to you as it is happening to you.)
Thanks!
Yeah, I’m thinking of saving filter options in the browser’s local storage along with a column list, etc. rather than having a per-query setting. The default options will probably be both open and closed bugs changed in the last 2 years. The new search results page will be completely Ajax-y, so it will be more flexible than the current server-side rendering and also solves many UX issues. Let me interview you later about your search experience since I’m now working in the Toronto office 😄
Comment 5•6 years ago
|
||
awesome |
Happy to chat any time! :-)
Comment 6•6 years ago
|
||
Our internal Bugzilla has countless bugs over 2 years old that are still current and relevant and which should show up in searches, for all staff. I would certainly want this to be something that could be opted out of.
In this case, we would be happy for the threshold to be a site-wide rather than being a per-user setting (with 2 years, or maybe 24 months, as the default, and a value of zero causing the threshold to be disabled).
I won't know until I've had a chance to test it whether or not remembering the last value of this setting for each user on a per-session basis would be a help or a hindrance.
(In reply to Mark Clements from comment #6)
In this case, we would be happy for the threshold to be a site-wide rather than being a per-user setting (with 2 years, or maybe 24 months, as the default, and a value of zero causing the threshold to be disabled).
+1
It's critical that the setting be the same for all so that the results of shared search URLs are consistent.
Comment 9•6 years ago
|
||
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #8)
It's critical that the setting be the same for all so that the results of
shared search URLs are consistent.
Or, that the value of the setting is included in the URL.
The search parameters already exist in the advanced search interface, so it sounds like this bug is about exposing that parameter on the search results page. If so, it should update the URL to include the current setting, so that sharing the URL gives the same results.
This applies to any of the tweakable parameters on the search results page.
Comment 10•6 years ago
|
||
Perhaps I am challenged but I'm having trouble visualizing how this will work. Especially for those of use who use advanced search, and at least in my case I think I don't want any imposed defaults on my advanced searches.
And so I think it would be helpful to map out some examples which demonstrate how the user will be affected, which user type will be helped, and which user type might not be helped.
I also have to wonder whether a new user might search, not find an old bug that matches to their issue, and then when filing a new bug blindly ignore the potential duplicates list. (which could use in improvement - but that's another issue)
Updated•6 years ago
|
Description
•