Glific v0.3.1 API Reference

Modules

Glific keeps the contexts that define your domain and business logic.

Glific Cache management

The cache API behaviour

Glific interface for all provider communication

The Message Communication Context, which encapsulates and manages tags and the related join tables.

The Contacts context.

The minimal wrapper for the base Contact structure

The minimal wrapper for the base Contact structure

Current location of a contact

The main Glific abstraction that exposes the data in a stuctured manner as a set of conversations. For now each contact is associated with one and only one conversation. We will keep the API simple for now, but it is likely to become more complex and will require a fair number of iterations to get right

The Glific Abstraction to represent the conversation with a user. This unifies a vast majority of the glific data types including: message, contact, and tag

Module to communicate with DialogFlow v2. This module was taken directly from: https://github.com/resuelve/flowex/

Helper to get information about the agent

The main intents module which stiches it all together

Helper to help manage intents

The Enum provides a location for all enum related macros. All the constants that Ecto/Elixir used are exposed here as macros, so other files can invoke them as simple functions

The Enums constant are where all enum values across our entire application should be defined. This is the source of truth for all enums

Centralizing all the code we need to handle flags across Glific. For now, we'll also put operational code on flags here, as we figure out the right structure

The Flows context.

The Action object which encapsulates one action in a given node.

The Case object which encapsulates one category in a given node.

The Category object which encapsulates one category in a given node.

Since many of the functions, also do a few actions like send a message etc centralizing it here

Since many of the functions set/update fields in contact and related tables, lets centralize all the code here for now

Since many of the functions set/update fields in contact and related tables, lets centralize all the code here for now

The Exit object which encapsulates one exit in a given node.

The flow object which encapsulates the complete flow as emitted by by https://github.com/nyaruka/floweditor

When we are running a flow, we are running it in the context of a contact and/or a conversation (or other Glific data types). Let encapsulate this in a module and isolate the flow from the other aspects of Glific

The flow count object

The flow revision object which encapsulates the complete flow as emitted by by https://github.com/nyaruka/floweditor

The Localization object which stores all the localizations for all languages for a flow

substitute the contact fileds and result sets in the messages

The Node object which encapsulates one node in a given flow

A central place to define and execute all periodic flows. The current periodic flows in priority order are

The Router object which encapsulates the router in a given node.

The Case object which encapsulates one category in a given node.

The Wait object which encapsulates the wait for a router

Lets wrap all webhook functionality here as we try and get a better handle on the breadth and depth of webhooks

The Groups context.

A pipe for managing the contact groups

Simple container to hold all the contact groups we associate with one contact

The minimal wrapper for the base Group structure

Simple container to hold all the group contacts we associate with one group

Simple container to hold all the group users we associate with one group

A pipe for managing the user groups

Simple container to hold all the user groups we associate with one user

Processes the tasks that need to be handled on a minute schedule

The Messages context.

Message media are mapped with a message

Create maps for substitutions in message body These maps of available variables will be required by frontend team

The Partners context. This is the gateway for the application to access/update all the organization and Provider information.

Organizations are the group of users who will access the system

The Glific abstraction to represent the organization settings of out of office

The Glific abstraction to represent the out of office enabled day schema

Provider are the third party Business Service providers who will give a access of WhatsApp API

Process all messages of type consumer and run them thru the various in-built taggers. At a later stage, we will also do translation and dialogflow queries as an offshoot from this GenStage

Process all messages of type consumer and run them thru the various in-built taggers. At a later stage, we will also do translation and dialogflow queries as an offshoot from this GenStage

Helper functions for all processing modules. Might promote this up at a later stage

This producer is linked to the message receiving end and gets messages from the external world in the message structure

A worker to handle send message processes

Http API client to intract with Gupshup

Messgae API layer between application and Gupshup

A worker to handle send message processes

The message behaviour which all the providers needs to implement for communication

This file will be handling production database migrations. This is a standard elixir/ecto release file. Copied from: https://hexdocs.pm/phoenix/releases.html

A repository that maps to an underlying data store, controlled by the Postgres adapter.

Glific interface to Postgres's full text search

The Searches context.

The minimal wrapper for the base Saved Search structure

First experiments with PhilColumns. Hopefully it will work

Our first attempt at a deployment seeder script. Wish us luck

Script for populating the database. We can call this from tests and/or /priv/repo

Script for populating the database at scale

The Settings context. This includes language for now.

Ecto schema and minimal interface for the languages table

The API for a generic tagging system on messages that coordinate with different types of taggers. The proposed taggers are: Numeric Keyword Emojis

This module is user driven via keywords associated with tags. It reads in all the keywords associated with each tag in the DB and matches it to the input text.

The numeric tagger which takes the message body and checks if the body is mainly a number in different ways including: Ordinal Numbers (0..19) Cardinal Number (Zero - Ten) Emojis (0..9) Ordinal Hindi Numbers Cardinal Hindi Numbers

This module will be responsible for all the contact and message status tagging. Like new contacttagg and unread

Helper functions for tagging incoming messages

The Tags Context, which encapsulates and manages tags and the related join tables.

A pipe for managing the contact tags

Simple container to hold all the contact tags we associate with one contact

A file for managing the join table message tags

Simple container to hold all the message tags we associate with one message

The minimal wrapper for the base Tag structure

A pipe for managing the template tags

Simple container to hold all the template tags we associate with one template

The Templates context.

The Users context.

The entrypoint for defining your web interface, such as controllers, views, channels and so on.

The Pow User Registration Controller

The Pow User Session Controller

PoW error handler for API Authentication

Setting the absinthe context, so we can store the current user there

This is a basic plug that ensure the organization is loaded.

This is a struct that holds the configuration for GlificWeb.EnsurePlug.

Conveniences for translating and building error messages.

The Flow Editor Controller

A module providing Internationalization with a gettext-based API.

This file and the below files have been "borrowed and modified" from triplex: https://github.com/ateliware/triplex The original copyright and license - MIT belong to the authors and contributors of Triplex

Dedicated controller to handle different types of inbound message form Gupshup

Dedicated controller to handle all the message status requests like read, delivered etc..

Dedicated controller to handle different types of user events requests like optin an optout form

A Gupshup shunt which will redirect all the incoming requests to the gupshup router based on there event type.

A Gupshup router which will redirect all the gupsup incoming request to there controller actions.

Module with named helpers generated from GlificWeb.Providers.Gupshup.Router.

Contact Resolver which sits between the GraphQL schema and Glific Contact Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Tag Resolver which sits between the GraphQL schema and Glific Conversation Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Flow Resolver which sits between the GraphQL schema and Glific Flow Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Group Resolver which sits between the GraphQL schema and Glific Group Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Helper funcations for GQL resolvers

Message Resolver which sits between the GraphQL schema and Glific Message Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Partners Resolver which sits between the GraphQL schema and Glific Partners Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Searches Resolver which sits between the GraphQL schema and Glific saved_search Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Settings Resolver which sits between the GraphQL schema and Glific Settings Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Tag Resolver which sits between the GraphQL schema and Glific Tag Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

Templates Resolver which sits between the GraphQL schema and Glific Templates Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

User Resolver which sits between the GraphQL schema and Glific User Context API. This layer basically stiches together one or more calls to resolve the incoming queries.

a default gateway for all the external requests

Module with named helpers generated from GlificWeb.Router.

This is the container for the top level Absinthe GraphQL schema which encapsulates the entire Glific Public API. This file is primarily a container and pulls in the relevant information for data type specific files.

GraphQL Representation of Glific's Contact Group DataType

GraphQL Representation of Glific's Contact Tag DataType

GraphQL Representation of Glific's Contact DataType

Representing our enums in the style Absinthe expects them. We can now use these atoms in the object definitions within the GraphQL Schema

GraphQL Representation of Flow DataType

GraphQL Representation of common data representations used across different Glific's DataType

GraphQL Representation of Glific's Group DataType

GraphQL Representation of Glific's Language DataType

GraphQL Representation of Glific's MessageMedia DataType

GraphQL Representation of Glific's Message Tag DataType

GraphQL Representation of Glific's Message DataType

Implementing middleware functions to transform errors from Ecto Changeset into a format consumable and displayable to the API user. This version is specifically for mutations.

Implementing middleware functions to transform errors from Ecto Changeset into a format consumable and displayable to the API user. This version is specifically for mutations.

Implementing middleware functions to transform errors from Elixir and friends into a format consumable and displayable to the API user. This version is specifically for queries.

GraphQL Representation of Glific's Organization DataType

GraphQL Representation of Glific's Provider DataType

GraphQL Representation of Glific's Search DataType

GraphQL Representation of Glific's Session Template DataType

GraphQL Representation of Glific's Tag DataType

GraphQL Representation of Glific's Template Tag DataType

GraphQL Representation of Glific's User Group DataType

GraphQL Representation of Glific's User DataType

This is a basic plug that loads the current organization assign from a given value set on subdomain.

This is a struct that holds the configuration for GlificWeb.SubdomainPlug.

This is the main module of multi-tenancy in Glific. It has been borrowed from Triplex. (https://github.com/ateliware/triplex). However we are going to us postgres row level security instead, and hence copying the code from there. The original copyright and license (MIT) belong to the contributors to Triplex.