Point bots like Sparkles can sometimes result in a popularity contest, and that's no fun. It's also possible for people to join a team that has used Sparkles for a while and feel like they'll never catch up. Sparkles should be lighthearted and fun, and for some teams, that's going to mean not keeping track of point totals. We should allow people to disable the leaderboard features for Sparkles, which would change a few key functionalities:

• In Slack, /sparkle @user [reason] would stop printing out @user's total number of sparkles
• In Slack, /sparkle stats without a username would no longer show the top 10 leaderboard, and would instead default to showing the caller their own sparkles (e.g. me running /sparkle stats would just be equivalent to /sparkle stats @davidcelis)
• On the web, the Leaderboard index page would become a simple directory and not show point totals

I think the easiest way to do this may be to have a command like /sparkle settings and, maybe eventually, a simple settings page on the web-frontend.

One open question I want to consider before implementing anything is whether this should be a setting we give to individual users to tailor their own experience, or if this should be a setting we give to workspace admins to disable or enable the leaderboard for the whole team. It would probably also be possible to do both, allowing users to change their own experience in a way that removes the potential for competition, or allow the workspace owners to disable it whole-sale.

People should be able to give someone a quick sparkle by leaving an emoji reaction on one of their messages. If someone reacts to a message with the ❇️ emoji, we'll get a reaction_added event with this payload:

{
  "type": "reaction_added",
  "user": "// Sparkler ID",
  "reaction": "sparkle",
  "item_user": "// Sparklee ID",
  "item": {
    "type": "message",
    "channel": "// Channel ID",
    "ts": "// Message ID"
  },
  "event_ts": "1360782804.083113"
}

We'll need to be able to keep track of whether or not a Sparkle was the result of a reaction. We should add two new attribute to the Sparkle model:

# Stores the `ts` of the message that someone reacted to, creating this sparkle
add_column :sparkles, :reaction_ts, :string

# Stores the `ts` of the message Sparklebot posted to confirm the sparkle
add_column :sparkles, :confirmation_ts, :string

class Sparkle
  def reaction?
    reaction_ts.present?
  end
end

Flow

We get one ❇️ emoji reaction on a message:

1. We receive a reaction_added event
2. We call conversations.history?channel={item.channel}&latest={item.ts}&limit=1
3. We check for the presence of a thread_ts in the response (thread_ts = response.body["messages"].first["thread_ts"] || item.ts)
4. Pass item.ts to chat.getPermalink so that our Sparkle's permalink will be the message that got a reaction
5. Create a Sparkle with reaction_ts set to item.ts
6. Use the thread_ts we kept a reference to so that we can reply with confirmation from within a new or existing thread, keeping another reference to the ts of the resulting reply. Example:

Aw yeah! <@slack_sparklee_id> got a sparkle for their <message|permalink> from <@slack_sparkler_id>. They've got N sparkles now :sparkles:

7. Update the Sparkle we created, setting reaction_confirmation_ts to the ts of our confirmation response

For each follow-up ❇️ emoji reaction:

1. We receive a reaction_added event
2. Check Sparkle.where(slack_team_id:, slack_channel_id:, slack_sparkler_id:, reaction_ts:)
3. Simply duplicate an existing sparkle and set its slack_sparkler_id accordingly
4. Use our confirmation_ts with the chat.update method so that we can update our response:

Aw yeah! <@slack_sparklee_id> got 2 sparkles for their <message|permalink> from <@slack_sparkler_id> and <@slack_sparkler_id>. They've got N sparkles now :sparkles:

Is your feature request related to a problem? Please describe.

To avoid too much message noise, it'd be nice to optionally attach the confirmation of sparkles to the original message instead of creating a new message from the bot.

Describe the solution you'd like

See https://api.slack.com/messaging/composing/layouts#building-attachments

But basically, adding an attachment to any message that is triggering sparkles.

Describe alternatives you've considered

The existing method of providing an additional message can be noisy, but is a fine alternative, so maybe this is optional behavior?

Additional context

n/a

Right now, we display sparkles' reasons as the original, raw text. This means any emoji or other formatting are displayed as markdown instead of translated into HTML and rendered with the formatting intact.

In the interest of not writing our own Slack markdown parser, this gem might be our best bet: https://github.com/rutan/slack_markdown

To make this work properly and render custom emoji, we'll need to supply the original_emoji_set option to the Markdown formatter. We already require the emoji:read scope when installing Sparkles into a workspace, so we should be able to use the emoji.list API endpoint and provide the result as the original_emoji_set.

However, the slack_markdown gem doesn't take emoji aliases into account:

https://github.com/rutan/slack_markdown/blob/master/lib/slack_markdown/filters/emoji_filter.rb#L28-L30

As an example, every Slack workspace has this default emoji definition:

{
  "shipit": "alias:squirrel"
}

We can use the fork present at davidcelis/slack_markdown, but I've also opened a pull request at rutan/slack_markdown#5; if the author accepts the change and cuts a new release, we can go back to using the stock gem.

If we're on the first page, we could make our leaderboard live-update using Hotwire. No need to do this any time soon, but maybe there are some people out there who love Sparkles so much that they want to have it up on a screen permanently and not have to refresh the page. Mostly it would just be an excuse to learn Hotwire 😅

Right now, Sparklebot joins every public (non-shared) channel as they're created. A frustrating problem with the Slack API means that we aren't notified when a channel becomes private, so this was to work around a potential issue: some public channel where people have been given sparkles becomes private, we lose access to it, and people try to view sparkles that were given in that channel but we can no longer see it.

However, we never actually fetch information about channels outside of events and syncing, so maybe this isn't really a problem that would cause breakage with the app.

I think a better and safer workaround that wouldn't require joining channels would be to rely on our daily sync. When the SyncSlackTeamWorker runs, detect channels that we have stored locally but which no longer appear in the results of conversations.list, updating them to be marked as private. We won't get updates to those channels unless Sparklebot is invited, but we'll at least hide the channel name appropriately and just refer to it as "a secret place" where stats are visible.

We installed Sparkles and Sparklebot immediately added itself to all public channels.

This is not desirable for our organization as there are lots of places where we don't want/need to use the bot.

Ideally, adding itself to all public channels would be opt-in functionality instead of the default.

Some of the test suite, especially tests involving building BlockKit views (e.g. tests for StatsWorker and the settings slash command) are very verbose and could maybe be pared down to be cleaner. These two classes build up big BlockKit views on their own and we may benefit from presenter objects that are designed to translate things into BlockKit (Sparkle records should definitely have a cleaner way to translate into BlockKit).

Additionally, although StatsWorker is now tested, we could still use some integration tests for the leaderboard on the Rails frontend.

Description

Technically, the sparklee and sparkler associations for our Sparkle model use only the users.slack_id column, which means they are prone to break if we encounter users in different teams that share an ID. Ideally we could define these associations to query on both users.slack_team_id and users.slack_id, but Rails does not provide a fully-supported way to define an association with multiple foreign keys.

We should continue to reference Teams, Users, and Channels by their Slack IDs, but because Sparkle is an internal model, the easiest thing to do would be to change its references to use our internal identifiers, which is just Rails' default auto-incrementing id column. We should add sparklee_id, sparkler_id, and channel_id to the sparkles table, populate it based on the contents of slack_team_id, slack_sparklee_id, slack_sparkler_id, and slack_channel_id and then drop those columns.

Steps to Reproduce

To reproduce the behavior:

1. Sync a user from team T123 that has the id U123
2. Sync a user from team T456 that has the id U123
3. Load the sparkles association for the second user
4. The results will include sparkles for both users

Expected behavior

The sparkles association for the second user should only contain that user's sparkles.

We get an app_uninstalled event when Sparkles is removed from a workspace. We should handle this by clearing out the team's token in our database and setting a new uninstalled flag on the team. Uninstalled teams should be excluded from the DailySyncWorker.

Is your feature request related to a problem? Please describe.

N/A

Describe the solution you'd like

Would be great if you could have a channel where all Sparkle information was aggregated to so that others could see the sparkles that were sent as they were coming in, instead of needing to be in the direct channel the Sparkle was given.

Describe alternatives you've considered

N/A

Additional context

Depending on if you have plans for making Sparkles potentially private and public I could see this not being a great solution for private sparkles where maybe the message is intended more directly for the receiver of the sparkle.

Description

We allow team admins to set a feed channel that we cross-post all public Sparkles in. Unfortunately, there seems to be a limitation with the channels_select BlockKit element: there's no null option. Once a channel is selected, there's no way to unset it.

Steps to Reproduce

To reproduce the behavior:

1. Run /sparkle settings as an admin
2. Select a feed channel
3. Press the "Submit" button
4. Run /sparkle settings again
5. There is no way to unselect a channel or clear the field

Expected behavior

There is either a way to clear the Slack Feed Channel field or to submit some kind of null value.

Is your feature request related to a problem? Please describe.

N/A

Describe the solution you'd like

Would be nice to have a list of sparkles that a user has given vs. received as kinda a way to gauge the engagement of users within the app. Not really a point war but would maybe help in showing participation.

Describe alternatives you've considered

Possibly make this a command just for the current individual to see a list of who they have sent a sparkle to?

Additional context

N/A

Description

We allow team admins to set a feed channel that all sparkles are cross-posted into. However, when that channel is archived or deleted, we will continue to try to post all sparkles into it and receive an error. We should run a quick check in the channel_archived and channel_deleted events to see if that channel is the team's Slack Feed Channel; if so, we should just un-set it.

Steps to Reproduce

To reproduce the behavior:

1. Run /sparkle settings
2. Choose a channel to act as the Sparkle Feed Channel
3. Archive or delete the channel
4. Run /sparkle @user to try giving a sparkle
5. Sparklebot will error

Expected behavior

We un-set the slack_feed_channel_id field for the team and /sparkle @user succeeds

If multiple people helped me out with something, I'd like to be able to give them all a sparkle at once!

Passing multiple User IDs

Users should be able to do something like /sparkle @user1 @user2 @user3 for helping me out and have Sparklebot create an identical sparkle for everyone specified.

Passing a user group

The /sparkle command should also support user groups; if provided a user group, we'll get a string like this on the backend: /sparkle <!subteam^SAZ94GDB8> for helping me out. Calling this should have the same result as calling /sparkle @user1 @user2 @etc for helping me out

To make this work, we'll need to add the usergroups:read bot scope so that we can figure out which users belong to the group; anybody who wants to use this feature will have to reinstall Sparkles 🙃

Providing a proper error response for trying to /sparkle @here|@channel|@everyone

If we get <!here>, <!channel> or <!everyone> as the argument to /sparkle, we return the generic "I didn't understand your command" text along with showing the help command text. We should catch these and provide a more reasonable error like "Sorry, but using @here/@channel/@everyone is pretty disruptive, and I want to make sure that Sparkles stays fun for everyone."