instedd / aida Goto Github PK

Before a bot is created or updated, validate the manifest against a JSON schema

Create a basic Facebook channel capable of echo back every message received.

Let's hardcode the parameters for the Facebook channel for now ("page_id", "verify_token" and "access_token") and use those parameters to verify the callback received from Facebook Messenger API and reply with a message to the same user with the same content.

We can asume for now that if the only word in a message is a perfect match with the name of a language, we have 100% confidence that the user wants to change the language.

If not, for now we can just return 0 and let the other skills take over.

Manifests must be parsed to create a Bot structure instance when new bots are pushed or when the system starts. Create a BotParser module capable of parse the bot manifest and return a Bot structure with skills and channels.

Add "constraint" and "constraint_message" to the json schema for survey steps.

If the step has a "constraint" expression, evaluate it over the given answer and reply with "constraint_message" if the evaluation is "false".

Also, use the "constraint_message" for invalid answers.

Each skill can specify an xpath expression that determines if the skill applies or not for a user at the moment of receiving a message or a skill is activated.

See #10

After the system starts, the bot supervisor must create one BotServer (GenServer) for each bot.

Whenever a bot is updated, a message is sent to the corresponding server so it can reload the configuration.

• Parse value in manifest
• Trigger clarification for all Skills that fall within the "confidence distance" from the confidence upper bound.
• If only one skill responded with a confidence higher than 0%, then handle message with that Skill only if it's confidence = Confidence distance threshold

Instead of splitting, converting and removing unwanted characters on every skill, add a function to the Message module that returns a list with the words present in the content.

Something like this:

Regex.scan(~r/\w+/u, str) |> Enum.map(&hd/1)

Then replace existing calls to String.split and similar on the skills by calling to this new function.

http://support.kobotoolbox.org/customer/portal/articles/1682856-adding-cascading-select-questions

Message strings can contain interpolation of variables like this: "Hello ${name}!"

Variable values must be extracted from the session taking into account the last portion of the variable name after splitting by "/".

1- Skills will be renamed by users in the UI.
2- Stats of Skill usage need to be persistent across renames.
3- Therefore we need an ID for a skill in the manifest.
4- We might also want to have the name of the skill in the manifest for logging purposes.
5- It might be good to not be strict about the type of the IDs to allow for manual creation or other tools to emit manifests. Maybe just a unique (not repeated in the manifest) string?

Currently, only text is supported as content. Let's add support for pictures.

• Change Message.content so it's either a TextContent or a ImageContent. The ImageContent will contain the URL received by the channel
• Fix all the skills expecting text from the content (most of the time, skills will return a confidence = 0 when the content is an image)
• Support image questions in the survey. When the question is executed, download and store the image sent by the user in a new images table. Store the URL to retrieve the image in the session value.

When the steps has a "relevant" attribute, evaluate the condition and skip if the result is "false"

message received and message sent are returned as null instead of 0
active users does return 0 when the bot has just been published.

Store bots with a simple db schema with the fields:

• id
• guid
• manifest (JSON)

For audit purposes, store all the incoming and outgoing messages in a new table (message_logs) with the following fields:

• id (autonumeric)
• bot_id
• session_id
• direction (incoming/outgoing)
• content
• timestamp

Sessions must be scoped by bot. Let's include the bot_id inside the session and the sessions table.

Add a simple API to get the installed version (/api/version). Use the same mechanism we use in Surveda to obtain the version: https://github.com/instedd/ask/blob/master/config/config.exs#L49-L54

In the management UI, show the current version in the footer

Add the "channels" section into the JSON schema definition. Each channel will be an object with a "type" identifier. For now, only "facebook" channels are allowed with the following structure:

{
  "type": "facebook",
  "page_id": "152279268715860",
  "verify_token": "eSAM6WbxaLSc4GNBGnEfA4mgH9rvXQjdhNetYnMt",
  "access_token": "2XUFvv8JJbB9sQW3gWneKkY7kYpV4u7whNkcwLbd"
}

We decided to store bots configuration in a ETS table. Let's define two modules:

• Bot: holds the entire bot configuration and serves as the entry point to reply messages
• BotConfig: manages the active bots in memory. It will keep the ETS table up to date and lookup for bots by id. It provides functions like start/stop/reload to respond to configuration changes.

Support in manifest something like the sketch below. Delay is in minutes. Messages get triggered after the user has not sent any message for that time.

"type": "scheduled_messages",
"id": "inactivity_check",
"name": "Inactivity Check",

Messages:
schedule_type: since_last_message
Delay: 2880
Message:
En: “Hey, I didn’t hear from you for the last 2 days, is there anything I can help with?”

The initial version must be able to CRUD bots.

Let's use:

• webpack
• react
• react-md

If channel is created in the UI and the user goes to FB to setup the tokens before "publishing", the challenge sent to the Bot Engine from FB will not match any existing channel nor verification token.

Maybe just a note with a "you have to publish the bot before entering these data in FB".

When a new respondent first contacts the bot, query the user profile and store "first_name", "last_name" and "gender".

https://developers.facebook.com/docs/messenger-platform/identity/user-profile/

Make language_detector a skill without special treatments (specially on bot.ex).
Every skill should have a function where it defines what pre-conditions needs to be 'activated'.
Every skill that is not a language_detector should ask at least for a language to be defined before allowing its use. This way, the only active skill when there is no language selected will be the language_detector.
If there is only one language available, maybe the bot should be the one that sets it on the session.

See 1.1 to 1.5 in the interactions document:
https://docs.google.com/document/d/1630iHOy8D5CPK48mW2Y4HmMja6xFd88sRAlNqoZUN7I/edit

• Keep a table with day, received messages, sent messages
• For each message sent, increment the sent message for the current day.
• For each message received, increment the received message for the current day.
• Expose totals of both values via API for "today", "this_week" and "this_month"

• Keep a table with respondent_id, skill_id, last_usage_datetime
• For each skill that handles a response, update the corresponding row with the current datetime.
• Expose count of unique respondes per skill via API for "today", "this_week" and "this_month". Return counts for all skills for a period in a single request.

When a new session is created, accept an optional data parameter to specify the values. Also, add a put_data message that receives the session and the data to merge into

Example definition for this skill:

{
  "type": "language_detector",
  "explanation": "To chat in english say 'english'. Para hablar en español escribe 'español'",
  "languages": {
    "en": ["english"],
    "es": ["español"]
  }
}

Connect the existing basic Facebook channel with the Bot. For this, lookup the channel configuration by page_id calling Facebook.find_channel_for_page_id. Then obtain the bot by calling BotManager.find and execute the message through the Bot instance.

We need to support:

• and, or, not
• <, >, <=, >=, =
• function calls: foo(...)
• variables: ${foo}
• . (current value)
• literals: integers, strings, booleans

Confidence = [number of keywords that matched]/[word count in message]

Now if the chatbot fails Facebook will stop working.
The user should receive an error message.
We should log the error in Sentry.

• Keep a table with respondent_id and last_incoming_message_datetime
• For each incoming message from a respondent, update the last_..._datetime for that respondent
• Expose count of unique respondents for Today, This Week (Sun to Sat?), This Month.
• All periods start and end in UTC
• via an endpoint with something like "/api/stats/unique_respondents?period=[today|this_week|this month]

The content_type will be either text or image

Allow definitions of variables in the manifest with overrides depending on the session variables. For example:

{
  "variables": [
    {
      "name": "food_options",
      "values": {
        "en": "barbecue and pasta",
        "es": "parrilla y pasta"
      },
      "overrides": [
        {
          "relevant": "${age} >= 18",
          "values": {
            "en": "barbecue and pasta",
            "es": "parrilla y pasta"
          }
        }
      ]
    }
  ]
}

Add an optional flag "temporary" to the bots. These bots will be automatically deleted after some time of inactivity.

• Accept a "temp" parameter in the query string while publishing a new bot
• Add a "temp" column to the bots table and set it to "true" if a temp=true was passed while creating

Add the following endpoints to the SessionController:

Session index

GET /api/bots/<bot_id>/sessions

This endpoint should return the existing sessions for the bot:

{
  "data": [
    {"id": "", "first_message": "2017-01-01T01:23:45Z", "last_message": "2017-01-01T01:23:45Z"}
  ]
}

Session log

GET /api/bots/<bot_id>/sessions/<session_id>/log

{
  "data": [
    {"timestamp": "", "direction": "incoming | outgoing", "content": ""}
  ]
}