Merge branch 'upgrade-django' into 'master'

2.0: Upgrade the repo

Closes #38, #44, #33, #28, #15, #35, #30, and #31

See merge request !16

.gitignore

@@ -10,5 +10,7 @@ build
 apache
 .ropeproject
 whats_open/secret_key.py
-website/static/admin/
+whats_open/assets/
+static/admin/
 data
+whats_open/website/migrations
\ No newline at end of file

.gitlab-ci.yml

+services:
+  - mysql:latest
+
+variables:
+  MYSQL_DATABASE: wopen
+  MYSQL_ROOT_PASSWORD: root
+
+types:
+  - test
+
+before_script:
+  - apt-get update -qy
+  - apt-get install -y mysql-client libmysqlclient-dev python-mysqldb  
+  - pip install -r requirements/test.txt
+  - cd whats_open/
+  - export WOPEN_SECRET_KEY=$(dd if=/dev/urandom count=100 | tr -dc "A-Za-z0-9" | fold -w 60 | head -n1 2>/dev/null)
+  - export WOPEN_EMAIL_DOMAIN="@masonlive.gmu.edu"
+  - export WOPEN_DB_NAME="wopen"
+  - export WOPEN_DB_USER="root"
+  - export WOPEN_DB_PASSWORD="root"
+  - export WOPEN_DB_HOST="mysql"
+  - export WOPEN_DB_PORT=3306
+  - export WOPEN_SUPERUSER=admin
+  - python manage.py makemigrations
+  - python manage.py makemigrations website
+  - python manage.py migrate
+  - echo "from django.contrib.auth import get_user_model; User = get_user_model(); User.objects.create_superuser('root', 'root@srct.gmu.edu', 'root') " | python manage.py shell
+
+whats-open-py2.7:
+  image: library/python:2.7
+  type: test
+  script:
+    - python manage.py test
+
+whats-open-py3.5:
+  image: library/python:3.5
+  type: test
+  script:
+    - python manage.py test
+
+whats-open-py3.6:
+  image: library/python:3.6
+  type: test
+  script:
+    - python manage.py test
+    - coverage run --source=website --omit=*migrations/*,*admin.py,*__init__.py,*.pyc manage.py test
+    - coverage html -i && grep pc_cov htmlcov/index.html | egrep -o "[0-9]+\%" | awk '{ print "covered " $1;}'

.gitlab/bug.md

+## Expected Behavior
+
+Describe briefly what the app should be doing or, what the expected behavior would
+be given a certain input or action.
+
+## Actual Behavior
+
+Describe briefly what actually occurs in the app given the input described above.
+
+## Steps to Reproduce the Behavior
+
+A numbered list of steps starting from the earliest possible moment up until the 
+bug occurs. Something that could be used by other developers to reproduce the bug
+that is being reported.

.gitlab/default.md

+## Summary
+Here you should include two to three sentences explaining the thought process
+about the current issue. Perhaps a picture? Some details that could best help someone,
+especially someone new, understand the goal of the issue and how they should best
+approach the problem.
+
+## Helpful Links
+Here you should include a bullet point list of links to documentation, stack overflow,
+whatever, that could help guide someone on what it is they are trying to do.
+Essentially, a list of links to point them in the right direction.
\ No newline at end of file

AUTHORS.rst

+- Tyler Halada
+- Daniel Bond
+- Renfred Harper
+- Ben Waters

CONTRIBUTING.md

+# Contributing to What's Open
+
+We would love for you to contribute to What's Open and help make it even better 
+than it is today! As a contributor, here are the guidelines we would like you to
+follow:
+
+ - [Code of Conduct](#coc)
+ - [Question or Problem?](#question)
+ - [Issues and Bugs](#issue)
+ - [Feature Requests](#feature)
+ - [Submission Guidelines](#submit)
+ - [Coding Rules](#rules)
+ - [Commit Message Guidelines](#commit)
+
+## <a name="coc"></a> Code of Conduct
+
+Help us keep What's Open open and inclusive. Please read and follow the 
+[GMU Student Code of Conduct][coc].
+
+## <a name="question"></a> Got a Question or Problem?
+
+Please, do not open issues for the general support questions as we want to keep 
+GitLab issues for bug reports and feature requests. You've got much better 
+chances of getting your question answered on [Slack Group][slack] where 
+questions should be asked in their respective channels.
+
+## <a name="issue"></a> Found a Bug?
+
+If you find a bug in the source code, you can help us by
+[submitting an issue](#submit-issue) to our [GitLab Repository][gitlab]. Even 
+better, you can [submit a Merge Request](#submit-pr) with a fix.
+
+## <a name="feature"></a> Missing a Feature?
+
+You can *request* a new feature by [submitting an issue](#submit-issue) to our 
+GitLab Repository. If you would like to *implement* a new feature, please ensure
+an issue already exists to be associated with your commits.
+
+* For any **contribution**, first [open an issue](#submit-issue) and outline your proposal so that it can be
+discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
+and help you to craft the change so that it is successfully accepted into the project.
+
+## <a name="submit"></a> Submission Guidelines
+
+### <a name="submit-issue"></a> Submitting an Issue
+
+Before you submit an issue, please search through open issues, maybe an issue for 
+your problem already exists and the discussion might inform you of workarounds 
+readily available.
+
+We want to fix all the issues as soon as possible, but before fixing a bug we 
+need to reproduce and confirm it. In order to reproduce bugs we may 
+ask you to describe a use-case that fails to assist in the debugging process. 
+
+In GitLab there are issue templates that you can use which paste in a sample 
+format for you to use.
+
+Check out the following issue for an example: [https://git.gmu.edu/srct/whats-open/issues/31](https://git.gmu.edu/srct/whats-open/issues/31)
+
+You can file new issues by filling out our [new issue form][new-issue].
+
+### <a name="submit-pr"></a> Steps to contribute and submit a Merge Request (MR)
+
+Before you submit your Merge Request (MR) consider the following steps:
+
+* Search [GitLab][merge-request] for an open or closed MR that relates to your 
+    submission. You don't want to duplicate effort.
+
+* Pull the latest commits from GitLab
+
+    ```sh
+    git pull
+    ```
+
+* Check into the current development branch:
+
+    All new commits are merged into this development branch before going live on
+    the site in a tagged release (merge into master branch). 
+    
+    ```sh
+    git checkout consolidation
+    ```
+
+* Create a new git branch:
+
+    ```sh
+    git checkout -B ##-shortdescription
+    # Example 
+    git checkout -B 31-contibution-guidelines-proposal
+    ```
+
+    All branches need to follow the above convention (`##-shortdescription`) `##` 
+    in this case represents the issue number that your branch is related to. Each
+    issue has one and only one branch and each branch has one and only one purpose:
+    to add, modify, or remove a feature/bug from the repo. `shortdescription` is 
+    a few hyphon (`-`) seperated words that consisely describe the branch. This helps people 
+    who may be unfamiliar with the issue number to know at a glance what the branch
+
+* Now you're ready to write your code in your new branch! Make sure to follow
+    listed [style](#rules) & [commit](#commit) guidelines/rules when contributing 
+    code.
+
+* Unit tests are run at the CI (GitLab-CI) level once you push your code to GitLab.
+    We do this to ensure that the project builds properly and passes tests. In general,
+    if you are adding some new piece of code like a function you must **include 
+    appropriate test cases**. 
+    
+    For example if I compose the following function:
+
+    ```python
+    # file.py
+    def oneplus(num):
+        return num + 1
+    ```
+
+    then I would additionally write the following test case:
+    
+    ```python 
+    # test_file.py
+    def TestOneplus(TestCase):
+        assertEquals(oneplus(1), 2)    
+    ``` 
+* Before you push your code to GitLab it is suggested that you run all unit tests locally.
+    
+    ```sh
+    python manage.py test
+    ```
+
+* Commit your changes using a descriptive commit message that follows our
+    [commit message conventions](#commit). Adherence to these conventions is strongly
+    suggested as it makes it easier to determine what each commit does when, for example,
+    things break.
+
+     ```sh
+     git add --all
+     git commit # first line is title, two newlines is description
+     ```
+
+* You will need to ask in the slack channel to be added to the GitLab repo. This
+    step is necessary such that you have the necessary permissions to push up your
+    branch.
+
+* Push your branch to GitLab:
+
+    ```sh
+    git push origin ##-shortdescription
+    # ex.
+    git push origin 31-contibution-guidelines-proposal
+    ```
+
+* In GitLab, send a merge request to the current development branch.
+
+* If we suggest changes to your branch then:
+  * Make the required updates.
+  * Re-run the unit tests to ensure tests are still passing.
+  * Rebase your branch and force push to your GitLab repository (this will update
+    your Merge Request):
+
+    ```sh
+    git rebase consolidation -i
+    git push -f
+    ```
+
+That's it! Thank you for your contribution! :tada:
+
+#### After your merge request is merged
+
+After your merge request is merged, you can safely delete your branch and merge 
+the changes from the main (upstream) repository:
+
+* Delete the remote branch on GitLab either through the GitLab web UI or your 
+    local shell as follows:
+
+    ```sh
+    git push origin --delete ##-shortdescription
+    # ex.
+    git push origin --delete 31-contibution-guidelines-proposal
+    ```
+
+* Check out the current development branch:
+
+    ```sh
+    git checkout consolidation -f
+    ```
+
+* Delete the local branch:
+
+    ```sh
+    git branch -D ##-shortdescription
+    # ex. 
+    git branch -D 31-contibution-guidelines-proposal
+    ```
+
+* Update your current development branch with the latest upstream version:
+
+    ```sh
+    git l --ff upstream consolidation
+    ```
+
+## <a name="rules"></a> Coding Rules
+
+To ensure consistency throughout the source code, keep these rules in mind as you
+are working:
+
+* All features or bug fixes **must be tested** by one or more specs (unit-tests).
+* We follow [the PEP8 styleguide][style-guide].
+
+## <a name="commit"></a> Commit Message Guidelines
+
+Consistant commit messages are easier to follow when looking through the **project
+history**.
+
+### Commit Message Format
+
+Each commit message consists of a **header**, a **body** and a **footer**.  The 
+header has a special format that includes a **type** and a **subject**. The **header**
+is mandatory.
+
+Layout:
+
+```
+<type>: <subject> # this is the <header>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+Sample headers: 
+
+```
+docs: update change log to beta.5
+```
+```
+fix: need to depend on latest rxjs and zone.js
+```
+
+### \<header> Type
+Must be one of the following:
+
+* **build**: Changes that affect the build system or external dependencies 
+(example scopes: gulp, broccoli, npm)
+* **ci**: Changes to our gitlab-ci configuration files and scripts 
+* **docs**: Documentation only changes
+* **feat**: A new feature
+* **fix**: A bug fix
+* **perf**: A code change that improves performance
+* **refactor**: A code change that neither fixes a bug nor adds a feature
+* **style**: Changes that do not affect the meaning of the code (white-space, formatting,
+ etc.)
+* **test**: Adding missing tests or correcting existing tests
+
+### \<header> Subject
+
+The subject contains succinct description of the change.
+
+Sample Subject:
+
+```
+add in contributing guide
+```
+
+### Body
+
+The body should include a brief description of the changes made in the commit to
+provide additional detail.
+
+Sample Body:
+
+```
+- Introduce my proposal for CONTRIBUTING.md
+- Filled with the whats-open-web contributing guide but contains friendlier language
+```
+
+### Footer
+
+The footer should contain any information about **Breaking Changes** (**Breaking 
+Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
+The rest of the commit message is then used for this. and is also the place to 
+reference GitLab issues that this commit **Closes**.
+
+Sample footers:
+```
+BREAKING CHANGE: remove outdated dependency from requirements.txt. be sure to 
+reinstall your packages in order for the project to build.
+```
+
+```
+Closes #31
+```
+This "Closes" statement should only be incuded in commits that resolve an issue.
+What's nice about the statement itself is that when the commit is merged, the issue
+will auto close.
+
+If neither of these situations are the case (breaking changes or issue closing)
+then feel free to omit the footer.
+
+[coc]: https://studentconduct.gmu.edu/wp-content/uploads/2011/09/2016-17-Code-of-Student-Conduct.pdf
+[gitlab]: https://git.gmu.edu/srct/whats-open
+[style-guide]: https://www.python.org/dev/peps/pep-0008/
+[slack]:https://srct.slack.com/
+[new-issue]:https://git.gmu.edu/srct/whats-open/issues/new
+[merge-request]:https://git.gmu.edu/srct/whats-open/merge_requests

Dockerfile

@@ -2,65 +2,16 @@
 # Dockerfile to build What's Open Django App
 ############################################################
 
-# Instructions:
-#
-# Note: You need to edit the empty string on the line that
-#   says "ENV SECRET_KEY" to be a secure random value.
-#
-# Any initialized data that needs to be imported should be
-#   placed in a directory called "fixtures" in the context
-#   of the build.
-#   (https://docs.djangoproject.com/en/dev/howto/initial-data/)
-#
-# Build Command: sudo docker build -t whats_open .
-# Run Command: sudo docker run -p 8000:80 -i -t -d whats_open
-#
-# (You'll need to reverse proxy port 8000 via nginx)
-
 # Set the base image to Ubuntu
-FROM ubuntu:16.04
-
-# File Author / Maintainer
-MAINTAINER Student-Run Computing and Technology - GMU
+FROM python:3.6
+ENV PYTHONUNBUFFERED 1
 
 # Update the sources list
 RUN apt-get update
+RUN apt-get install netcat -y
 
-# Install basic applications
-RUN apt-get install -y tar git curl nano wget dialog net-tools build-essential
-
-# Install Python and Basic Python Tools
-RUN apt-get install -y python python-dev python-distribute python-pip
-
-# Clone down SRCT-Web
-RUN git clone https://github.com/srct/whats-open.git whats-open
-
-# Get pip to download and install requirements:
-RUN pip install -r /whats-open/requirements.txt
-
-# Set this to a unique, secure value before building
-# (http://www.miniwebtool.com/django-secret-key-generator/)
-ENV SECRET_KEY ""
-
-# Set the default directory where CMD will execute
-WORKDIR /whats-open/whats_open
-
-# Setup database
-RUN python manage.py syncdb --noinput
-RUN python manage.py migrate website --noinput
-
-# Generate static files in the STATIC_ROOT location
-# (https://docs.djangoproject.com/en/dev/howto/static-files/deployment/)
-RUN python manage.py collectstatic --noinput
-
-# Add any inital data fixtures
-# (https://docs.djangoproject.com/en/dev/howto/initial-data/)
-ADD fixtures /whats-open/whats_open/
-# Import the loaded fixtures
-RUN python manage.py loaddata users schedules
-
-# Expose ports
-EXPOSE 80
-
-# Use Gunicorn to server the application
-CMD gunicorn whats_open.wsgi:application -b 0.0.0.0:80
+RUN mkdir /whats_open
+WORKDIR /whats_open
+ADD /requirements/ /whats_open/
+RUN pip install -r base.txt
+ADD . /whats_open/

README.md

-What's Open
-===
+# What's Open
 
-Simple Django site displaying which dining locations are currently open on 
-George Mason University's campus.
+[![build status](https://git.gmu.edu/srct/whats-open/badges/master/build.svg)](https://git.gmu.edu/srct/whats-open/commits/master) [![coverage report](https://git.gmu.edu/srct/whats-open/badges/master/coverage.svg)](https://git.gmu.edu/srct/whats-open/commits/master) [![python version](https://img.shields.io/badge/python-2.7-blue.svg)]() [![Django version](https://img.shields.io/badge/Django-1.10-brightgreen.svg)]()
 
-For more up-to-date information, view the [What's Open 
-wiki page](http://wiki.srct.gmu.edu/wiki/index.php/Whatsopen).
+The What's Open project is an initiative at George Mason University by Mason
+Student Run Computing and Technology (SRCT) to display which dining locations
+are currently open on George Mason University's campus.
 
-Contributing
----
-UPDATE:
-
-Please join the #whats-open channel at srct.slack.com in order to chat with project
-members about how to contribute. There are pinned posts in the sidebar of that channel
-containing step by step instructions about how to get setup in addition to info about 
-branches and the direction of the project.
-
-Thanks!
-
-
-OUTDATED:
+This repo is a simple Django Rest Framework (DRF) project that contains the
+database backend and API for SRCT developed What's Open applications. 
 
 What's Open needs all the help it can get. Even if you don't feel 
 like you can be helpful with the heavily technical aspects, 
 we definitely need designers and technical writers.
  
-There are many things that can be done with this project (see the "To Do" 
+There are many things that can be done with this project (see the project [Issues](https://git.gmu.edu/srct/whats-open/issues) 
 section), but sometimes it's the small things that count, so don't be afraid of 
 contributing just for a spelling mistake.
 
-If you need help at all please contact any SRCT member. We want people to
-contribute, so if you are struggling, or just want to learn, then we are willing
-to help.
-
-Set Up
----
-
-To get started, you'll need the following installed:
-
-* [Python 2.7](http://www.python.org/download/)
-* [Django 1.5 or later](https://www.djangoproject.com/download/)
-* [Git](http://git-scm.com/book/en/Getting-Started-Installing-Git)
-* [virtualenv](http://www.virtualenv.org/en/latest/index.html#installation) 
-  (to install you will need either 
-  [pip](http://www.pip-installer.org/en/latest/installing.html) or
-  [easy_install](http://pythonhosted.org/distribute/easy_install.html))
-
-Then type the following commands in your terminal (if you're on Windows, 
-[Cygwin](http://www.cygwin.com/) is recommended).
-
-```bash
-git clone http://git.gmu.edu/srct/whats-open.git
-cd whats-open/
-virtualenv venv --distribute
-source venv/bin/activate
-pip install -r requirements.txt
-python manage.py syncdb
-python manage.py migrate website
+If you need help at all please contact any SRCT member in the `#whats-open` 
+channel in our [slack group](https://srct.slack.com). We want people to 
+contribute, so if you are struggling, or just want to learn, then we are 
+willing to help.
+
+Check out some of the other What's Open projects!
+ - [https://git.gmu.edu/srct/whats-open-android]()
+ - [https://git.gmu.edu/srct/whats-open-ios]()
+ - [https://git.gmu.edu/srct/whats-open-web]()
+ - [https://git.gmu.edu/srct/whats-open-alexa]()
+
+# Setup instructions for local development
+
+What's Open currently supports developers on Linux and macOS systems. Here's our 
+walk-through of steps we will take:
+
+1. Install `git` on your system.
+2. Clone the whats-open codebase.
+3. Get whats-open up and running with the method of your choice.
+
+## 1) Install `git` on your system.
+
+`git` is the version control system used for SRCT projects.
+
+### On Linux Based Systems
+
+**with apt:**
+
+Open a terminal and run the following command:
+
+    sudo apt update
+
+This retrieves links to the most up-to-date and secure versions of your packages.
+
+Next, with:
+
+    sudo apt install git
+
+you install `git` onto your system.
+
+**with pacman:**
+  
+    pacman -S git
+
+### On macOS
+
+We recommend that you use the third party Homebrew package manager for macOS,
+which allows you to install packages from your terminal just as easily as you
+could on a Linux based system. You could use another package manager (or not
+use one at all), but Homebrew is highly reccomended.
+
+To get homebrew, run the following command in a terminal:
+
+    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)
+
+**Note**: You do NOT need to use `sudo` when running any Homebrew commands, and
+it likely won't work if you do.
+
+Next, to make sure Homebrew is up to date, run:
+
+    brew update
+
+Finally we can install git with:
+
+    brew install git
+
+## 2) Clone the whats-open codebase
+
+Now, we're going to clone down a copy of the whats-open codebase from [git.gmu.edu](http://git.gmu.edu/srct/whats-open),
+the SRCT code respository with SSH.
+
+**a)** Configure your ssh keys by following the directions at:
+
+[git.gmu.edu/help/ssh/README](http://git.gmu.edu/help/ssh/README).
+
+**b)** Now, on your computer, navigate to the directory in which you want to download the project (ie. perhaps one called `development/SRCT`), and run
+
+    git clone git@git.gmu.edu:srct/whats-open.git
+
+## 3) Get whats-open up and running
+
+Now that we have `git` setup and cloned down the code you can
+
+    cd whats-open/
+
+and get to working on setting up a development environment! There are two options
+to go about doing this: `Docker` and `Manual Setup`.
+
+### Docker
+
+We can automate the setup process through [Docker](https://www.docker.com/what-docker)
+containers! This allows us to quickly get started and standardize development
+environments across machines.
+
+Installing Docker on your system:
+
+ - For macOS: [https://docs.docker.com/docker-for-mac/]()
+ - For Windows: [https://docs.docker.com/docker-for-windows/]()
+ - For your specific *nix distro: [https://docs.docker.com/engine/installation/]() 
+
+Additionally, you will need to install docker-compose: [https://docs.docker.com/compose/install/]()
+
+Next inside the `whats-open/` root directory run:
+
+    docker-compose build
+
+If that doesn't work, try:
+
+    sudo docker-compose build
+