Broker-Web Documentation

This is the official developer documentation for the Pitt-Google Broker Website.

Website Specification Document

The Website Specification Document (WSD) outlines key objectives and design decisions relevant to developing the web front-end of the Pitt-Google Broker (herein the project and PGB respectively).

Overview

The current design of the PGB focuses on providing services within a cloud based environment. While this provides many benefits from a computational and scalability perspective, familiarity of cloud based services is not common within all parts of the scientific / astronomical community. To mitigate this potential obstacle for PGB users, a website interface will be used to provide a public reference for PGB services. This includes (but is not limited to) providing basic access to PGB data products, either in whole or in part.

Functionality

Data Access:

  1. Access to tabulated data for recent alerts / objects (e.g. last week or month or 10,000 alerts).
  2. Ability for users to define custom topic subscriptions
  3. User configurable subscriptions to PGB alert topics
  4. User configurable subscriptions notifications. Options to:
    • Send to email
    • Subscribe on slack
    • Alert within website
  5. Guides on how to access data in the cloud and instructions on where to go for more information on cloud deployment.
  6. Options throughout the UI to share data with collaborators, both via email and from within the web application.

TOM Integration:

  1. Management of users’ observatory API keys
  2. Ability to submit observing requests to remote observatories
  3. Alert notifications when observations are completed (email and in site)

Authentication:

  1. Email validation when signing up for a new user account
  2. Recaptcha validation when logging in and creating new accounts
  3. Ability to authenticate via an existing Google account
  4. Permission roles for unauthenticated, general users, staff, and admin

Accessibility

The project will adhere to WCAG 2.0 guidelines. To assist in this, this project will use the adherence checklists provided by wuhcag.com. A minimum of Level 1 accessibility will be provided in final production, which is formalized below. These requirements hold across all platforms, including desktop, tablet, and mobile browsers. No accessibility requirements are formally imposed during the development process, only on the final delivered product.

Level 1 Requirements

Guideline Summary
1.1.1 – Non-text Content Provide text alternatives for non-text content
1.2.1 – Audio-only and Video-only (Pre-recorded) Provide an alternative to video-only and audio-only content
1.2.2 – Captions (Pre-recorded) Provide captions for videos with audio
1.2.3 – Audio Description or Media Alternative (Pre-recorded) Video with audio has a second alternative
1.3.1 – Info and Relationships Logical structure
1.3.2 – Meaningful Sequence Present content in a meaningful order
1.3.3 – Sensory Characteristics Use more than one sense for instructions
1.4.1 – Use of Colour Don’t use presentation that relies solely on colour
1.4.2 – Audio Control Don’t play audio automatically
2.1.1 – Keyboard Accessible by keyboard only
2.1.2 – No Keyboard Trap Don’t trap keyboard users
2.2.1 – Timing Adjustable Time limits have user controls
2.2.2 – Pause, Stop, Hide Provide user controls for moving content
2.3.1 – Three Flashes or Below No content flashes more than three times per second
2.4.1 – Bypass Blocks Provide a ‘Skip to Content’ link
2.4.2 – Page Titled Use helpful and clear page titles
2.4.3 – Focus Order Logical order
2.4.4 – Link Purpose (In Context) Every link’s purpose is clear from its context
3.1.1 – Language of Page Page has a language assigned
3.2.1 – On Focus Elements do not change when they receive focus
3.2.2 – On Input Elements do not change when they receive input
3.3.1 – Error Identification Clearly identify input errors
3.3.2 – Labels or Instructions Label elements and give instructions
4.1.1 – Parsing No major code errors
4.1.2 – Name, Role, Value Build all elements for accessibility

Hosting

The project will be hosted using the Google Cloud Platform. The web application itself will be hosted using App Engine while the backend database will rely on the Cloud SQL service. This choice is motivated by the following factors:

  1. PGB Data products are also hosted in the cloud, so deploying to the cloud makes it easier to interface the website with PGB data products.
  2. Cloud services (App engine and Cloud SQL) scale automatically to meet demand. This means we don’t have to manage servers or services to meet user demand.
  3. GCP works on a “pay for what you use” basis. This minimizes operating costs, and scales to zero cost during periods of low website traffic.

Project Phases

This project is broken down into separate development stages listed below. In general, later phases depend on the completion of work in earlier phases. However, there is some room for simultaneous work on successive phases. Late stage phases (5-7) are intentionally left blank, and are to be outlined in detail before be-ing undertaken.

Phase 1 – Establish a Foundational Website

This phase is targeted on getting up and running. Focus is placed on getting most of the heavy lifting out of the for a rudimentary, functional website so team team members can contribute in later phases during spare or 20% time.

  • Design jinja HTML templates for core website pages including:
    • A landing page
    • Getting started pages for describing PGB services and products
    • A page with tabulated data of recently published alerts
    • A page displaying information for a single alert and it’s data products
    • A page with tabulated data of recently observed objects
    • A page displaying information for a single object and it’s data products
  • Build a Django backend capable of supporting the above listed pages. At a minimum include apps for:
    • Interacting ith alert data (alerts)
    • Interacting ith object data (objects)
    • Signing up new users (signup)
    • User profiles (subscriptions)
  • Add a custom user authentication model to the backend that includes at minimum:
    • Username and / or email
    • First and last name
    • Host country / university
  • Add forms and pages for adding new users. Tie this to a sign up page

Phase 2 – Documentation and Testing

This phase is targeted at ensuring the project has a solid foundation for moving forward efficiently. Some of the work in this phase may have already been implement in Phase 1 by virtue of good coding habits.

  • Use sphinx to write dedicated documentation for:
    • Installation instructions
    • Configuring GCP services to support the project
    • Project goals
  • Write supplemental documentation for autodoc content generated by sphinx
  • Deploy sphinx documentation for the project to Read The Docs
  • Configure tests with travis
  • Ensure a minimum of 50% test coverage for the django backend
  • Configure style / quality control with code climate or a similar service

Phase 3 – Styling and Content

This phase begins populating the website with static and dynamic content. This includes technical documentation on PGB services, getting started guides, PGB data products, etc. Progress at this phase is somewhat limited by the availability of PGB data products. This phase should be completed to the extent allowed by the PGB development status, and can be revisited as necessary.

Static content (phase 3a):

  • Implement an initial CSS template to style existing HTML templates
  • Add CSS styling to the django admin interface
  • Add textual content for all existing pages. Much of this can be pulled from existing PGB documentation. Place holder text should be avoided when possible.

PGB content (phase 3b):

  • Connect the alerts app to PGB and populate pages with real data
  • Connect the objects app to PGB and populate pages with real data
  • Add PGB online status to the home page
  • Add plots of alert data to object pages

Phase 4 – Design review and Deployment

  • Validate project meets accessibility requirements
  • Acquire external input concerning overall website design and implement any desired changes.
  • Ensure a minimum of 75% test coverage for the django backend
  • Signup pages and contact forms are checked for correct configuration with the email backend
  • All web pages correctly implement required authentication requirements
  • No major error messages rendered by the site
  • Functioning website deployed to App Engine with continuous deployment
  • Evaluate next steps by outlining phases 5-7

Phase 5 – Adding Content Topic Subscriptions

Phase 6 – Adding a Collaborative User Platform

Installation and Setup

This page provides instructions for downloading, configuring, and running a local copy the website.

Python Dependencies

The broker website is packaged as the broker_web Python package, which is available on GitHub. To download the code from this repository and install the dependencies, use:

# Download project source code
git clone https://github.com/mwvgroup/Broker-Web

# Install Python dependencies with pip
pip install -r Broker-Web/requirements.txt

Local Database

The source code expects you to have already established a MySQL database for storing user and website data. If this database is not already available on your local machine, you can create a user and databases for development as shown below.

Important

It is strongly recommended for security reasons that you use a dedicated set of credentials when developing. This means the username and password for your local database should be different from any credentials you may have for the deployed database.

$ mysql -u root -p

mysql> CREATE DATABASE [DB_NAME];
mysql> CREATE USER '[DB_USER]'@'localhost' IDENTIFIED BY '[DB_PASSWORD]';
mysql> GRANT ALL PRIVILEGES ON [DB_NAME].* TO 'DB_USER'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> quit;

You should repeat the above process twice: Once for the database you wish to develop against, and once to set permissions for the database you want to run tests against. The testing database has the same name of the development database prefixed with the word 'test_'.

mysql> CREATE DATABASE test_[DB_NAME];
...

Environmental Variables

The following table outlines environmental variables that can be used to configure standard Django settings. The ALLOWED_HOSTS variable must be set for the app to run if DEBUG is set to False (the default).

Variable Description Required
SECRET_KEY Django secret key Yes
DEBUG Whether to run in debugging mode Must be True if ALLOWED_HOSTS is not set
ALLOWED_HOSTS Block requests except from these domains If Debug is not true
CONTACT_EMAILS List of developer contact emails No

You will also need to specify various environmental variables for configuring your database connection.

Variable Description Required
DB_NAME Name of the MySQL database for user data No (Default = web_backend)
DB_USER MySQL username Yes
DB_PASSWORD MySQL password Yes
DB_HOST Database host connection For local database only
DB_PASSWORD Port number to connect on For local database only
TEST_NAME Name of the MySQL database used in tests No (Default = text_[DB_NAME])
ZTF_ALERTS_TABLE_NAME Name of the Bigquery table with ZTF alert data ingested by the broker pipeline. No (Default = text_[DB_NAME])

Note

For convenience, environmental variables can be specified in a .env file placed into the project’s root directory. However, the application will ignore ``.env`` files when running on the deployment server.

Running a Local Instance

With your databases created and environmental variables defined, you can configure the database schema using the management script:

python manage.py makemigrations
python manage.py migrate --run-syncdb

At this point, it is also useful to create an admin account for the website:

python manage.py createsuperuser

Finally, a local server for the website can then be launched in standard Django fashion:

python manage.py runserver

GCP Configuration

Full documentation on configuring Django applications for App Engine is available in the official App Engine docs. Notes are provided here for those configuring an environment from scratch. These steps only need to be performed once. If you are developing against the official Pitt-Google Broker GCP project then these these steps should have already been taken.

Static File Storage

You will need to configure a GCP Storage Bucket for publicly hosting static files (images, CSS, etc.). This can be from the console webpage or from the command line as shown below. :

  1. Create a bucket for hosting static files. Default values for the storage class and bucket location should be sufficient, but can be specified if desired.
gsutil mb -p [PROJECT_NAME] -c [STORAGE_CLASS] -l [BUCKET_LOCATION] -b on gs://[BUCKET_NAME]/
  1. Make sure the bucket is publicly readable.
gsutil defacl set public-read gs://broker-web-static

Cloud SQL

The website will pull data from the broker pipeline to populate page content as necessary. However, a dedicated Cloud SQL database is also used to store website and user data. You can use the console SQL interface to create this database, or accomplish it from the command line:

  1. Start by making sure the Cloud SQL Admin API is enables.
gcloud services enable sqladmin
  1. Create a Cloud SQL instance.
gcloud sql instances create [INSTANCE_NAME] --tier=[MACHINE_TYPE] --region=[REGION]
  1. Create a database on the Cloud SQL instance.
gcloud sql databases create [DATABASE_NAME] --instance=[INSTANCE_NAME]
  1. Create a new user account that your application will user to access the database.
gcloud sql users create [USER_NAME] --instance=[INSTANCE_NAME] --password=[PASSWORD]

The Django Application

Once Cloud SQL is configured, you will need to create the necessary database tables. The management script packaged with the website’s source code automates this process. You will need to connect to the Cloud SQL database and migrate database models from the Django application into the database.

  1. Use the Cloud SDK to fetch the connection name of your instance. The connection name will be listed in the format [PROJECT_NAME]:[REGION_NAME]:[INSTANCE_NAME].
gcloud sql instances describe [INSTANCE_NAME]
  1. Make sure the database settings in the Django application (broker_web/main/settings.py) point to the new database you just created. In general, the settings should look like the following:
# broker_web/settings.py

if os.getenv('GAE_APPLICATION', None):
    # Running on production App Engine, so connect to Google Cloud SQL using
    # the unix socket at /cloudsql/<your-cloudsql-connection string>
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.mysql',  # Assuming you are using MySQL
            'HOST': '/cloudsql/[CONNECTION_NAME]',
            'NAME': '[DATABASE_NAME]',
            # You'll probably want to set the auth data in your environment
            'USER': '[DATABASE_USER]',
            'PASSWORD': '[DATABASE_PASSWORD]',
        }
    }

else:
    # Running locally so connect to Cloud SQL via the proxy.
    # To start the proxy see https://cloud.google.com/sql/docs/mysql-connect-proxy
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.mysql',
            'HOST': '127.0.0.1',
            'PORT': '3306',
            'NAME': '[DATABASE_NAME]',
            # Here is an example using django-environ
            'USER': env.str('DB_USER'),
            'PASSWORD': env.str('DB_PASSWORD'),
        }
    }
```
  1. Launch a SQL proxy so a a Django application running from your local machine can connect to the GCP SQL database. Instructions on downloading the cloud_sql_proxy application are available here.
./cloud_sql_proxy -instances "[REGION_NAME]"=tcp:3306
  1. Make the necessary database migrations and set up an admin account.
python manage.py migrate --run-syncdb
python manage.py createsuperuser
  1. As a final step you will need to configure the Recaptcha service which is used to protect against bots. Make sure to add the appropriate public recaptcha key to broker_web/templates/recaptcha.html

Running Locally

A development version of the website can be run locally in two configurations:

  1. Running locally against a local database
  2. Running locally against the deployment database in the cloud

The first configuration should be the default when developing. Working against the deployment database is rarely necessary and should be undertaken with care.

GCP Dependencies

The broker website is built to run in the cloud using App Engine. If you intend to run the website against a local development database, this step can be skipped. If you intend to run the website using GCP resources you will need to install the gcloud command line tool which is available `here`_. You will also need to install the Google Cloud SQL Proxy so the website can connect to the necessary SQL backends when running locally.

For Mac OS 64 bit, use:

curl -o cloud_sql_proxy https://dl.google.com/cloudsql/cloud_sql_proxy.darwin.amd64
chmod +x cloud_sql_proxy

For Linux 64 bit, use:

wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
chmod +x cloud_sql_proxy

For other installations see the appropriate section of the official App Engine docs.

Running Against The Cloud

  1. Configure environmental variables as defined in the previous section.
  2. Start by launching the SQL proxy so the application can connect to the cloud.
./cloud_sql_proxy -instances "ardent-cycling-243415:us-east1:broker-web"=tcp:3306
  1. Next, launch the web application via the management script:
python broker_web/manage.py runserver  # Run the web server

Deploying to App Engine

The production version of the website is hosted in the cloud using GCP App Engine. This page outlines instructions for deploying new versions of the website source code to the cloud.

Updating Static Files

Static files are updated in the cloud separately from deploying changes to the source code. This includes pushing source code changes via continuous deployment. Static files can be synced against a local version of the project by running:

gsutil -m rsync -r broker_web/static gs://[BUCKET_NAME]/static

Manual Deployment

Important

The following section is provided for reference only. All updates to the official website should be performed via continuous deployment as outlined later in this document.

Deployment settings should be configured using the app.yaml file. The official app.yaml docs can be found here. At a minimum, your settings for deployment should include the following:

runtime: python37

entrypoint: gunicorn -b :$PORT broker_web.main.wsgi

env_variables:
  SECRET_KEY: '[YOUR-SECRET-KEY]'
  STATIC_URL: 'https://storage.googleapis.com/[BUCKET-NAME]/static/'
  DB_USER: [SQL-DB-USERNAME]
  DB_PASSWORD: [SQL-DB-PASSWORD]
  ALLOWED_HOSTS: [OFFICIAL-PGB-WEBSITE-DOMAIN]

handlers:
  - url: /static
    static_dir: static

Application versions can be deployed manually using the gcloud API. The command below will automatically use the app.yaml file located in the working directory.

gcloud app deploy

Continuous Deployment

Note

The TLDR of this section is to submit a pull request against the appengine-staging branch of the project repository. A new version of the website will start building automatically.

Similar to when deploying manually, an app.yaml configuration file must be created to store deployment settings. However, instead of storing the file locally, the file should be save to a GCP bucket. This file persists across deployments and only needs to be replaced if you are changing the website’s deployment settings. You will also need a cloudbuild.yml file to configure the website build process. A version controlled copy of this file should be included with the website’s source code.

To trigger a new build, merge a pull request into the appengine-staging branch of the projet’s repository. The new build will be automatically triggered and it’s progress can be tracked in Cloud Build. If you run into deployment errors, the GCP docs may be of some help.

main

The main module represents the main django application. It handles the settings and URL routing for the website and includes minimal custom views or models.

Submodules

broker_web.main.asgi Exposes the ASGI callable as a module-level variable named application.
broker_web.main.settings Django settings
broker_web.main.urls URL routing for the main django application.
broker_web.main.views Defines views for converting a Web requests into a Web responses
broker_web.main.wsgi Web Server Gateway Interface configuration

App URL Routing

URL routing for the main django application. URLS from each application is routed to the following namespaces:

Application Namespace
apps.alerts alerts
apps.contact contact
apps.getting_started getting-started
apps.objects objects
apps.signup signup
apps.subscriptions subscriptions

apps.alerts

A django application for serving up data about recently observed LSST/ZTF alerts published in a collection of configured PubSub topics.

apps.alerts.urls

The urls module configures routes from URLs to views.

URL View name
/ RecentAlertsView recent-alerts
<str:pk> AlertSummaryView alert-summary
json/ AlertsJsonView alerts-json

apps.alerts.forms

The forms module defines views forms for data entry and query construction.

broker_web.apps.alerts.forms.FilterAlertsForm Form for filtering a table of alerts
class broker_web.apps.alerts.forms.FilterAlertsForm(data=None, files=None, auto_id='id_%s', prefix=None, initial=None, error_class=<class 'django.forms.utils.ErrorList'>, label_suffix=None, empty_permitted=False, field_order=None, use_required_attribute=None, renderer=None)

Form for filtering a table of alerts

Fields:
include_internal (BooleanField) min_ra (FloatField) max_ra (FloatField) min_dec (FloatField) max_dec (FloatField)` time_range (DurationField)

apps.alerts.views

The views module defines View objects for converting web requests into rendered responses.

broker_web.apps.alerts.views.AlertsJsonView Serves recent alerts as a paginated JSON response
broker_web.apps.alerts.views.AlertSummaryView Displays information about a single alert
broker_web.apps.alerts.views.RecentAlertsView Provides a summary table of recently ingested alerts
class broker_web.apps.alerts.views.AlertSummaryView(**kwargs)

Displays information about a single alert

get(request, *args, **kwargs)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing JsonResponse
get_alert_data_for_id(alert_id, survey)

Retrieve alert data for a given alert ID

Parameters:
  • alert_id (int) – Id of the alert to retrieve data for
  • survey (str) – Parent survey of the alert
Returns:

A dictionary of alert data
static get_value_added_data_for_id(alert_id, survey)

Retrieve value added data products for a given alert ID

Parameters:
  • alert_id (int) – Id of the alert to retrieve data for
  • survey (str) – Parent survey of the alert
Returns:

A dictionary of value added data products
class broker_web.apps.alerts.views.AlertsJsonView(**kwargs)

Serves recent alerts as a paginated JSON response

static fetch_alerts_as_dicts(request, num_alerts=10000)

Returns a list of recent alerts messages as dicts

Parameters:
  • request (HttpRequest) – Incoming HTTP request
  • num_alerts (int) – Maximum number of alerts to return
Returns:

A list of dictionaries representing
get(request)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing JsonResponse
class broker_web.apps.alerts.views.RecentAlertsView(**kwargs)

Provides a summary table of recently ingested alerts

get(request)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing HTTPResponse
post(request)

Fill in the page’s form with values from the POST request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing HTTPResponse

apps.contact

A django application for handling an email contact form.

apps.contact.urls

The urls module configures routes from URLs to views.

URL View name
/ ContactView contact
sent SuccessView contact-sent

apps.contact.forms

The forms module defines views forms for data entry and query construction.

broker_web.apps.contact.forms.ContactForm Form to send a “contact us” email to the maintainers
class broker_web.apps.contact.forms.ContactForm(data=None, files=None, auto_id='id_%s', prefix=None, initial=None, error_class=<class 'django.forms.utils.ErrorList'>, label_suffix=None, empty_permitted=False, field_order=None, use_required_attribute=None, renderer=None)

Form to send a “contact us” email to the maintainers

apps.contact.views

The views module defines View objects for converting web requests into rendered responses.

broker_web.apps.contact.views.ContactView View for submitting an email to the website maintainers
class broker_web.apps.contact.views.ContactView(**kwargs)

View for submitting an email to the website maintainers

form_class

alias of broker_web.apps.contact.forms.ContactForm

form_valid(form)

Send contents of email form and redirect to success url

Called after form is validated

Parameters:form (django.forms.Form) – User creation form

apps.getting_started

A django application for handling displaying a getting started guide. This application primarily provides views for generic/static web pages.

apps.getting_started.urls

The urls module configures routes from URLs to views.

URL View name
/ Introduction introduction
data_products DataProducts data-products
technical_resources TechnicalResources technical-resources
data_access DataAccess data-access
broker_design BrokerDesign broker-design

apps.getting_started.views

The views module defines View objects for converting web requests into rendered responses.

broker_web.apps.getting_started.views.Introduction Static template view
broker_web.apps.getting_started.views.DataProducts Static template view
broker_web.apps.getting_started.views.TechnicalResources Static template view
broker_web.apps.getting_started.views.DataAccess Static template view
broker_web.apps.getting_started.views.BrokerDesign Static template view

apps.objects

A django application for serving data concerning recently observed astronomical objects. The focus of this app is on the object itself, and not the corresponding alerts.

apps.objects.urls

The urls module configures routes from URLs to views.

URL View name
/ RecentObjectsView recent-objects
/<str:pk> ObjectSummaryView object-summary
/salt2/ Salt2FitView salt2-fits
json/ RecentObjectsJsonView objects-json
/singlejson/<str:pk> RecentAlertsJsonView single-object-json
salt2json/ Salt2FitsJsonView salt2-fit-json
salt2json/<str:pk> Salt2FitsJsonView salt2-fit-json

apps.objects.forms

The forms module defines views forms for data entry and query construction.

broker_web.apps.objects.forms.FilterObjectsForm Form for filtering a table of alerted objects
class broker_web.apps.objects.forms.FilterObjectsForm(data=None, files=None, auto_id='id_%s', prefix=None, initial=None, error_class=<class 'django.forms.utils.ErrorList'>, label_suffix=None, empty_permitted=False, field_order=None, use_required_attribute=None, renderer=None)

Form for filtering a table of alerted objects

Fields:
time_range (DurationField) min_ra (FloatField) max_ra (FloatField) min_dec (FloatField) max_dec (FloatField)

apps.objects.views

The views module defines View objects for converting web requests into rendered responses.

broker_web.apps.objects.views.ObjectsJsonView
broker_web.apps.objects.views.RecentAlertsJsonView
broker_web.apps.objects.views.ObjectSummaryView View for displaying a table of all recent objects matching a query
broker_web.apps.objects.views.RecentObjectsView View for displaying a summary table of objects with recent alerts
class broker_web.apps.objects.views.ObjectSummaryView(**kwargs)

View for displaying a table of all recent objects matching a query

get(request, *args, **kwargs)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing JsonResponse
class broker_web.apps.objects.views.RecentObjectAlertsJsonView(**kwargs)

JSON rendering of recent alerts for a given object

static fetch_object_alerts(object_id, limit=50)

Return a list of all alerts corresponding to an object Id

Parameters:
  • object_id (str) – Object identifier
  • limit (int) – Maximum number of alerts to return
Returns:

A list of dictionaries
get(request, *args, **kwargs)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing JsonResponse
class broker_web.apps.objects.views.RecentObjectsJsonView(**kwargs)

View for serving recently observed objects as a paginated JSON response

static fetch_objects(limit=10000)

Returns a list of objects with recently issued alerts as a list of dicts

Parameters:limit (int) – Maximum number of alerts to return
Returns:A list of dictionaries representing
get(request)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing JsonResponse
class broker_web.apps.objects.views.RecentObjectsView(**kwargs)

View for displaying a summary table of objects with recent alerts

get(request)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing HTTPResponse
post(request)

Fill in the page’s form with values from the POST request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing HTTPResponse
class broker_web.apps.objects.views.Salt2FitView(**kwargs)

View for displaying a table of salt2 fits to recently observed objects

get(request, *args, **kwargs)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing JsonResponse
class broker_web.apps.objects.views.Salt2FitsJsonView(**kwargs)

View for serving recent Salt2 fit results as a paginated JSON response

static fetch_salt2_fits(object_id=None, limit=1000)

Return a list of recent Salt2 fits for a given astronomical object

Parameters:
  • object_id (str) – Object identifier
  • limit (int) – Maximum number of fits to return
Returns:

A list of dictionaries
get(request, *args, **kwargs)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing JsonResponse

apps.signup

A django application for managing creation and authentication of new user accounts.

apps.signup.urls

The urls module configures routes from URLs to views.

URL View name
/ SignUp signup
activation_sent ActivationSentView activation-sent
[AUTH-TOKEN-LINK] ActivateAccount activate

apps.signup.admin

The admin module defines app level interfaces for the website’s admin panel.

class broker_web.apps.signup.admin.CustomUserAdmin(model, admin_site)

Custom admin interface for user management

add_form

alias of broker_web.apps.signup.forms.CustomUserCreationForm

form

alias of broker_web.apps.signup.forms.CustomUserChangeForm

model

alias of broker_web.apps.signup.models.CustomUser

apps.signup.forms

The forms module defines views forms for data entry and query construction.

broker_web.apps.signup.forms.CustomUserChangeForm Custom form for modifying user data
broker_web.apps.signup.forms.CustomUserCreationForm Custom form for creating a new CustomUser
class broker_web.apps.signup.forms.CustomUserChangeForm(*args, **kwargs)

Custom form for modifying user data

class broker_web.apps.signup.forms.CustomUserCreationForm(*args, **kwargs)

Custom form for creating a new CustomUser

validate(value)

Check if value consists only of valid emails.

apps.signup.managers

The managers module defines Manager objects to handle DB changes

class broker_web.apps.signup.managers.CustomUserManager

Custom user model manager

create_superuser(email, password, **extra_fields)

Create and save a SuperUser with the given email and password.

create_user(email, password, **extra_fields)

Create and save a User with the given email and password.

apps.signup.models

The models module defines Model objects for representing backend DB constructs.

class broker_web.apps.signup.models.CustomUser(*args, **kwargs)

Custom user model for authentication

exception DoesNotExist
exception MultipleObjectsReturned

apps.signup.tokens

Custom token generation for user signup tasks

class broker_web.apps.signup.tokens.TokenGenerator

apps.signup.views

The views module defines View objects for converting web requests into rendered responses.

broker_web.apps.signup.views.ActivateAccount View that account verification
broker_web.apps.signup.views.ActivationSentView Render a template.
broker_web.apps.signup.views.SignUp View that handles CustomUser creation
class broker_web.apps.signup.views.ActivateAccount(**kwargs)

View that account verification

get(request, uidb64, token)

Handle an incoming HTTP request

Parameters:
  • request (HttpRequest) – Incoming HTTP request
  • uidb64 (str) – Base 64 encoded user id
  • token (str) – Activationn auth token
Returns:

Outgoing HTTPResponse
class broker_web.apps.signup.views.SignUp(**kwargs)

View that handles CustomUser creation

form_class

alias of broker_web.apps.signup.forms.CustomUserCreationForm

form_valid(form)

Sends email confirmation for new user creation

Called after form is validated

Parameters:form (django.forms.Form) – User creation form

apps.subscriptions

A django application for managing user profiles and topic subscriptions

apps.subscriptions.urls

The urls module configures routes from URLs to views.

URL View name
/ SubscriptionsView subscriptions
profile ProfileView profile

apps.subscriptions.views

The views module defines View objects for converting web requests into rendered responses.

broker_web.apps.subscriptions.views.ProfileView View that handles user profiles
broker_web.apps.subscriptions.views.SubscriptionsView View that handles new user subscriptions
class broker_web.apps.subscriptions.views.ProfileView(**kwargs)

View that handles user profiles

get(request, *args, **kwargs)

Handle an incoming HTTP request

Parameters:request (HttpRequest) – Incoming HTTP request
Returns:Outgoing HTTPResponse
class broker_web.apps.subscriptions.views.SubscriptionsView(**kwargs)

View that handles new user subscriptions

apps.utils

General utilities used across apps

Paginating JSON Responses

The paginate_to_json function handles the generation of JSON responses to HTTP requests for pagination of data. For example, it can be used in a view as:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
from django.views.generic import View

from apps.utils import paginate_to_json

class MyView(View):

    template = 'myt_template_path.html'

    def get(self, request, *args, **kwargs):
        data = [{'field1': 'value1'}, {'field1': 'value2'}, ...]
        return paginate_to_json(request, data)

apps.utils.templatetags.utility_tags

The utility_tags module defines functions for casting between different data types and formats. These functions are automatically registered as template tags for use in the Django template engine.

broker_web.apps.utils.templatetags.utility_tags.bytes_to_64utf8 Convert bytes data to UTF8
broker_web.apps.utils.templatetags.utility_tags.jd_to_readable_date Convert a julian date to a human readable string
broker_web.apps.utils.templatetags.utility_tags.urlparams Format keyword arguments as url parameters
broker_web.apps.utils.templatetags.utility_tags.bytes_to_64utf8(bytes_data)

Convert bytes data to UTF8

Parameters:bytes_data (bytes) – Bytes data
Returns:A string in UTF-8 format
broker_web.apps.utils.templatetags.utility_tags.jd_to_readable_date(jd)

Convert a julian date to a human readable string

Parameters:jd (float) – Datetime value in julian format
Returns:min’ format
Return type:String in ‘day mon year hour
broker_web.apps.utils.templatetags.utility_tags.urlparams(**kwargs)

Format keyword arguments as url parameters

Returns:A string in the format ‘?<key>=<value>’