Lately I noticed that under some circumstances not all Target Milestone entries are shown. I haven't seen this before the upgrade, so it has to be a regression which was introduced by the upgrade to Bugzilla 3.2. Steps to reproduce: 1. Log out of Bugzilla and Log-in again 2. Enter "453299" into Find a bug and click find 3. Open the Target Milestone drop down => Only 11 entries are shown 4. Click on the bug link to reload the page 5. Open the Target Milestone drop down again => All available entries are shown I expect to see all the available (active) milestones at any time. No idea if some of the scripts are broken and some not. Probably it can also be seen with the given URL above.
I'm pretty sure this is a bug due to the local hack on b.m.o about disabled milestones.
You probably caught it while someone was editing the list. We have the ability to restrict milestones so they can't be newly set on a bug (and will only be there if they were already there before). There are indeed only 11 of them enabled in the Core product right now (actually, 12, if you count "---")
OK, I can reproduce this only if I follow the link URL given here, following the STR doesn't work for me because of my default query_format cookie being set to advanced. This only happens with query_format=specific ????
Appears to happen just with the standard show_bug URL as long as you have the cookie present for query_format=specific (go to the query page, click on the Specific tab, then go reload the bug)
The advanced query is normally my default one, but after the re-login I just entered the bug number into the mentioned field. So I probably got the specific query_format. But even after I did a search with the advanced options, opening the found bug and reloading the page several times, the issue can be seen again. So its not related to specific only.
OK, absolutely no relation whatsoever to the query format. There was a bug related to the active flag not getting honored that was fixed a couple days ago. I think what happened is one of the webservers didn't get restarted after the fix was pushed, and mod_perl was caching the old behavior. So it depended which server you hit.
Both servers have been restarted, seems to have cleared up the problem. For future troubleshooting purposes, there is now an X-Backend-Server header included in the HTTP headers which tells you which backend server served the content to you.
Thanks Dave! That was absolutely fast. Looks like everything is fine now. Marking as verified.