Arbitary mentions

[samhh]

We support dynamically mapping channel names to IDs. Could we do the same for user and/or group mentions?:

mercury/src/slack/mention.rs

Line 6 in 4b0b337

// We could potentially reverse engineer user group IDs from friendly names

[samhh]

This'd make the project more immediately useful to consumers beyond Unsplash. (NB our hosted instance can't be used by anyone else as it's tied to our Slack token.)

[samhh]

Yep, we could: https://api.slack.com/methods/usergroups.list

It'd be mostly a copy/paste of how we handle channel names, meaning we'd inherit #5.

[samhh]

Example response:

{
    "ok": true,
    "usergroups": [
        {
            "id": "SAWPVDSUW",
            "name": "Web Team",
            "handle": "web-team"
        }
    ]
}

id is what we currently use in to_user_group_id. handle is what we'd want to expose in cc. We could also support pinging specific users but I don't think that's necessary.

So our call sites would need to change from -d cc=web to -d cc=web-team. Or we could change the handles I guess, the suffix is redundant.

[samhh]

Suggested plan:

1. Support arbitrary team mentions. Fall back to the current hardcoded ones.
2. Support arbitrary user mentions, trying team mentions first.
3. After a little time, separately remove the hardcoded team mentions. (v2? Deprecation?)

[samhh]

Related to this is how successive messages with the same user (e.g. "repo-foo") with different avatars, as we currently use them, may be clipped together with the first avatar. For our deployment use case this can be misleading.

I think to better impersonate Slack users we'd need to get each user's token as described here: https://stackoverflow.com/a/42663007

I suppose that relates to #5 insofar as it's a reason for some persistence, but then Mercury balloons in complexity.