Duplicate names break “manage presenters” UI

[pcantrell]

0. Create multiple participants with different emails but identical names.
1. Go to a session presented by the currently logged in user.
2. Click “manage presenters” (below the title).
3. Search for the duplicate name.
4. The always finds the same one of the duplicate users; it is impossible to add any of the others. This can make it impossible to add a presenter who has created multiple accounts with multiple emails — unless by luck the system just happens to find the most recent user first. It will also bite us as soon as we have two presenters with the same name.

[brycehowitson]

I'm running into the same issue. Is it worth displaying an email address as well to differentiate between records?

[unsay]

We managed to manually right the presentations last night.

To compound the issue, the Twitter autocomplete library, rest in peace, is no longer around and appears to not handle id and name pairs.

The selected name is passed to Rails, and it then does another lookup which AFAIK will result in always the first "John Doe" match, but not necessarily the one that was selected. I suspect it's going to be the one with the lowest ID.

sessionizer/src/app/controllers/presentations_controller.rb

Lines 12 to 14 in 37a8eaa

	# super lame: look up the person by name. Twitter's typeahead library doesn't currently have a way to report an item's been selected.
	participant = Participant.where(:name => params[:name]).first

Recommendation

First, replace the library with a more correct library where we can pass the selected ID (user's intent).

1. A thought is to only provide autocomplete with a list participants who have accepted the current CoC, removing the problem with old accounts.
2. We could present a masked email and/or email lookup in autocomplete for more specific selection when there are two people with the same name.

I'll be putting up a PR to address the issue.

refs #304

/cc @experimatt

[experimatt]

I share your hesitation to display users' email addresses, but I do like the idea of being able to find a user by inputting their email address. This definitely feels like an edge case (that's going to keep popping up) until we 1) address duplicates in the database, and/or 2) work in a better longer term solution.

[unsay]

I provided a report to the team with duplicates so we can manage it better short-term.

PR #305 addresses a more fundamental issue where even if there 2 or more people who show up in the user interface, the same one will always be looked up by the database.

Agreed on finding by email. It will take more work since the endpoint is not a search endpoint, but an in-browser search of the participant universe. We cannot expose emails there as a UX patch without doing it correctly...too public.