Selected SharePoint group will display as another user when user name contains group name

[yungfu]

Category

[ ] Enhancement

[x] Bug

[ ] Question

Version

Please specify what version of the library you are using: [3.14.0]

Expected / Desired Behavior / Question

Create a user named Adelve Vance, and a SharePoint group named Van. Add a PeoplePicker as flollowing:

<PeoplePicker
    ....
    defaultSelectedUsers={loginNames}
    principalTypes={[PrincipalType.User, PrincipalType.SharePointGroup]
/>

Input Van in PeopleSelector, and select group Van from options, record group login name Van to loginNames, PeoplePicker will change the displayed Van group to user Adelve Vance immediately. If we leave the defaultSelectedUsers empty, when this PeoplePicker inited with Van group name, it will display people Adelve Vance not groupc Van either.

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[NishkalankBezawada]

Hey @yungfu,

I tried to reproduce this but out of luck. It would be nice if you be more specific with some screenshots code sample etc?

Thanks, Nishkalank

[yungfu]

A user named Adele Vance and a group named Van exist, when you input Van and select group Van in people picker, selected item will changed to Adele Vance one second late. I found when I select group Van , the group login name returned is Van, PeopleSearchService will initialize the selected user next time by a rule, login name contain specified value, but when PeopleSearchService.searchTenant return multi matched items (Adele Vance and Van by key word Van), it will return first item only.

export const Sample = (props)=> {
    const {spfxContext} = props;
    const [users, setUsers] = useState([]);

    const getPeopleItems = (items: any[]) => {
        var users = items.map(item => {
            return {
                id: item.id,
                loginName: item.loginName, 
                displayName: item.text};
        });
        setUsers(users);
    };
    
    const getLoginNames = users => {
        let ids = users?.map(user => {
            let index = user.id.lastIndexOf('|');
            return index > -1 ? user.loginName.substring(index + 1) : user.loginName;
        });
        return ids;
    };

    return (
        <PeoplePicker
            context={spfxContext}
            titleText={"Select a user"}
            defaultSelectedUsers={getLoginNames(users)}
            personSelectionLimit={100}
            principalTypes={[PrincipalType.User, PrincipalType.SharePointGroup]}
            onChange = {getPeopleItems}
            resolveDelay={200} 
      /> 
    );
};

[NishkalankBezawada]

Hey @yungfu Did you try testing using beta version of the controls?

Thanks, Nishkalank

[yungfu]

Hey @NishkalankBezawada unfortunately, in latest built 3.16.0-beta.6203356, I can still reproduce this issue.

[mihkelpoder]

Hey! I would like to add an additional problem case that seems relevant to this bug.

In our tenant, we have one person with multiple users that have similar e-mail addresses, where the email is differentiated only by a suffix in the local part (below is an example). If one selects the person with no suffixes in the email, then for a second, the correct persona is selected, but after the searchTenant query, a person with a suffix is selected instead.

The emails in question have the following shapes:

• [email protected]
• [email protected]
• [email protected]

Consistently, instead of [email protected] being selected, the second email shape is selected instead ([email protected]). In my opinion, I think that it would be better to use the loginName property instead.

Edit: We think that that our issue is related to the fact that the two other users have the searched for email set as their "other emails". The clientPeoplePickerSearchUser query then searches for the email address, finds all three users (one is an exact match, others have the query email in OtherMails, sorts the results by either Email or Key, and returns the first result in the sorted list.

The issue was first noticed with 3.15.0, and is also reproducible in 3.16.0-beta.6488578.