Documentation Note: These sections need better titles.
After Gem install: Adding a new Channel to the Whenbot Gem
- New Channel is installed (via gem)
i. Channel must register with main Whenbot gem
* Can be done with aconfigoption orWhenbot.defineblock
* Or, possibly, via the#include module->#included?method/call technique - Gem
i. Adds registered gem to "array / list of Channels / Triggers / Publishers"
* Should this be in memory? Redis?
ii. Does it do anything else here? (retrieve options? ...anything?)
User wants to create a new task
-
Gem needs to list the Trigger Channels to show the User
-
Gem asks each Channel (that it knows about) for its Triggers (names, images / descriptions?)
-
Channel tells Gem whether it has any Triggers
-
Gem UI lists all Trigger Channels on a single page (erb) for the User
-
User clicks on the Trigger Channel they want to use
-
Gem UI receives selected Trigger Channel via params, and calls to model (via Gem) to check if this Channel has authentication credentials in the database
-
If the Channel doesn't have any saved authentication credentials
i. Gem UI displays the OAuth / basic_http_auth credentials box
* Note that we should probably recommend / enforce that the user uses the free SSL provided by Heroku at https://yourapp.herokuapp.com
ii. User enters their credentials
iii. Service attempts to validate the credentials authenticating with the Provider * On success: store (encrypted) credentials / token, display success message * On failure: re-request authentication credentials from the user and try again -
Gem requests the selected Trigger Channel's list of Triggers
-
Trigger Channel returns the list of Triggers that the user can choose from
-
Gem UI displays the list of Triggers to the user
-
User selects a Trigger
-
Gem UI receives the selected Trigger via params * Passes data to next step (via hidden form field?) if needed. Depends on how the UI / UX is architected.
-
Gem UI (via Gem) requests the Parameters for the Trigger from the Trigger itself
-
Trigger returns a list of Parameters for the specified Trigger (as a hash of hashes, or some other object)
-
Gem UI displays the fields for the Trigger's parameters to the user
-
User enters the appropriate information and presses "Next" (or something similar)
The Trigger setup is done at this point. The User is shown the Action setup next (seamlessly)
Action Setup Flow
-
Gem ask all Channels (that it knows about) for its Actions, if it has any (names, descriptions / images?)
- Or, they could have been pre-registered via a config option set by the Action's author (Actions may also be individually authored, if we make it easy enough to do so ;)
- Similar to the methodology found in step 2
-
Each Channel tells the Gem whether it has any available Actions 19.Gem UI list all Action Channels on a single page (erb) for the user
-
User chooses an Action Channel and clicks on it
-
Gem UI, using the Action Channel given in the click (via params), checks (via Gem) to see if there are authentication credentials (OAuth / basic HTTP auth, depending on the service) in the database. i. If not, the Gem UI displays the "Authentication Credentials" box ii. User enters their information and submits iii. Credentials are checked via the provider, to ensure that we can log in. * On success: securely store credentials, display success message * On failure: re-request authentication credentials from the user
-
Gem requests the selected Action Channel's list of Actions
-
Action Channel returns its list of Actions for the User to choose from
-
Gem UI displays the list of Actions to the User
-
User chooses an Action from the list
-
Gem UI (via Gem) asks the Action for the list of Parameters from the Action itself
-
Action returns a list of Parameters
-
Gem UI generates and displays the entry fields for the given Parameters
-
User fills in the fields and submits the form