master commit 396b48fde3613c359b49ca4b776ee18fa39f3865 Allow an unlimited number of children when expanding the tree node. Although this may create a large vertical expansion, it may also be what the user wants. See BZ comments for more on the approach and alternatives but basically, take this [easy] approach until it's clear that users, or UX, want something else.
*** Bug 848851 has been marked as a duplicate of this bug. ***
master commit 30a6818e7ae101dc8df7edc198c5ee9ac790683e We decided not to allow an unlimited number of child resources be returned when expanding a node in the tree. But there are major problems with simply limiting the children to 200. This is what we do today, and the results are unordered. Meaning you can lose any number of resources of any types and it is not possible to know what you are missing. And we don't indicate that the tree is incomplete. If we add ordering (alphabetical by resource name) you still lose any number of resources, but always the same ones. In this way it is much easier to realize that you are missing child resources (and/or entire child types) because the resources returned obviously stop as some lexigraphical point. Still, we don't want to allow an unbounded fetch in the GUI. The solution here is to move the unbounded fetch to the server side and to introduce SLSB support to prune the results and return the pruned child set. In this way we can limit the max child resources while returning a much more reasonable resource set. The way it works is as follows: There are two variable in use: maxResources Will not return more than this number of resources. If the original fetch exceeds maxResources then maxResourcesByType will be enforced. If, after trimming by type, maxResources is still exceeded, then the tail resources (assuming a sorted set) will be removed to enforce the limit. If <=0 the default (currently set to 1000) will be used. maxResourcesByType If maxResources is exceeded by the initial result set then members of each type will be trimmed down to meet this limit. If <=0 the default (currently set to 200) will be used. The defaults may change after this check-in based on testing results. The GUI will not set these values in the fetch, so the defaults will be applied. The default values can be overriden (and applied to all fetches/sessions) by setting the following system properties (in rhq-server.properties and restarting): rhq.server.findResourcesByCriteriaBounded.maxResources rhq.server.findResourcesByCriteriaBounded.maxResourcesByType So, this allows us to: - Avoid an unbounded fetch. - Have any distribution of child resources of various types as long as the maxResources limit is not exceeded. - Apply an even and understandable pruning when necessary. It does not yet allow us to indicate in the tree which resource types have been pruned. This will be a future enhancement and tracked as https://bugzilla.redhat.com/show_bug.cgi?id=848853.
Test Notes: See the comments in bug 784571.
*** Bug 753141 has been marked as a duplicate of this bug. ***
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.