Enums used in Proca database.

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.

Authorization Context for resolvers.

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.

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.

Bulgaria validations for ECI id numbers

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 helpers (to support deprecated Field model)

Represents an organisation in Proca. Org can have many Proca.Staffers, Proca.Services, Proca.Campaigns and Proca.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.

Process which contains a dictionary of encryption keys for orgs. It also generates unique nonce values it is guaranteed they are not re-used if multiple actions are encrypted in parallel.

Setup GenServer to run every 5 minutes to check if there are any emails to send

Server that decides what actions should be done after different events.

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.

Service concept in Proca Server

Every organisation can own a set of services, and each service type has a name. A service record represents API access. Currently names are

Implement supporter detail lookup.

EmailBackend behaviour specifies what we want to expect from an email backend. We are using Swoosh 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 Swoosh does not have this.

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

Lookup email templates.

Mailjet Email Backend

This module lets you send bulk emails via AWS SES.

Currently, a storage service

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

Producers

Processing "stage" that sends thank you emails

Define JSON format for events in proca system.

For these cases

A queue producer for Broadway.

Tools to re-queue action directly into custom or delivery queue

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).

Stage which produces unproduced actions, which might be unprocessed because of no queue was available, or because processing failed.

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.

Target represents a target of a campaign, and contains information about the Target

TargetEmail contains the email data for a Target

The Users context.

Stores token_last_seen timestamps to user_tokens table. Does not store it every time a token is used, not to strain the DB. Synces every 10s

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

Disable or restrict schema introspection to authorized requests

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.

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

Resolvers for action related mutations

Resolvers for action page related mutations

Resolvers for public action lists (recent comments etc.)

Provides macros to handle auth flow in schema files.

Given authenticated user, looks up Proca.Auth struct that matches contextually to resolution result or context. Has two modes

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.

middleware Loader, :campaign, by: [name: :campaign_name, :id]

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

Schema decleration for Target and TargetEmail types

Incoming webhook controller to process call backs from services like Mailjet and SES, etc

Task to create ECI campaign

Mix tasks for managing organisation and generating encryption keys.