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)

2.21

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
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.

??
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?
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.
(In reply to comment #0)
> TT doesn't support incremental

Hum, is that true???
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
Keywords: perf
Attached patch Patch v1 (obsolete) — Splinter Review
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 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-
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
Too invasive for 2.22.
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0
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
(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.
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.
(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?
Attached patch Updated Patch (obsolete) — Splinter Review
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)
Assignee: bugzilla-mozilla → m.thomas
Target Milestone: Bugzilla 3.2 → Bugzilla 3.6
Version: 2.21 → 3.5
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
Attachment #373386 - Attachment is obsolete: true
Attachment #373441 - Flags: review?(LpSolit)
Attachment #373386 - Flags: review?(LpSolit)
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
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 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-
Attached patch Bugzilla 3.4 Patch (obsolete) — Splinter Review
(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)
Attachment #375231 - Flags: review?(LpSolit) → review+
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
Flags: approval3.4+
Flags: approval+
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-
Flags: approval3.4+
Flags: approval+
(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).
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.
(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 %]
Attached patch Bugzilla 3.5 patch (obsolete) — Splinter Review
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
Attachment #375231 - Attachment description: Patched for Comment 20 → Bugzilla 3.4 Patch
Attachment #379180 - Attachment description: Bugzilla 3.5 version attachment 375231 → Bugzilla 3.5 patch
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).
(In reply to comment #29)
copy and paste ftw!

Yeah opps.
Attached patch Bugzilla 3.4 Patch v3 (obsolete) — Splinter Review
Attachment #375231 - Attachment is obsolete: true
Attachment #379186 - Flags: review?(LpSolit)
Attached patch Bugzilla 3.5 Patch v1 (obsolete) — Splinter Review
Attachment #379180 - Attachment is obsolete: true
Attachment #379188 - Flags: review?(LpSolit)
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-
Also, please fix my nits from comment 22.
Comment on attachment 379188 [details] [diff] [review]
Bugzilla 3.5 Patch v1

Same problem here.
Attachment #379188 - Flags: review?(LpSolit) → review-
(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 ;-)
Except that there is no CSS here. I prefer the important => 1 idea.
Attached patch Bugzilla 3.4 Patch v4 (obsolete) — Splinter Review
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)
Attached patch Bugzilla 3.5 Patch v2 (obsolete) — Splinter Review
same edit as Comment #38
Attachment #379188 - Attachment is obsolete: true
Attachment #379214 - Flags: review?(LpSolit)
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-
Attachment #379214 - Flags: review?(LpSolit) → review-
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.
Michael, any help needed for the remaining bits of the patch?
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>
(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.
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.
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
Attached patch Bugzilla 3.4 Patch v5 (obsolete) — Splinter Review
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)
Attached patch Bugzilla 3.4 Patch v5 (obsolete) — Splinter Review
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)
Attachment #381669 - Flags: review?(LpSolit)
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.
(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)
Attachment #379214 - Attachment is obsolete: true
Attachment #381673 - Flags: review?(LpSolit) → review-
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.
Attachment #252513 - Attachment is obsolete: true
Attachment #381673 - Attachment is obsolete: true
Attachment #385027 - Flags: review+
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+
Flags: approval3.4+
Flags: approval+
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)
Thanks Frédéric.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: