hackgt / buzzer Goto Github PK

We need to adjust the server to be able to retrieve information from the InfoSource plugins. sendMessage should have a few variations. sendMessage will optionally take a source parameter that can be populated as follows:

• Provided a dictionary of user objects in the raw query.
• Provided a dictionary of InfoSource names and values that are also dictionaries that satisfy the filter function mentioned in #28. (Some kind of filter format should be provided by InfoSource)
  We need more information on what we can target. The server should provide a method for retrieving what InfoPlugins are available and what filtering groups they have and what information they can provide.
  If InfoSources are provided in source, run the InfoSource plugins filter with the parameters given in the request. Hold onto the information for later processing.

If the source parameter is not specified, the server will skip any info retrieval processing and default to BuildGT MVP behavior or directly routing a message to presumably broadcasting plugins.
Part of the #13 epic.

Email a bunch of people!

Might need to make a similar change mentioned in #10 .

Think about what kind of API we want to support, we need to:

1. Be able to select what kind of recipients we want to send notifications to (people who checked out hardware, vegeterians, people who applied, accepted, from one school, etc.). And just list users.
2. Be able to select where to send it to, i.e. via what medium (slack, SMS, push, email, etc.)
3. Specify what message to send.
4. Whatever else you think of...

no. 1 is probably the most difficult right now, we'll have to talk about it more, mostly just leave a stub for stuff you don't know. Be sure to be able to specify just a raw list of users, phone numbers, etc.

This should be an self-standing snippet because it'll probably live together with mapgt.

Rough outline would probably be to add an html bit with:

• a feed for showing history
• load live site history on init
• custom OneSignal hooks that will push notifications to the feed.

This should be its own type of 'plugin' that just connects to one of these services and provides you with group names that you can make use of in the API.

Once one is integrated it'll be easier to do the next, so the next issue will be whatever is not done here.

Once AppGT notification settings are configured, support remote notifications via OneSignal API.
https://documentation.onesignal.com/docs/react-native-sdk-setup
Some of the config steps should be skippable if we already support push notifications in AppGT.

All logic is processed in the app, so no participant filtering is necessary, just blast through OneSignal.

Currently, all group targetting from slackbot is manually assigned to Twilio config in the slackbot script 👎 . Redo API to accept --group config (and similar concepts) and apply group to all notifiers that would use it.

Basically support the ability to send SMS to a list of phone numbers.

This kind of plugin might require a change to the general plugin system because it is so different.
Mainly the need to report back which phone numbers succeeded or failed.

change webhook_url to something more indicative of the fact that we're using regular chat api
add some documentation on how to grab slack tokens when adding to new workspace

post-hackgt 6 work

Through something like this https://github.com/missive/emoji-mart, there should be a way to include emojis in your message as well.

Same format as the others!

Keep a record of all notifications that went out, their status, and who sent them.
This is good for both accountability (e.g. knowing who sent out a controversial message) but it's also good for users being able to see any notifications they missed (e.g. if they just logged into the live site).

In order to have the live site only show relevant notifications its probably a good idea to save where a notification went, so the live site can pull only notifications that were sent to it.

Plugin to notify people on slack, either DM or in a channel.

It'd be nice if event-notify-bot logic were brought into buzzer.

Our GraphiQL page is publicly accessible, we should authenticate that and any API routes that can send notifications.

Some API we do want to be publicly readable, e.g. the live site would want to pull which notifications it was sent, as described in #14 .

We need a new generic InfoSource plugin interface that provides targetting information for the server (aka either checkin or registration).

An InfoSource needs to provide two methods:

• options() should return filtering groups (e.g. grade, school) that can be used when requesting targets.
• filter(filterDict) will be given a dictionary of filtering groups with keys of filtergroups and values of arrays of accepted values (e.g. {grade: [9, 10, 11]}), and should return an array user objects that satisfy the filterGroups. This method should query the appropriate service for the actual information (checkin, registration). Once the data is received, process the information into a uniform format [i.e. plugin knows that a received UserEmail field is contains the email raw targetting information]

Once the interface is made, make a plugin for either plugin or registration (whichever is ready to serve the relevant info first).
Part of #13 epic.

Not sure how we would connect, but if there's some screens we have access to, let's figure out a way to quickly update all of them with buzzer (even if it's a page on live site that polls news)

The Slack API has changed!
Currently, we must create a new app for each event, and add the corresponding webhook for general purpose announcements. However, the API has moved to OAuth, and we must update the plugin to give the bot user level permissions (for individual messaging)
https://api.slack.com/apps/AHMKWNKNG/incoming-webhooks?

Provide some way of inserting configuration or secrets (probably with a file for each).
So a conf file could be:

port: 3000
production: true
plugins:
  slack:
    some_non_secret_conf: Hello

A secrets file is similar, but contains info we can't include in the public biodomes repo:

plugins:
  twitter:
    api_key: 3243546787543546789

Also be able to override some / all of these options through environment variables.

Approving messages is a good thing but causes slight downtime and annoyance - add a mechanism that allows scheduling of messages so that hubot can add messages that are pre-approved.

Currently the args argument has the any type.
With checkin and registration we actually generate types to match what GraphQL would provide us.

Plugins that use individual identifiers (e.g. email, sms) should specify so with a target() function and a needs attribute that specifies which identifier they want (e.g. email addresses, phone numbers) as a string. target will take an array of needed identifiers provided by the server and adjust plugin config accordingly. When sendMessage is called on the plugin, it should check if config has target info, and dispatch notification to all targets, otherwise have default behavior. Fail appropriately if target is called with invalid values.

Part of #13 epic.

Provided an array of raw user objects from #29, for each outgoing plugin, verify their .needs and provide the appropriate targetting information by reducing the user objects. Call their target functions with the targetting information.

The server should ideally behave the same way it if the outgoing plugins have no needs aka are broadcasting plugins.

This issue continues directly from #29. This is part of the #13 epic.

This is some UI for botgt that lets us send notifications through a slackbot. e.g.

/botgt notify slack Who lost some rain boots?

Code for this will entirely be on the hackgt/botgt repo.

This is to make adding a plugin and maintaining it simpler.
Each plugin should have its own snippet of GraphQL that defines its configuration options, e.g. slack:

type Config {
    channels: [String!]!
    at_channel: Boolean!
    at_here: Boolean!
}

The server should collect all of these config options and stich them together to make a final GraphQL schema. GraphQL provides utilities to do this, but you might have to get a bit hacky to rename Config to a unique name for that plugin and to collect them all in one struct.

The return status for each plugin should probably stay the same.

Make an easy web UI where people can buzz people through any medium they want.
If a medium is selected that contains a bunch of options, the UI should present those options to the user. (e.g. pick which slack channel, or what the subject of the email should be)

Having a nice mobile UI is important here, since this will be used a lot during the event.

We need a server to execute all the notifications using the different mediums we define.
This should:

1. Scan and find all plugins we want to use (SMS, Email, etc.)
2. Enfore some interface on all plugins to use.
3. Be able to execute a notifications request on all plugins.

When a (possibly internal) event is about to happen, post the appropriate confluence link on instructions and faq in #staff-faq

Plugin to show notifications on the live site.