Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

Hmmm, lets discuss this one...

 

> 1)

> When entering IDs into the search field for adding users (labeled

> "Member name or ID"), entering text into the field will activate a

> spinning throbber on the field. While the cursor is in the text

> field the throbber never disappears, and there is no drop down of

> potential matches. However, if you tab out of the field or otherwise

> lose focus, the field changes to the display name of the found record.

 

That’s not the experience I see.  I see a result pretty quickly.  Can you try the demo server?  I think your subject source is not answering the query quickly.  Can you try from GSH?

 

grouperSession = GrouperSession.startRootSession();

SubjectFinder.findAll(searchString, source);

 

Note, I think it should do at least prefix matching, if not substring matching.  Here is a screenshot from demo server

 

 

>

> The search field for adding users is set up as a dojo combo field,

> similar to the combo search field for groups. But unlike the group

> search, the user search does not work for partial search-as-you-type

> results. The dojo logic java class is invoked with a final wildcard

> on the query. But it then calls UiV2Group.lookup() to search, which

> looks up subjects by SubjectFinder.findByIdOrIdentifier(). Unless a

> source Id actually has a wildcard in the name, I think that nothing

> would be found.

 

I think the subject source should add wildcard

 

>

> As far as I can trace the code, it looks like when the field loses

> focus, it does the same query but without the wildcard. This would

> explain why moving from the field exposes the desired result.

 

Right, losing focus will search by id or identifier, which is faster

 

>

> I don't know what the fix should be. Dynamic search results for users

> would be nominally useful, although it would only be on the Id or

> Identifier (not a person's full name string, as the label would suggest).

> But wildcard queries might put a strain on LDAP servers or SQL databases.

> Maybe the optimal fix is to disable partial dynamic search results.

 

Hmmm, it would be nice to do a FAST search.  What subject source type do you use?  How many records are in it?

 

>

> 2) After input of a user's id, hitting enter instead of tab has inconsistent

> behavior depending on prior actions.

>

>   - initially, it will change to the display name, but then flash an error

>   "Select an entity from the search results"

>   - continuing from above, if another id is entered, the result will be

>   successful, *but it will be the previous ID that is added to the group*!

>   - continuing from the previous entry, hitting return after a third entry

>   will flash the error "Select an entity from the search results"

>

> Suggested fix: remove carriage return functionality from the add member form

 

Hmmmm, I think enter key will work with id or identifier?  Or if you select a result from below?

 

Im trying to not edit the dojo combo control too much here…  we need faster queries

 

 

>

> 3)

> The tooltip that shows up when the field is empty is "Enter 2 or more

> characters for searching". This would suggest that it is doing a partial

> search, which isn't functional per #1 above. The wildcard search also happens

> after the first character, without waiting for the minimal 2 characters.

 

But the server will reject it and display the error message

 

>

> 4)

> The label for the field is "Member name or ID". But the search is actually on

> Id or Identifier, not the name attribute or some variation on the user's

> display name.

>

> Suggested fix: change base property groupSearchMemberOrId in

> grouperText/grouper.text.en.us.base.properties to "Member ID or

> unique identifier"

 

It is assumed your subject source searches by name.  If not you can override that label in your own grouper.text.en.us.properties if your subject source doesn’t support searching by name

 

Note, I would like to have a UI admin component available to test subject sources and answer some of these questions…  at some point… J

 

Anyways, let me know your thoughts

Thanks

Chris

 

 

-----Original Message-----
From: Chad Redman (JIRA) [mailto:]
Sent: Thursday, December 08, 2016 4:27 PM
To: Hyzer, Chris <>
Subject: [JIRA] (GRP-1440) Usability of the Add Member dojo search field

 

Chad Redman created GRP-1440:

--------------------------------

 

             Summary: Usability of the Add Member dojo search field

                 Key: GRP-1440

                 URL: https://bugs.internet2.edu/jira/browse/GRP-1440

             Project: Grouper

          Issue Type: Bug

          Components: UI

    Affects Versions: 2.3.0

         Environment: Chrome 54.0.2840.99; Firefox 50.0.2

            Reporter: Chad Redman

            Assignee: Chris Hyzer

 

 

1)

When entering IDs into the search field for adding users (labeled "Member name or ID"), entering text into the field will activate a spinning throbber on the field. While the cursor is in the text field the throbber never disappears, and there is no drop down of potential matches. However, if you tab out of the field or otherwise lose focus, the field changes to the display name of the found record.

 

The search field for adding users is set up as a dojo combo field, similar to the combo search field for groups. But unlike the group search, the user search does not work for partial search-as-you-type results. The dojo logic java class is invoked with a final wildcard on the query. But it then calls UiV2Group.lookup() to search, which looks up subjects by SubjectFinder.findByIdOrIdentifier(). Unless a source Id actually has a wildcard in the name, I think that nothing would be found.

 

As far as I can trace the code, it looks like when the field loses focus, it does the same query but without the wildcard. This would explain why moving from the field exposes the desired result.

 

I don't know what the fix should be. Dynamic search results for users would be nominally useful, although it would only be on the Id or Identifier (not a person's full name string, as the label would suggest). But wildcard queries might put a strain on LDAP servers or SQL databases. Maybe the optimal fix is to disable partial dynamic search results.

 

2) After input of a user's id, hitting enter instead of tab has inconsistent behavior depending on prior actions.

 

  - initially, it will change to the display name, but then flash an error "Select an entity from the search results"

  - continuing from above, if another id is entered, the result will be successful, *but it will be the previous ID that is added to the group*!

  - continuing from the previous entry, hitting return after a third entry will flash the error "Select an entity from the search results"

 

Suggested fix: remove carriage return functionality from the add member form

 

3)

The tooltip that shows up when the field is empty is "Enter 2 or more characters for searching". This would suggest that it is doing a partial search, which isn't functional per #1 above. The wildcard search also happens after the first character, without waiting for the minimal 2 characters.

 

4)

The label for the field is "Member name or ID". But the search is actually on Id or Identifier, not the name attribute or some variation on the user's display name.

 

Suggested fix: change base property groupSearchMemberOrId in grouperText/grouper.text.en.us.base.properties to "Member ID or unique identifier"

 

 

 

 

--

This message was sent by Atlassian JIRA

(v6.4.11#64026)