praekeltfoundation/vumi-jssandbox-toolkit

Vumi JavaScript Sandbox toolkit.

vumi-jssandbox-toolkit's Issues

Allow user applications a chance to decide how to handle errors.

Currently InteractionMachine.err handles errors all by itself. We should allow user applications a chance to do the high-level processing of the error themselves (falling back to the current behaviour if the application error handler throws an exception or indicates that it'd like default error processing to continue).

Add ability to provide hints for the transport.

Some transports sometimes need special hints on how to handle messages.

A simple example is Rich Media Messages in WeChat.

But other things are:

1. Menu structure for apps running on Mxit
2. end-of-input markers for IVR, Enter your ID number and press # for example.

Add multipart support to HttpApi and DummyHttpResource

praekeltfoundation/vumi#735 adds this to the real resource, we should support it in the toolkit too.

Setting a user_store in tester config causes state errors

Sandbox version: vumigo_v01

See https://gist.github.com/imsickofmaps/9111647 for example of error log

Add default delay to fixture HTTP calls.

Currently the test framework immediately returns results for http calls, that's not how things will happen in production.

Having a configurable delay in the fixtures would help, a default of 100ms would probably be OK?
It would help indicate where too many http calls are being made for production (even though they're snappy in the tests).

Add a check on the length of replies and outbound SMSes.

The check would be on a configurable maximum message length (set in the config for the JS app) and would log a warning if the content is too long.

The test harness already checks this but a check in production would help pick up odd errors (e.g. where the aggregator ends the USSD session because the reply is too long) more quickly. Sometimes production replies are longer than test replies (e.g. because dynamic content is included in the replies).

Remove unnecessary namespaces in event names

Users emit events like user:new, user:load and States emit events like state:enter. This means attaching listeners looks something like this:

user.on('user:new', function() {
    ...
})

This feels a little redundant, since we already know that the object emitting the event is a user. Event names like session:new make sense, I think, since they happen on the interaction machine.

Add contacts.search handler in DummyAPI

This is so that tests can run with the proposed 'contacts.search' API in praekeltfoundation/vumi-go#809.

Add a kv helper

The only helper missing (other than GroupStore). Would be great to have this out when we do a final release for v02.

AppTester setup task methods for the sandbox config

This will be helpful for things like setting language data.

Throw a better exception when no choices are passed into a choice state.

Currently we try to access .forEach on undefined and throw a rather obscure error.

Twitter transport needs to support auto following

We need a way of toggling auto-following so that we don't have to manually follow people in order to send DMs to them or get DMs from them.

Document i18n features & IM.set_user_lang()

Currently getting this to work involves reading a lot of source code, figuring out what the tool chain looks like and how the python PO utilities & scripts work.

Split out param part of url encoding and decoding utils

We currently have utils that look something like:

function url_encode(url, params) {
    ...
}

function url_decode(url) {
    ...
}

Url encoding params (without a url) is needed often enough that it probably makes sense to split these out into their own utilities.

Add documented examples for various sandbox features

This should be in the form of mini-applications that exercise a feature. Each should appear in the documentation and be tested. We need:

• general package and documentation structure to be set up
• an example of a simple app
• an example of a slightly more complex app
• an example of using the HttpApi and JsonApi helpers
• an example of using a language state
• an example using contacts

Once those are done, we can add examples as needed.

Add utility class for making external HTTP calls.

Especially ones that return JSON.

Allow test checker `response` attribute to be a plain string

Currently all response values are assumed to be strings that represent regex patterns. We should instead allow responses to be either regexes or strings and do a pattern match for regexes and an exact match for strings.

E.g.

// regular expression match
tester.check_state({
  response: /^foo.*$/
})

// exact string match
tester.check_state({
  response: "foo"
})

Allow ChoiceState to take in an array of objects as choices

Currently, we do this:

return new ChoiceState(name, {
    question: "Coffee or tea?",
    choices: [
        new Choice('coffee', "Coffee"),
        new Choice('tea', 'Tea')
    ],
    next: function(choice) {
        return {
            coffee: 'states:coffee',
            tea: 'states:tea',
        }[choice.value];
    }
});

It would be nice if we could do this too:

return new ChoiceState(name, {
    question: "Coffee or tea?",
    choices: [{
        value: 'coffee',
        label "Coffee"
    }, {
        value: 'tea',
        label "Tea"
    })]
    next: function(choice) {
        return {
            coffee: 'states:coffee',
            tea: 'states:tea',
        }[choice.value];
    }
});

Fire an IMEvent from on_inbound_event.

Create a helper method for sending messages out over different endpoints.

A lot of JS apps that use sms sending as part of a USSD session do so using the outbound.send_to_tag method, it would be nice if there was a helper method available for that which uses/exposes the new endpoint based routing.

Simple how-to for translation

Translation is currently a pretty obscure matter.

Add helpers for redis-backed metrics (e.g. counts) and generic state tracking metrics.

These are generically useful and are already being copied around a lot.

Align BookletState and PaginatedChoiceState navigation options

The BookletState and PaginatedChoiceState provide similar navigation options but for historical reasons there constructor arguments are completely different. We should standardize on one set of navigation arguments before doing an official release of version 2.

Log twitter api failures in twitter transport

At the moment, we publish nacks, but don't log anything.

Expose `verify_options` and `ssl_method` in HTTP API.

The HTTPClientResource allows for those options but there the HTTP API doesn't expose them.

contacts.search returns keys, DummyApi implementation returns contact objects.

Write a tutorial for how to use the JS sandbox toolkit

This was started in #7 but still needs quite a lot of work.

Add errback path to Promise implementation.

Add support for helper_metadata to outbound resource.

Once #217 lands we will have support for helper_metadata on replies, but not for setting it on non-reply outbound sends (it would be cool to be able to support triggering a voice call from a USSD menu the way we support triggering an SMS).

Lowercase app name when using it as metric store

The default metric store name is the app name, and the store name needs to be lowercase.

Please create a new release.

It'd be convenient to have the new BookletState on the NPM registry.

Document the object that a next() function can return.

I happen to guessed what it's expecting from the go-di project.

{
    name: 'name of state',
    creator_opts: {
        foo: 'bar'
    }
}

Use a third-party promises implementation.

Options include:

• q (https://github.com/kriskowal/q)
• jQuery's implementation

This obseletes #3.

Get mocha to display diffs for fixture mismatches

At the moment, it is difficult to tell why a fixture doesn't match a real request, especially for cases where the bodies are non-trivial. It would be great if we could make use of mocha's showDiff error flag to show these diffs in a way that it is easy to figure out the reason for mismatches.

Dummy message store resources

We somehow don't have this yet.

LanguageChoice state broken in v2

Complains "has no method set_user_lang". Current work around is: https://github.com/praekelt/go-di/blob/develop/src/app.js#L256-L270

HttpApi doesn't encode its urls

Fix bug that causes on_enter to be fired twice for non-end states.

Currently on_enter handlers are called twice for states that aren't end states. Once when the state is first transitioned to for displaying and a second time when the state is loaded in order to process user input.

DummyAPI fixture handling has no tests

Re-write state machine stuff to use promises.

Documenting for dummy api

Support explicit delivery class for sending

At the moment, the documentation suggests we support the delivery class being given explicitly, but we actually dont.

Allow triggering metrics on delegator states.

Currently one can't trigger metrics helper metrics on delegator states because those don't have events fired. This is a thorny problem and I'm not entirely sure what the solution is.

Return to user's last seen page on PaginatedState after timeout

It would be ideal if this would also work if a special timeout state is interjected like in go-refugeerights state_timed_out.

JsonApi doesn't break on no body fixtures in tests

But it does in production as JSON.parse("") throws errors.

Use the new view.enter() in existing views

Add ability to know transport the message came from into the sandbox

This would be really useful for applications that are running the same codebase on two conversations (like SMS and USSD). Sometimes the responses you give to the user or logging you want to do is defined by the transport.

Add reusuable validation functions

Including:

• MSISDN

Add utility class for message sending via other messaging channels.

This should use Go's send_to_tag method on the outbound resource.

Example and documentation of low-level API access

We need an example of how to write ones own replacement for InteractionMachine (useful for applications that aren't at all like state machines).