Sync & store slack handles on Customer

[chungl]

Many denhac members do not use their name as their slack handle. It is common for members to be known to other members exclusively/primarily by their slack handle. We store several name fields on Customers, but none of them are slack handle. This causes confusion/inconvenience when trying to look up member accounts for tasks including equipment authorization and incident investigation.

Notably, slack handles can be changed by the user. We need to watch for update events from slack and keep this field up to date.

It is my opinion that slack handle and Customer->username should be the same. username is infrequently used/visible, and often different from the slack handle. Some longtime members have laughed when identified by their customer username, saying "oh that's very old I had no idea I was still using that anywhere". Counterpoint: I believe username can be used to log in to wordpress. It would be confusing to some users if their login username suddenly changed. Personally, I'd rather disable that if possible and make people log in with their email addresses.

[Jnesselr]

You can log in on the website with either your username or email address, but username is a requirement. It's easy to add a field to the customers table that's just the slack_username, no need to override the username field. It's also useful to note that Slack has several names, and based on some testing I did just now, trying to at someone will work with autocomplete for their "real_name" and "display_name" field under the "profile" section, but not always the name field. A little confusing, but we can store both slack_real_name and slack_display_name.

We could also just add a slack users_select as well in these menus or even switch entirely over to that. We'll just lose the ability to see if someone is a member or not in that view. I don't know what you're looking at for incident investigation, though.

[chungl]

Look up these customer IDs in Wordpress and tell me you are able to quickly, easily, and reliably tell me their slack handles.

570, 1046, 370, 980, 992, 518, 576, 1009, 243

Then, tell me that you as a non-admin user could figure out who this or this person is on slack, given that you only have access to their display_name instead of display_name, first_name, last_name, username, nickname, and email.

I looked through 40 names from our customer database to create this list. From 40 names, I found at least ten (25%) that are difficult, if not impossible, for an admin to connect a slack profile to. Evan and I have both experienced difficulty figuring out how to contact a person on slack even after we've identified them from a badge scan and found their wordpress account. Now that we're doing the events plugin project and giving non-admins a list of wordpress members who are attending their class, it's even more problematic. It's only marginally more feasible to connect the wordpress attendee list to slack than it was to connect meetup registrations to our members. And that's really silly because we have the slack id stored on the account, so we should have a [nearly] 100% mapping that should take no thought and leave no room for guessing.

We could just pile on more names to the wordpress account. And that would be a lot better than not having any slack names to use. However, I think it's ridiculous that we have so many name fields. That's why I believe we should consolidate some of them. Different parts of our UI pull names from different fields, and I've found examples of variance for every possible pair of names; none of our name fields are just "redundant". People customize everything, and there is no reason for our members to have 5 aliases for one account.