User search problems in /user request and response #189

Closed
opened 2021-10-02 14:05:57 +02:00 by ajl199 · 5 comments
ajl199 commented 2021-10-02 14:05:57 +02:00 (Migrated from github.com)

You did say you were all ears...

Describe the issue
On the admin web interface User List, entering a string in the search box and clicking the search button has no effect (just returns the current page as before search). There seem to be two issues:

  1. the request (e.g. https://example.com/api/user?offset=40&limit=20&pattern=Adrian) contains an offset parameter, which I don't think it should since whatever page the user is on when searching, they probably want to start at the beginning of their search results; and
  2. the pattern parameter seems to be ignored by the API anyway, because the response contains the correct data for full user list with that limit and offset, which don't match the supplied string.

Expected behavior
Only users whose names/usernames contain the submitted string (case insensitive match) should be returned, starting with offset 0. Forward and back buttons should maintain the pattern parameter while changing offset to page through the search results.

System (please complete the following information):
Docker :src build from 02/10/2021 running on AWS Linux2.

You did say you were all ears... **Describe the issue** On the admin web interface User List, entering a string in the search box and clicking the search button has no effect (just returns the current page as before search). There seem to be two issues: 1. the request (e.g. https://example.com/api/user?offset=40&limit=20&pattern=Adrian) contains an offset parameter, which I don't think it should since whatever page the user is on when searching, they probably want to start at the beginning of their search results; and 2. the pattern parameter seems to be ignored by the API anyway, because the response contains the correct data for full user list with that limit and offset, which don't match the supplied string. **Expected behavior** Only users whose names/usernames contain the submitted string (case insensitive match) should be returned, starting with offset 0. Forward and back buttons should maintain the pattern parameter while changing offset to page through the search results. **System (please complete the following information):** Docker :src build from 02/10/2021 running on AWS Linux2.
babelouest commented 2021-10-02 15:18:51 +02:00 (Migrated from github.com)

Hello @ajl199 ,

You did say you were all ears...

I am!

I can reproduce your issue but I'd like to make sure we're on the same page.
In your request example: https://example.com/api/user?offset=40&limit=20&pattern=Adrian , the option offset=40 means that you are make in search in the 3 page (using the >>).
There, if you make a search, the option offset=40 remains, which leads to an empty result if the result has less than 40 entries.

Does my description fit your issue or am I missing something else?

Hello @ajl199 , > You did say you were all ears... I am! I can reproduce your issue but I'd like to make sure we're on the same page. In your request example: https://example.com/api/user?offset=40&limit=20&pattern=Adrian , the option `offset=40` means that you are make in search in the 3 page (using the `>>`). There, if you make a search, the option `offset=40` remains, which leads to an empty result if the result has less than 40 entries. Does my description fit your issue or am I missing something else?
ajl199 commented 2021-10-02 17:40:19 +02:00 (Migrated from github.com)

Yes, that's right, that's one of the two problems. Equally, even if there were enough results for the user to be on a valid page, normal expectation would be to start on the first page of the returned results.

The other problem is that the results returned don't seem to have been filtered by the search string: if I search for "zzzzzzzzzzz", the browser console shows a 200 response with a JSON body containing 20 real users, who obviously don't have that in their names.

Yes, that's right, that's one of the two problems. Equally, even if there were enough results for the user to be on a valid page, normal expectation would be to start on the first page of the returned results. The other problem is that the results returned don't seem to have been filtered by the search string: if I search for "zzzzzzzzzzz", the browser console shows a 200 response with a JSON body containing 20 real users, who obviously don't have that in their names.
babelouest commented 2021-10-02 18:17:10 +02:00 (Migrated from github.com)

The other problem is that the results returned don't seem to have been filtered by the search string: if I search for "zzzzzzzzzzz", the browser console shows a 200 response with a JSON body containing 20 real users, who obviously don't have that in their names.

That one I can't reproduce yet.
You said earlier you use the database backend with a mysql database right?

> The other problem is that the results returned don't seem to have been filtered by the search string: if I search for "zzzzzzzzzzz", the browser console shows a 200 response with a JSON body containing 20 real users, who obviously don't have that in their names. That one I can't reproduce yet. You said earlier you use the database backend with a mysql database right?
ajl199 commented 2021-10-02 21:13:39 +02:00 (Migrated from github.com)

Yes, that's right. Interesting you can't reproduce it - maybe it is just me! I've attached a somewhat redacted composite screenshot to show what's happening client-side.

image

Yes, that's right. Interesting you can't reproduce it - maybe it is just me! I've attached a somewhat redacted composite screenshot to show what's happening client-side. ![image](https://user-images.githubusercontent.com/46404662/135729254-914a46f2-6c67-4a7d-9e65-87e361c538d6.png)
babelouest commented 2021-10-03 19:43:35 +02:00 (Migrated from github.com)

@ajl199 , I fixed the offset issue in github.com/babelouest/glewlwyd@f52eeca96f but the invalid result remains though.
Although since I'm not able to reproduce it in my tests I suggest you reopen a new issue for this one only and we can start again from there.

@ajl199 , I fixed the offset issue in https://github.com/babelouest/glewlwyd/commit/f52eeca96f6dc37dad026132bf28e48e05560ff6 but the invalid result remains though. Although since I'm not able to reproduce it in my tests I suggest you reopen a new issue for this one only and we can start again from there.
This discussion has been locked. Commenting is limited to contributors.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
KittenSquad/glewlwyd#189
No description provided.