Bug 818985 - [ipa webui] Searchsize limit is not used
[ipa webui] Searchsize limit is not used
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Identity_Management_Guide (Show other bugs)
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: Deon Ballard
: Documentation, Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-05-04 10:04 EDT by Namita Soman
Modified: 2012-07-02 15:31 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-02 15:31:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Namita Soman 2012-05-04 10:04:30 EDT
Description of problem:
In configuration, set the search size limit to be 5
With 10 users added, go to user page, and expect only 5 to be listed...but all 10 are listed. 
Same with groups.

But in config page, dropdown to list "Default Users group" lists only 5. 

Tried in cli, and ipa user-find brings back only 5 users

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Add 10 users
2. Set search size limit to be 5
3. Go to user page
Actual results:
display all 10 users and admin

Expected results:
display only 5 users total

Additional info:
Comment 2 Namita Soman 2012-05-04 10:48:34 EDT
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

not a bug - it was designed this way


Beahviour is as expected...so closing
Comment 3 Jenny Galipeau 2012-05-04 11:16:12 EDT
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??
Comment 5 Petr Vobornik 2012-05-07 07:43:31 EDT
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).

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
Comment 6 Dmitri Pal 2012-05-09 08:26:09 EDT
IMO we should document all of the above in a special section talking about search limits. Reassigning.
Comment 7 Deon Ballard 2012-06-26 23:09:34 EDT
I added a new subsection in the part on search settings:
Comment 10 Deon Ballard 2012-07-02 15:31:47 EDT
The internal url has been changed to example.com.

Note You need to log in before you can comment on or make changes to this bug.