Closed
Bug 304267
Opened 19 years ago
Closed 15 years ago
Large lists in admin pages fail to display (they take too much time)
Categories
(Bugzilla :: Administration, task, P1)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.4
People
(Reporter: timeless, Assigned: mockodin)
References
()
Details
(Keywords: perf, regression)
Attachments
(2 files, 12 obsolete files)
15.41 KB,
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
14.43 KB,
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
this bug is being filed preemptively. TT doesn't support incremental, so any page that takes a long time to prepare, and the full 200,000 user world from bugzilla counts, will be killed by apache instead of being returned. since bugzilla can scale, and it's impossible to know what is in the list without having the list (which is the reason for getting the list), this can block me from getting certain work done. either TT needs to be killed, hacked, mangled, munged, mutilated, expunged, or we need some way to avoid it. [2005-08-10 22:13:42] fwiw Size: 36428882 that's the result of my editusers request 212150 users found. bugzilla properly returned the page
the request started some time before 2005-08-10 21:47:22, at which point i observed: Received 14 MB, avg 38 kB/s, cur 40 kB/s
Target Milestone: --- → Bugzilla 2.22
Comment 2•19 years ago
|
||
Can't this be avoided by having editusers limit the number of rows it fetches to something more modest (like 1000) and provide .... "1-1000 shown of 235000: next 2 3 4 5 ... last" links. ??
Comment 3•19 years ago
|
||
Suggest confirming. I can suggest one thing to do: Break the page into 3 sections. The script would spit out the first section, spit out the second section once for each user mached, and finally spit out the last section. That way Apache would know that the script is still working. You could also add a "Please stand by" push at the start. Comment 2 is also an option. Hardware & OS are are inaccurate. Also, is this really blocking development & testing of Bugzilla?
Updated•19 years ago
|
Severity: blocker → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: TT will break edit users for long lists → Extremely large lists of users in editusers.cgi fail to display
oh sure, make me spider bugzilla to get the data i need. please no, you really really really don't want me to do that. i filed it as a blocker because i want it to block the release because it will block me from doing maintenance on bmo.
Blocks: bmo-regress-20051022
Comment 5•18 years ago
|
||
(In reply to comment #0) > TT doesn't support incremental Hum, is that true???
Comment 6•17 years ago
|
||
Due to bug 302955 even just 2000 users takes 108 seconds to display. This is extremely/unusably slow.
Assignee: administration → bugzilla-mozilla
Depends on: 302955
Summary: Extremely large lists of users in editusers.cgi fail to display → Large lists of users in editusers.cgi fail to display
Comment 7•17 years ago
|
||
Do it in 12 seconds instead. Changes overrides to use hashes instead. This should not be a problem as overrides takes the first matching hash within the array anyway (see usage of [% LAST %] in the existing code). I prevented possible problems by changing the order in which the 'value match hash' is filled E.g. before admin/table.html.tmpl would take the order it was pushed. Now with hashes, the override you want to have in the end MUST be set last. This because the previous 'overridden values hash' --4th hash-- will be overwritten. The intention is going from searching e.g. possibly 2000 overridden lists manually to just looking quickly in a few hashes. Speedup for me is from 108 to 12 seconds for 2000 results (which IMO is still slow).
Attachment #252513 -
Flags: review?(LpSolit)
Comment 8•17 years ago
|
||
Comment on attachment 252513 [details] [diff] [review] Patch v1 >Index: template/en/default/admin/custom_fields/list.html.tmpl > [% FOREACH field_type = field_types.keys %] >+ [% overrides.type.type.field_type = { > override_content => 1 > content => field_types.${field_type} >+ } Must be: overrides.type.type.$field_type (note the $ before field_type). >Index: template/en/default/admin/fieldvalues/list.html.tmpl >+ [% overrides.action.name.$static_value = { This doesn't work if $static_value is an empty string. You can try to delete the "" resolution. The "Delete" link should not be displayed. >Index: template/en/default/admin/groups/list.html.tmpl >+ chartgroup = Param("chartgroup") >+ insidergroup = Param("insidergroup") >+ timetrackinggroup = Param("timetrackinggroup") >+ querysharegroup = Param("querysharegroup") This part doesn't work at all. No group is reported as being one of these 4 special groups. >Index: template/en/default/admin/products/list.html.tmpl >+[% overrides.disallow_new.disallow_new = { >+ "1" => { >+ override_content => 1 >+ content => "No" >+ } >+ "0" => { >+ override_content => 1 >+ content => "Yes" >+ } > %] There is a missing } for the "0" key.
Attachment #252513 -
Flags: review?(LpSolit) → review-
Comment 9•17 years ago
|
||
Oh, and I forgot: it doesn't pass tests: Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t/008filter.t 3 768 272 3 1.10% 42 68 105
Status: NEW → ASSIGNED
Comment 11•16 years ago
|
||
The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Assignee | ||
Comment 12•15 years ago
|
||
(In reply to comment #6) > Due to bug 302955 even just 2000 users takes 108 seconds to display. This is > extremely/unusably slow. Seeing same behavior or longer for similar user count running a empty search to return all users. So long as the return is small it's not too bad.. still.
Assignee | ||
Comment 13•15 years ago
|
||
The specific section of admin/table.html.tmpl that appears to be causing the bulk of the slow down is the override FOREACH loop: [% FOREACH override = overrides.${c.name} %] [%# Is the override for this row? %] [% IF override.match_value == row.${override.match_field} %] [% SET contentlink = override.contentlink IF override.override_contentlink %] [% SET content = override.content IF override.override_content %] [% SET content_use_field = override.content_use_field IF override.override_content_use_field %] [% SET align = override.align IF override.override_align %] [% SET class = override.class IF override.override_class %] [% SET allow_html_content = override.allow_html_content IF override.override_allow_html_content %] [% SET yesno_field = override.yesno_field IF override.override_yesno_field %] [% LAST %] [% END %] [% END %] When the above is commented out the script returns in a timely manner.
Assignee | ||
Comment 14•15 years ago
|
||
(In reply to comment 9) Frédéric can you comment on what part of test failed? Going to look at incorporating comment 8 corrections into comment 7 attachment perhaps make the difference in the testing?
Assignee | ||
Comment 15•15 years ago
|
||
Addressed what I could as a fly by, some of the files had changed since Attachment 252513 [details] [diff] was created. Specifically:
template/en/default/admin/fieldvalues/list.html.tmpl has changed.
The correction for template/en/default/admin/groups/list.html.tmpl may be too ugly, suggestions?
Can this bug be reassigned to me?
Testing against a user table of 2900 users it took 15 seconds to generate. Previously it took about 5 minutes load. So even with the proposed changes we're looking at a processing rate of 194 records per second. This was on a mid range overloaded server so on a dedicated production server performance increases should be moderate to significantly improved.
Attachment #373386 -
Flags: review?(LpSolit)
Updated•15 years ago
|
Assignee: bugzilla-mozilla → m.thomas
Assignee | ||
Updated•15 years ago
|
Target Milestone: Bugzilla 3.2 → Bugzilla 3.6
Version: 2.21 → 3.5
Comment 16•15 years ago
|
||
The version field shouldn't be updated. 2.21 was really the version in which this problem was discovered. And if nobody fixed the code meanwhile, it's expected that newer releases are still affected by the problem.
Version: 3.5 → 2.21
Assignee | ||
Comment 17•15 years ago
|
||
Attachment #373386 -
Attachment is obsolete: true
Attachment #373441 -
Flags: review?(LpSolit)
Attachment #373386 -
Flags: review?(LpSolit)
Comment 18•15 years ago
|
||
If the win is as important as I can read in comment 7 and comment 15, that's something I definitely want in Bugzilla 3.4 (not a blocker though). It's unfortunately too invasive for 3.2.
Severity: minor → normal
Priority: -- → P1
Target Milestone: Bugzilla 3.6 → Bugzilla 3.4
Assignee | ||
Comment 19•15 years ago
|
||
As far as importance, it doesn't appear overly noticeable for general user interaction. It's on the admin side so, waiting for 3.4 isn't a big deal. Similar behavior does, I believe, occur else where but not nearly as noticeably. Given that this issue was opened quite sometime ago it would be nice get it finalized and in the release queue. Lest is fall by wayside again.
Comment 20•15 years ago
|
||
Comment on attachment 373441 [details] [diff] [review] Corrected Missing " and missed a function >Index: template/en/default/admin/table.html.tmpl You have to update the description of overrides in the INTERFACE. >Index: template/en/default/admin/groups/list.html.tmpl >+[%# Define Special Groups Names If They Exist, Else Make One up %] Comments Do Not Need To Be Written Like This. They are just normal sentences, after all. But this comment can go away anyway for the reason below: >+[% IF Param("chartgroup") %] >+ [% chartgroup = Param("chartgroup") %] >+[% ELSE %] >+ [%# Becuase something needs to exist %] >+ [% chartgroup = 'CHARTGROUP_UNDEF' %] >+[% END %] This hack is useless. Param("chartgroup") is always defined (it's empty if not in use). We don't care if another special group is empty, because empty group names are not allowed, so we will never trigger this code anyway. This remark also applies to the other special groups. >Index: template/en/default/admin/users/list.html.tmpl >+ [% overrides.realname.login_name.${thisuser.login_name} = { >+ content => "missing" >+ override_content => 1 >+ class => "$classes" >+ override_class => 1 >+ } > %] >+ [% overrides.realname.login_name.${thisuser.login_name} = { >+ class => "bz_inactive" >+ override_class => 1 >+ } > %] The second hash overrides the first one (with the array approach, changes are additive, not exclusive), and so some data is missing in the output. You probably need to refactor this code a bit to avoid this problem. Otherwise, your patch looks good. But I'm much less impressed by the performance gain of this patch than you. With 4000 users, listing them all takes 8.9 seconds without your patch, and 7.5 seconds with your patch. The ratio is much less impressive than numbers you reported (but it's still a 17% gain).
Attachment #373441 -
Flags: review?(LpSolit) → review-
Assignee | ||
Comment 21•15 years ago
|
||
(In reply to comment #20) >You have to update the description of overrides in the INTERFACE. Documentation?! Bah, stole/readded the details provided by Olav Vitters in attachment 252513 [details] [diff] [review] as those seemed valid still. >This hack is useless. Param("chartgroup") is always defined (it's empty if not >in use). We don't care if another special group is empty, because empty group >names are not allowed, so we will never trigger this code anyway. >This remark also applies to the other special groups. Not entirely, the issue is how do you define potentially multiple empty strings as a hash key array. I made it a little less hackish though. Might need a little guidance on what I'm trying to do, should be understandable, I think, though as my brain is failing to shift between tasks today my code might be looking mangled. >The second hash overrides the first one (with the array approach, changes are >additive, not exclusive), and so some data is missing in the output. You >probably need to refactor this code a bit to avoid this problem. Ah yes, if both of the IF THEN are met then it would override moved things around a bit to make it 'nicer'
Attachment #373441 -
Attachment is obsolete: true
Attachment #375231 -
Flags: review?(LpSolit)
Updated•15 years ago
|
Attachment #375231 -
Flags: review?(LpSolit) → review+
Comment 22•15 years ago
|
||
Comment on attachment 375231 [details] [diff] [review] Bugzilla 3.4 Patch >Index: template/en/default/admin/users/list.html.tmpl >+ [%IF thisuser.disabledtext %] Nit: missing whitespace before IF. > [% END %] >+ > [% END %] Nit: useless newline. The patch looks good to me and is working fine. r=LpSolit To better reflect improvements brought by this patch, you need a large override hash, which I didn't have in my previous tests. Here are some interesting numbers: # of disabled users | time w/o patch | time w/ patch 666 17 s 1.5 s 1111 48 s 2.4 s 2222 3 min 4.8 s 3333 timeout 7.1 s 4000 timeout 8.6 s
Updated•15 years ago
|
Flags: approval3.4+
Flags: approval+
Comment 23•15 years ago
|
||
Comment on attachment 375231 [details] [diff] [review] Bugzilla 3.4 Patch >Index: template/en/default/admin/groups/list.html.tmpl >+[% IF Param("chartgroup") %] >+ [% overrides.action.name.Param("chartgroup") = { >+ override_content => 1 >+ content => "(used as the 'chartgroup')" >+ } >+ %] >+[% END %] >+[% overrides.action.isbuggroup => { >+ "1" => { >+ override_content => 1 >+ content => "Delete" >+ override_contentlink => 1 >+ contentlink => del_contentlink >+ } >+ } Oh, I just realized that this template is broken. If a user group is special, the Delete link should not be displayed. But as we store stuff in hashes, we cannot control which override rule will win and in my testing, the Delete link is always displayed. I wonder if a sortkey is required in this case as we cannot use the same trick as in users/list.html.tmpl. Also, to pass 008filter.t tests, the last block must be | isbuggroup = | instead of | isbuggroup => |. >Index: template/en/default/admin/products/list.html.tmpl >+[% overrides.disallow_new.disallow_new = { >+ "1" => { >+ override_content => 1 >+ content => "No" >+ }, >+ "0" => { >+ override_content => 1 >+ content => "Yes" >+ } >+ } > %] Note that due to the checkin of bug 493090 which occured a few minutes ago in Bugzilla 3.5, this change in products/list.html.tmpl is no longer needed. So you will have to provide two separate patches, one for 3.5, and one for 3.4.
Attachment #375231 -
Flags: review+ → review-
Updated•15 years ago
|
Flags: approval3.4+
Flags: approval+
Comment 24•15 years ago
|
||
(In reply to comment #23) > is always displayed. I wonder if a sortkey is required in this case as we > cannot use the same trick as in users/list.html.tmpl. Thinking about it a bit more, I think a sortkey is overkill. It's probably enough to have an |important => 1| key/value pair, as we have for CSS rules (!important).
Comment 26•15 years ago
|
||
Michael, do you think you will have time to update your patch within 48 hours? That's something I would like to have ready on time for 3.4rc1. Else it will go into 3.4rc2.
Assignee | ||
Comment 27•15 years ago
|
||
(In reply to comment #23 && comment #24) Alright, can't say I fully follow. Is this what your saying: The code blocks similar to: >+[% IF Param("blahblah") %] ... >+[% END %] Are being effected incorrectly by: >+[% overrides.action.isbuggroup => { ... >+ } To resolve we should add important => 1 to: >+[% IF Param("blahblah") %] ... >+[% END %]
Assignee | ||
Comment 28•15 years ago
|
||
quick update to address bug 493090 dropped patch for as requested in comment #23 : template/en/default/admin/products/list.html.tmpl Additional changes from comment #23 will be addressed after clarification requested in comment #22
Assignee | ||
Updated•15 years ago
|
Attachment #375231 -
Attachment description: Patched for Comment 20 → Bugzilla 3.4 Patch
Assignee | ||
Updated•15 years ago
|
Attachment #379180 -
Attachment description: Bugzilla 3.5 version attachment 375231 → Bugzilla 3.5 patch
Comment 29•15 years ago
|
||
wow, I don't know which patch you attached, but it has nothing to do with this bug. Comment 27 is correct, we should add important => 1 so that admin/table.html.tmpl can loop and take the first one it finds with important => 1. If there is no override rule with important => 1, then it takes the one it wants (there should be only one key in that case anyway).
Assignee | ||
Comment 30•15 years ago
|
||
(In reply to comment #29) copy and paste ftw! Yeah opps.
Assignee | ||
Comment 31•15 years ago
|
||
Attachment #375231 -
Attachment is obsolete: true
Attachment #379186 -
Flags: review?(LpSolit)
Assignee | ||
Comment 32•15 years ago
|
||
Attachment #379180 -
Attachment is obsolete: true
Attachment #379188 -
Flags: review?(LpSolit)
Comment 33•15 years ago
|
||
Comment on attachment 379186 [details] [diff] [review] Bugzilla 3.4 Patch v3 >Index: template/en/default/admin/table.html.tmpl There is no code which knows what to do with important => 1.
Attachment #379186 -
Flags: review?(LpSolit) → review-
Comment 34•15 years ago
|
||
Also, please fix my nits from comment 22.
Comment 35•15 years ago
|
||
Comment on attachment 379188 [details] [diff] [review] Bugzilla 3.5 Patch v1 Same problem here.
Attachment #379188 -
Flags: review?(LpSolit) → review-
Assignee | ||
Comment 36•15 years ago
|
||
(In reply to comment #33) Sigh, ok, I thought you meant that handling was in place and we just needed to add the important => 1 parameter. I'll take a look. Rather than 'important' flag I would think we would want a suppress flag to prevent the possibility that the delete link would be generated. As its possible if CSS was disabled on a client to view the link otherwise. Why it would be disabled who knows but plan for the worst ;-)
Comment 37•15 years ago
|
||
Except that there is no CSS here. I prefer the important => 1 idea.
Assignee | ||
Comment 38•15 years ago
|
||
Added to template/en/default/admin/table.html.tmpl: + [% UNLESS override.important %] + [% SET contentlink = override.contentlink + IF override.override_contentlink %] + [% END %] - [% SET contentlink = override.contentlink - IF override.override_contentlink %]
Attachment #379186 -
Attachment is obsolete: true
Attachment #379212 -
Flags: review?(LpSolit)
Assignee | ||
Comment 39•15 years ago
|
||
same edit as Comment #38
Attachment #379188 -
Attachment is obsolete: true
Attachment #379214 -
Flags: review?(LpSolit)
Comment 40•15 years ago
|
||
Comment on attachment 379212 [details] [diff] [review] Bugzilla 3.4 Patch v4 >Index: Bugzilla/User.pm >=================================================================== >RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v >retrieving revision 1.185 >diff -u -r1.185 User.pm >--- Bugzilla/User.pm 11 Apr 2009 23:33:26 -0000 1.185 >+++ Bugzilla/User.pm 29 Apr 2009 00:40:41 -0000 >@@ -1651,7 +1651,7 @@ > $dbh->sql_position(q{':'}, 'eventdata') . "- 1)) = ?) > OR (tokentype = 'emailnew' > AND SUBSTRING(eventdata, (" . >- $dbh->sql_position(q{':'}, 'eventdata') . "+ 1)) = ?)", >+ $dbh->sql_position(q{':'}, 'eventdata') . "+ 1 ), LENGTH( eventdata ) ) = ?)", > undef, ($username, $username)); > > if ($eventdata) { This has nothing to do with this patch. Please make sure to attach the right patch. >Index: template/en/default/admin/table.html.tmpl >+ [%# important indicates that for one reason or another we don't want override as we normally would %] >+ [% UNLESS override.important %] >+ [% SET contentlink = override.contentlink >+ IF override.override_contentlink %] >+ [% END %] No, this logic is wrong. First, you have to override current values entirely or not at all; you cannot do it partially only. Secondly, if important is set, you omit the override, which is the exact opposite of what we want. Please make sure to test your patch before uploading a new one (go to editgroups.cgi and check what is displayed there).
Attachment #379212 -
Flags: review?(LpSolit) → review-
Updated•15 years ago
|
Attachment #379214 -
Flags: review?(LpSolit) → review-
Comment 41•15 years ago
|
||
Comment on attachment 379214 [details] [diff] [review] Bugzilla 3.5 Patch v2 Same remark. Wait for one patch to be approved before attaching the other one.
Comment 42•15 years ago
|
||
Michael, any help needed for the remaining bits of the patch?
Assignee | ||
Comment 43•15 years ago
|
||
Sorry for delay went on vacation for a week. Happy back to work again. Already I have been pondering how to implement this. As you pointed out being I'm making this a hash instead of an array means that the rule iteration changes. Issue I'm looking at it looks to me like the file needing changing is /template/en/default/admin/table.html.tmpl but this means the change effect more than just /template/en/default/admin/groups/list.html.tmpl Another part is that the check for inclusion of the delete link is looking at overrides.action.isbuggroup.1 where the suggestion to add the important => 1 puts the setting in overrides.action.name.<groupname> In two different columns, name vs action. So they process are different times. Question is name ALLOWS processed firs? I'm thinking it's not a guarantee, but maybe it is? If it is that we can capture the important flag and skip processing action and provide some alternate content like displaying "Is Special" or something hopefully more descriptive. If its not I will need to cycles through the columsn twice first to retrieve the important flag then use it to supress, might be better to use a new hash to check against. using column and name of the object (component, product, group etc..) example: overrides.important.<object.name>
Comment 44•15 years ago
|
||
(In reply to comment #43) > In two different columns, name vs action. So they process are different times. We don't care. What we care about is one cell of one column only. So the FOREACH loop in table.html.tmpl will look at each key and keep the first one it sees with important => 1. If there is no such key, keep the first key it found.
Assignee | ||
Comment 45•15 years ago
|
||
Ok did some review here, I don't think the important flag is needed at all. Anytime we want to do a special override we are putting a hash here: overrides.<column name>.name.<value the will match row.name value> this is a direct translation of the array tree to a hash tree So given that we just need to look at overrides.${c.name}.name.${row.name} while in table.html.tmpl if we have a hash there matching the current row.name then ignore the normal override in favor of the "important" one I have working code based on what was desired. I will have it up shortly. I will post changes for 3.4 ONLY till it is reviewed.
Assignee | ||
Comment 46•15 years ago
|
||
Oh and special overrides are not limited just to groups/list.html.tmpl but would have broken in the following as well: template/en/default/admin/fieldvalues/list.html.tmpl template/en/default/admin/milestones/list.html.tmpl
Assignee | ||
Comment 47•15 years ago
|
||
Other than support for "special" overrides an important change is that the processing for the overrides is dynamic rather than multiple IF blocks. If there is only 1 key then only one loop. This is a change from evaluating for each override type on every matching column. Not a huge savings but over a very large list should shave off another few seconds potentially.
Attachment #379212 -
Attachment is obsolete: true
Attachment #381665 -
Flags: review?(LpSolit)
Assignee | ||
Comment 48•15 years ago
|
||
removed for extra code -- One Day I'll stop doing that, apparently not today --
Attachment #381665 -
Attachment is obsolete: true
Attachment #381665 -
Flags: review?(LpSolit)
Assignee | ||
Updated•15 years ago
|
Attachment #381669 -
Flags: review?(LpSolit)
Comment 49•15 years ago
|
||
Comment on attachment 381669 [details] [diff] [review] Bugzilla 3.4 Patch v5 Where is the important hash defined in templates? >Index: template/en/default/admin/params/bugfields.html.tmpl >=================================================================== >RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/params/bugfields.html.tmpl,v >retrieving revision 1.5 >diff -u -p -r1.5 bugfields.html.tmpl >--- template/en/default/admin/params/bugfields.html.tmpl 10 Dec 2008 18:43:29 -0000 1.5 >+++ template/en/default/admin/params/bugfields.html.tmpl 18 Apr 2009 03:44:38 -0000 >@@ -56,5 +56,7 @@ > "entry form.<br> " _ This has nothing to do here. Incomplete removal.
Assignee | ||
Comment 50•15 years ago
|
||
(In reply to comment #49) > (From update of attachment 381669 [details] [diff] [review]) > Where is the important hash defined in templates? It's not, unless you'd like me to rename the .name to .important there was no reason to change what was already there. Rather it was incomplete code in table.html.tmpl when processing overrides when I initially made the change. In fact looking around, the change I made initially would have broken components/list.html.tmpl as well I'm sure other places I have yet to go back and look it: - [% overrides.initialqacontact.push({ - match_value => component.name - match_field => 'name' + [% overrides.initialqacontact.name.${component.name} = { override_content => 1 content => component.default_qa_contact.login - }) + } %] So unless we are changing .name to .important everywhere... This has the desired effect and is indeed identical to the old results. the code that reads and processes the special overrides is in table.html.tmpl + [%# Get any specific "important" overrides for this c.name and row.name ? %] + [% SET important = overrides.${c.name}.name.${row.name} %] + + [% IF important %] blah blah blah... > This has nothing to do here. Incomplete removal. /sigh fixed
Attachment #381669 -
Attachment is obsolete: true
Attachment #381673 -
Flags: review?(LpSolit)
Attachment #381669 -
Flags: review?(LpSolit)
Assignee | ||
Updated•15 years ago
|
Attachment #379214 -
Attachment is obsolete: true
Updated•15 years ago
|
Attachment #381673 -
Flags: review?(LpSolit) → review-
Comment 51•15 years ago
|
||
Comment on attachment 381673 [details] [diff] [review] Bugzilla 3.4 Patch v5 - removed extra code v2 >Index: template/en/default/admin/groups/list.html.tmpl >+[% FOREACH group IN ["chartgroup", "insidergroup", "timetrackinggroup", "timetrackinggroup", "querysharegroup"] %] timetrackinggroup is declared twice. >+ [% IF Param(group) %] >+ [% overrides.action.name.${Param(group)} = { 008filter.t doesn't like it. Param(group) must be declared elsewhere. >+ content => "(used as the ${group})" single quotes have disappeared. >+ override_contentlink => 1 >+ contentlink => undef No reason to set them. They don't exist in the original code. >+ overrides.type = { >+ 'isbuggroup' => { Nit: you could write: overrides.type.isbuggroup directly. I fixed them myself while testing your patch, so I will attach an updated patch.
Comment 52•15 years ago
|
||
Attachment #252513 -
Attachment is obsolete: true
Attachment #381673 -
Attachment is obsolete: true
Attachment #385027 -
Flags: review+
Comment 53•15 years ago
|
||
Same patch as for 3.4, with the removal of the admin/products/list.html.tmpl file, which is no longer needed.
Attachment #385028 -
Flags: review+
Updated•15 years ago
|
Flags: approval3.4+
Flags: approval+
Comment 54•15 years ago
|
||
tip: Checking in template/en/default/admin/table.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/table.html.tmpl,v <-- table.html.tmpl new revision: 1.11; previous revision: 1.10 done Checking in template/en/default/admin/components/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/components/list.html.tmpl,v <-- list.html.tmpl new revision: 1.7; previous revision: 1.6 done Checking in template/en/default/admin/custom_fields/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/list.html.tmpl,v <-- list.html.tmpl new revision: 1.8; previous revision: 1.7 done Checking in template/en/default/admin/fieldvalues/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/fieldvalues/list.html.tmpl,v <-- list.html.tmpl new revision: 1.10; previous revision: 1.9 done Checking in template/en/default/admin/groups/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/groups/list.html.tmpl,v <-- list.html.tmpl new revision: 1.14; previous revision: 1.13 done Checking in template/en/default/admin/milestones/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/milestones/list.html.tmpl,v <-- list.html.tmpl new revision: 1.7; previous revision: 1.6 done Checking in template/en/default/admin/users/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/users/list.html.tmpl,v <-- list.html.tmpl new revision: 1.7; previous revision: 1.6 done 3.3.4: Checking in template/en/default/admin/table.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/table.html.tmpl,v <-- table.html.tmpl new revision: 1.10.4.1; previous revision: 1.10 done Checking in template/en/default/admin/components/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/components/list.html.tmpl,v <-- list.html.tmpl new revision: 1.6.4.1; previous revision: 1.6 done Checking in template/en/default/admin/custom_fields/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/list.html.tmpl,v <-- list.html.tmpl new revision: 1.7.4.1; previous revision: 1.7 done Checking in template/en/default/admin/fieldvalues/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/fieldvalues/list.html.tmpl,v <-- list.html.tmpl new revision: 1.9.2.1; previous revision: 1.9 done Checking in template/en/default/admin/groups/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/groups/list.html.tmpl,v <-- list.html.tmpl new revision: 1.13.4.1; previous revision: 1.13 done Checking in template/en/default/admin/milestones/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/milestones/list.html.tmpl,v <-- list.html.tmpl new revision: 1.6.4.1; previous revision: 1.6 done Checking in template/en/default/admin/products/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/products/list.html.tmpl,v <-- list.html.tmpl new revision: 1.6.2.1; previous revision: 1.6 done Checking in template/en/default/admin/users/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/users/list.html.tmpl,v <-- list.html.tmpl new revision: 1.6.4.1; previous revision: 1.6 done
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Summary: Large lists of users in editusers.cgi fail to display → Large lists in admin pages fail to display (they take too much time)
Assignee | ||
Comment 55•15 years ago
|
||
Thanks Frédéric.
You need to log in
before you can comment on or make changes to this bug.
Description
•