# MakingHistory - Emissary

We are customising an instance of Emissary to run MakingHistory.


## TODO

- Currently using a FILESYSTEM entry for emissary to access our MakingHistory
  templates.
    - Switch to using a hosted `git` repo instead


## Brief Architecture Overview

From the bottom up:

- Database
- Model Objects
  - define info saved in database
- Services
  - R/W objects to db
  - Handle queries
  - Handle inter-object actions
- Builders
  - Assemble different bits of functionality from services
    e.g.
    access data from inbox
    what's your username
    is the user I'm looking at actually me
    how many rules have I defined
    how many people are following me
    queries to get followers, following, folders we put people into, etc
    i.e. info we want to collect comes from varying services;
        builders assemble into pretty and limited API
  - Defines the public API


## Template Overview

- templateRole
    This role makes the template eligible to be displayed as a UI choice for user inbox
- model
    The model sets which go builder to use with this template
- extends
    Extends inherits from other templates
- containedBy
    Limit this template such the it can only be used from within certain others
    NOTE: I believe templateId's would be the content of the array
    TODO: Confirm the above note
- schema
    A schema sets up the data structure that will be used inside a template
    Defines the 'data' section of relevant table entry in mongodb
    Based on json, without linking between schemas; all rules must be defined herein
- states
    Each piece of content can pass through a state machine; e.g. unpublished, published, for-review, etc
- roles
    Works alongside states
    [Currently being reworked in the codebase]
    Assignable to various 'groups' [later, 'circles' as well]
- bundles
    Define static assets; e.g. stylesheets, js, compressed or not
    If not defined in a bundle, we may just define a 'resources' folder,
    whereby all content within will be fetchable by the client
- actions
    Every action has a name, which corresponds to a set of workflow 'steps' we
    want to be taken when that action is called by users with a certain 'role'
    - roles
    - stateRoles
        define which 'roles' can access the data when in a given 'state'
    - steps
        - do
            - "view-html"
                - by default will use the action name as the filename
        - file
            - define filename to be used for the step