Discussed this with Petr.

======
he said <snippets from irc> :
web ui uses kinda its own search limit for search pages to support paging.
Right now it is hardcoded to 20. It behaves this way: UI sends xxx-find command
with --pkey-only option. The --pkey-only bypasses the limit and gets all pkeys
then UI selects 20 of them (depend on current page) and calls batch command to
fetch data.

--pkey-only limit is 5000

In other controls (mentioned dropdown) the --pkey-only option is not used so
the result is limited.

IMHO this behavior is OK. What we can do is to make the search page size
configurable. For example user-specific config value stored in browser (hmtl 5
local storage).

in dropdowns like selecting a group, limit is enforced. In search pages may be
fetched first 5000 pkeys+DNs and then selected 20 of them to fetch remaining
values

not a bug - it was designed this way

=====

Beahviour is as expected...so closing

I would like more discussion around this since setting the search limits now can be very confusing ... maybe that the minimum should be 20 if the UI is setting it as a hard limit??

There is no point to create some minimum because UI uses limit which can be larger than config 'search limit'. What would we achieve by that?

If we want to do some conclusion we should first mention/define purposes of various limits.

So we have 3 limits:
 1) search limit defined in configuration (default 100 records)
 2) pkey-only limit: In above comment I didn't say it correctly. The limit is 0, that means that it is only limited by ldap server limit which might more than 5000.
 3) page size - hardcoded to 20

I'm not sure what is the original purpose of 'search limit'. IMO it is to limit the amount of data transferred and not to overwhelm user with tons of text. This limit is applied to all commands except those with --pkey-only option. The only thing which uses --pkey-only options are search pages in Web UI. We can conclude that all parts of CLI and Web UI except search behaves consistently and now we should only discuss search pages.

So the question is how many records should the search page show? I don't see a point in limiting the amount of records to 'search limit' if there is a space for displaying the records. Is there a reason the display the same amount of records as the search limit? Also no. The search limit can be much higher - ie 200. It would make the paging somehow weird. User should not scroll vertically a lot. The reasonable amount can be about 1-3 screens which is approximately 20-80 records depending on window size.

So enforcing the 'search limit' in search page is not the right thing.
Is the hard-coded limit to 20 records good? No. But it is the better than 'search limit'. So that's why I mentioned that we might want to make this limit configurable. I think it should be user specific. Storing the value in user record is bad because it is application specific data. So that's the reasoning for storing it in browser. Another option is to make the option dynamic, it can be computed from the size of window (with some minimum size of course).

Conclusion:
IMO we should do one of following options:
 a) leave it as is
 b) make page_size configurable in browser
 c) make page_size dependant on window size

IMO we should document all of the above in a special section talking about search limits. Reassigning.

I added a new subsection in the part on search settings:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/searches.html#types-of-search-limits

The internal url has been changed to example.com.