Grouper Users - Open Discussion List

["Redman, Chad Eric" <>]

Ok, all set. I created a pull request (https://github.com/Internet2/grouper/pull/66 ) to handle those custom properties, but feel free to change or reject. This should have minimal impact on existing behavior; if the properties aren't defined or are blank, it will be the status quo, using dojo for autocompletion in all cases.

 

I haven't looked into disabling carriage returns yet -- I suspect they are in the Dojo JS code and haven't dived into that yet.

 

-Chad

 

 

From: Hyzer, Chris [mailto:]
Sent: Monday, December 12, 2016 12:02 PM
To: Redman, Chad Eric <>; Mailing List <>
Subject: RE: [JIRA] (GRP-1440) Usability of the Add Member dojo search field

 

This is great Chad, thanks a lot!

 

Any chance you can submit a patch to v2.3 that includes your change but has some config switches so it doesn’t affect people who want the existing behavior?  Is that the best way forward to make sure your deployment does not diverge from the mainline source?

 

Thanks

Chris

 

From: [] On Behalf Of Redman, Chad Eric
Sent: Monday, December 12, 2016 11:56 AM
To: Mailing List <>
Subject: [grouper-users] RE: [JIRA] (GRP-1440) Usability of the Add Member dojo search field

 

I had tried it with the Unicom docker image and got the same behavior. Trying it today, I'm not getting the same spinner hang, I don't know what's up with that. I also tried it with the quickstart demo and didn't see that problem, just the expected behavior you describe. That helped to narrow it down to LDAP versus JDBC.

 

I didn't expect that a wildcard query on the subject id (even a full id like 712345678*) would take 2 minutes and then time out on our server, but that does seem to be the issue. I didn't see any way around it except by customizing the DojoComboLogic class. What I did was add two new items to grouper-ui.properties, that can whitelist certain pages for autocompletion lookup:

 

# dojo autocompletion for add member/add groups does a wildcard search

# for every character typed. If defined, only allow this for certain

# forms. If undefined, allow for all of them

uiV2.search.autocompleteById.allowedPaths = /UiV2Subject.addToGroupFilter, /UiV2Stem.createGroupParentFolderFilter

uiV2.search.autocompleteSearch.allowedPaths = /UiV2Subject.addToGroupFilter, /UiV2Stem.createGroupParentFolderFilter, /UiV2Group.addMemberFilter

 

The combo field in the subject and stem pages are ok, because they only look up groups and stems using JDBC. The addMember search in the group page is the one hitting LDAP that we want to prevent from wildcard searches. I can post a patch if anyone is interested.

 

The name search isn't so much of an issue, but only because we don't have wildcards in ours (the users can add it as needed). However, the dojoComboLogic class *takes out* the wildcard from the query before doing a name search. I presume that was done with the expectation that the search template already includes a wildcard. So it wasn't useful for us out of the box. In the end, we added a final wildcard to the first name of our Last,First style search. That makes it intuitive enough for our users without hurting performance much. We're already educating them that Last,First searches perform much better with wildcards than do display names, so this is just an extension of that.

 

       <searchType>search</searchType>

         <param>

            <param-name>filter</param-name>

            <param-value>(&amp;(|(uid=%TERM%)(pid=%TERM%)(displayName=%TERM%)(sn=%TERM%))(objectclass=UNCPerson))</param-value>

        </param>

         <param>

            <param-name>firstlastfilter</param-name>

            <param-value>(&amp;(|(sn=%LAST%)(uncPreferredSurname=%LAST%))(|(givenName=%FIRST%*)(eduPersonNickname=%FIRST%*))(objectClass=UNCPerson))</param-value>

        </param>

 

 

 

Item #2 (using carriage returns to submit without picking an entity from the dropdown -> adds an earlier entry instead of the current one) is also there even in the demo quickstart app (so it's not an issue of timing). To summarize, the issue is that, yes, it does resolve the string in the field to an entity if it's an exact match. But the form submission happens before the replacement of the raw string to the entity. So hitting return the first time results in "Select an entity from the search results" even though the page shows it resolved. Entering a different string in the search field and hitting return will give message "Success: entity was added to group", *but the entry added will be that of the previous entity*. That's a serious issue, and not easy to notice, especially when the group already has more than a few members and you don't notice one appearing that you didn't want.

 

-Chad

 

 

 

From: [] On Behalf Of Hyzer, Chris
Sent: Thursday, December 08, 2016 5:28 PM
To: Mailing List <>
Subject: [grouper-users] RE: [JIRA] (GRP-1440) Usability of the Add Member dojo search field

 

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) []
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)