If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Provide mechanism to run search without disturbing "lists" system




Query/Bug List
7 years ago
4 years ago


(Reporter: gerv, Unassigned)





7 years ago
Bugzilla 4.0 supports multiple concurrent stored buglists, with navigation between them. Very neat. However, doing a search (obviously) affects this system. Quite a few tools (BzAPI being one, but not the only one) do searches of Bugzilla on a user's behalf, using the CSV output. 

There is therefore a risk that such searches will mess up or change a user's list data, in a way which would not be at all obvious and lead to the user concluding that Bugzilla has bugs ("it forgot/reordered my list!").

So, it would be good to have a URL parameter they could add such that the search happens in a way which does not change the list stuff. Max suggested making "list_id=0" on the URL special.


Comment 1

7 years ago
Yeah, I think list_id=0 would be the way. Either that or some special list_id value that means "don't generate a Search::Recent for this." If this turns out to be pretty easy and somebody steps up to do it before we release 4.0, we can take it for 4.0.
Severity: normal → enhancement
Target Milestone: --- → Bugzilla 4.0


7 years ago
Target Milestone: Bugzilla 4.0 → Bugzilla 4.2


6 years ago
Target Milestone: Bugzilla 4.2 → Bugzilla 5.0

Comment 2

5 years ago
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
You need to log in before you can comment on or make changes to this bug.