API Reference proca v3.0.2


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

Record for action done by supporter. Supporter can have many actions, but actions can be created without a supporter with intention, to match them later to supporter record. This can come handy when we need to create actions for user, but will gather personal data later. It is possible to use ref field to match action to supporter later.

Action Page belongs to a Campaign, and represents a page (widget) where members take action.

Server which tracks and monitors active pages.

Campaign represents a political goal and consists of many action pages. Belongs to one Org (so called "leader org").

Helper methods for manipulating changeset data

Confirm represents a confirmable action deferred in time. It is called confirm, because it is a confirmable - something that must be confirmed by a party. Usually party A creates a confirm, and party B accepts or rejects it. Upon acceptance, the operation can run. Optionaly upon rejection a different action can be triggered.

Invite an org to join a campaign, by creating an action page based off action page subject_id

Confirmed operation to add staffer to org. subject: org object_id: perms (binary) email: invited user

Confirm a request to join campaign. Partner sends such request to campaign lead. v1. A successful confirm makes live all pages in that campaign for org. v2. A successful confirm creates a partnership.

Confirm operation of making action page live.

Each confirmable operation works a bit differently, so modules in Proca.Confirm.* implement the spefics. Thye fallow this behaviour.

Schema holding personal data (PII). Belongs to action page that collected the data, and to organisation which the data is sent to. Contains consent information. Can be encrypted. There can be many Contact records per one supporter (=per one action)

Basic data represents the most typical data set we collect on membres: email as main identifier, names, postcode and country for locality, and optional phone number.

Defines different styles of personal data that are stored in Contact.

Data format for ECI

Rules generated from SQL released by EC (see utils/ECI). Provides schema macro to generate EciData embedded schema

When api resolver validates contact map, it can use these helper funcitons.

schema for residency address

Schema for handling contact: map from graphql addAction* mutations

schema for national id

Data format for Italian Citizens' Initiative

Data gathered for Popular Initiative in Switzerland.

Custom field.

Represents an organisation in Proca. Org can have many Staffers, Campaigns and ActionPage's.

Permission bits used in proca. Should be named with a verb_noun (_owner is an exception here).

Supervisor of Topology processes and Processing Workers.

Topology of processing queue setup in RabbitMQ.

Keypair for encyrption of personal data

Tasks to seed and migrate the db on app start

Contains helpers for writing Proca Schemas. use Proca.Schema, module: Proca.MyRecordModule

Server which holds Home Org encryption keys and current nonce, and performs encryption and decryption of messages to other Orgs using their public keys.

Because JWT authentication requires a JWKS certificate retrieved from an url (from the token issuer), this server holds/caches this information.

Stores encryption keys and nonces for each Org id

Server that decides what actions should be done after different events

Plumbing server is responsible for setting up the signature processing in Proca.

For these cases

Stores campaign and action page signature counts in following structure (under campaign state key)

Service belong to Org and are hostnames, paths and credentials to external services that you can configure.

EmailBackend behaviour specifies what we want to expect from an email backend. We are using Bamboo for sending emails - it is very convenient because it has lots of adapters. However, we also need to be able to work with templates and Bamboo does not have this.

Represents an email recipient, for email templates that can be persnonalized.

Models an email tempalate to be rendered into a thank you email, etc.

Mailjet Email Backend

This module lets you send bulk emails via AWS SES.

Service configuration of webhook.

Holds utm codes. Will be reused by many actions

Join table between Org and User. Means that user has a role/some permissions in an Org.

For the organisation (they should be exclusive)

Processing "stage" that sends thank you emails

Server which processes older actions, which might be unprocessed because of not queue was available, or processing failed.

Processing "stage" that sends data to SQS

Support functions for job processing in Broadway. Most imporatntly functions to build RabbitMQ events containing enough data to be processed internally (system) or externally (custom).

Processing "stage" that sends events to webhook.

Supporter is the actor that does actions. Has associated contacts, which contain personal data dediacted to every receiving org

Models a consent for entered personal data, for an Org. Ultimately stored in Contact record.

This module specifies how the supporter presonal data is stored and share between orgs.

The Users context.

Password generator for users

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

Controller processing two kinds of confirm links

Alternative router used in ECI build. Minimal version of ProcaWeb.Router

Module with named helpers generated from ProcaWeb.EciRouter.

Error struct to be used universally in the resolver codebase - translated to the respective (GraphQL, REST) error formats.

Conveniences for translating and building error messages.

A module providing Internationalization with a gettext-based API.

Helper functions for formatting errors from resolvers

A plug that reads JWT from Authorization header and authenticates the user

A plug that passes headers from request to Absinthe context (into :headers map).

Helpers for returning errors from plugs. If the request is JSON, the error is structured like GQL error.

A plug that reads JWT from Authorization header and authenticates the user

Plug that reads "extensions" key from GraphQL paramters and addsthem to context of GQL resolution. This is to handle Apollo style extensions in requests.

Resolvers for action related mutations

Resolvers for action page related mutations

Resolvers for public action lists (recent comments etc.)

Absinthe middleware to mark authenticated API calls.

Resolvers for campaign queries in mutations

Absinthe middleware to check if captcha code is provided with request. Captcha should be provided in extension: captcha: key

Resolver for org { exportAction } query

Because only context is passed via private settings from Absinthe.Plug, we need to pass extensions loaded with ParseExtensions plug inside context. In this middleware we move it to Resolution.extensions.

Resolvers for org { } root query

Resolvers for org { } root query

Main app router

Module with named helpers generated from ProcaWeb.Router.

Main API schema. See schema/ for details.

API for campaign and action page entities

API for action entities

API for campaign and action page entities

API form confirms

Defines custom types used in API, and how to serialize/parse them

An alternative API schema (replaces ProcaWeb.Schema) used in ECI build.

API for org entities

API for Services

API schema for subscriptions

Mix Tasks

Task to create ECI campaign

Mix tasks for managing organisation and generating encryption keys.