There's a disabled flag, it has no pending requests, there's no reason to show it in the flag list. If someone is using the flag, then it's ok to show it in the list. But when the list is generated it should limit itself to flags that are at least used or enabled. This means that people would have to reload the request queue after someone either enables or uses an unused and disabled flag in order to see it. I believe that is a perfectly reasonable requirement. Steps: 1. create a disabled and unused flag. Perhaps "checkin". To make things interesting, fight over the flag, use it for a bit, kill off all requests for it and then disable it. 2. load the request queue. 2' <th>Flag:</th> <td><select name="type" > <option value="all">all </option> ... <option value="checkin">checkin </option> ... <option value="testcase">testcase </option> </select> </td> Expected results: flag doesn't appear in the list.
In order to know which flags to display, you would have to look for them in the DB which is very time consuming IMO.
Hmm... This looks like as simple as: select distinct flagtypes.id from flagtypes left join flags on flags.type_id = flagtypes.id where flags.id is not null; Yes, we can do that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Created attachment 334480 [details] [diff] [review] patch, v1
Assignee: attach-and-request → LpSolit
Status: NEW → ASSIGNED
Attachment #334480 - Flags: review?(ghendricks)
Created attachment 334489 [details] [diff] [review] patch, v2 This 2nd patch seems to be much more efficient based on tests done by ghendricks, dkl and reed on their respective production (or clone of) installation. Times are now comparable to what we get without the patch, versus a factor of 10-30 with my previous patch.
Target Milestone: --- → Bugzilla 3.4
Checking in request.cgi; /cvsroot/mozilla/webtools/bugzilla/request.cgi,v <-- request.cgi new revision: 1.48; previous revision: 1.47 done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.