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

Sometimes the Target Milestone field doesn't list all available milestones

VERIFIED FIXED

Status

mozilla.org Graveyard
Server Operations
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: whimboo, Assigned: justdave)

Tracking

Details

(URL)

(Reporter)

Description

9 years ago
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.

Comment 1

9 years ago
I'm pretty sure this is a bug due to the local hack on b.m.o about disabled milestones.
Assignee: create-and-change → nobody
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Version: 3.2 → other
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 "---")
No longer blocks: 452731
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: regression
Resolution: --- → INVALID
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  ????
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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)
(Reporter)

Comment 5

9 years ago
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.
(Reporter)

Updated

9 years ago
Status: REOPENED → NEW
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.
Assignee: nobody → server-ops
Component: Bugzilla: Other b.m.o Issues → Server Operations
QA Contact: other-bmo-issues → mrz
Assignee: server-ops → justdave
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 8

9 years ago
Thanks Dave! That was absolutely fast. Looks like everything is fine now. Marking as verified.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.