let's see... i can't use request mail because we don't deliver it to me (bug 179701) if bug 184251 was fixed then i could use the request queue but when i'm looking at a request i couldn't go to the next request because requests aren't treated as buglists. What I'd like: Requests: First Prev Next Last | This is request 3 of 20 in _your list_. <Link rel> for the requests. If I happen to go to a request which isn't in my list, we could do something like: Requests: First Prev Next Last | View queues of <john>, <sally>, <jane>, ... where john, sally and jane are the requestees/requesters listed on the current request page.
The request queue really just needs to use a different output format from buglist.cgi. That would fix this + a whole host of other bugs.
we should have a link per table in the request queue + a global link including all tables. When clicking one of these links, we should get a buglist with the corresponding bugs in it. This way, we could then navigate as we usually do. This is something I would like to see in 2.24.
This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.
Created attachment 409637 [details] [diff] [review] patch, v1 The (view as buglist) link is displayed below each table, despite having it at the top of each table would probably be better. But I do this this way due to the "complex" check which is done inside the FOREACH loop. And I don't want to loop twice.
Created attachment 409671 [details] [diff] [review] patch, v1.1 Oops, I forgot FILTER html.
Comment on attachment 409671 [details] [diff] [review] patch, v1.1 Having it below each table is fine, but is there a way to avoid having to have it inside a block "start_new_table" which actually refers to a different table? Can't it just be included (once rather than the current twice) at the end of the section which prints the table itself. (Obviously, it's entirely reasonable for the resetting of the buglist variable to be in start_new_table.) Gerv
Created attachment 413448 [details] [diff] [review] patch, v1.2 Small improvement/cleanup, taking gerv's suggestion into account.
Comment on attachment 413448 [details] [diff] [review] patch, v1.2 this is mostly due to my own run-ins with this but we should really avoid closing tags in blocks that open elsewhere. It gets really confusing for future development. I'd prefer for the table to be outside of the block. It makes it easier to read. Other than that it looks fine.
Comment on attachment 413448 [details] [diff] [review] patch, v1.2 <table> itself is created in a block. I don't see how my patch makes things harder.
Checking in template/en/default/request/queue.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/request/queue.html.tmpl,v <-- queue.html.tmpl new revision: 1.24; previous revision: 1.23 done
Added to the release notes in bug 547466.