Merge branch '2.2-dev' into 'master'

2.2

Closes #97, #91, #92, #90, #88, #99, #100, #78, #75, and #77

See merge request !50

.gitignore

@@ -13,5 +13,4 @@ whats_open/secret_key.py
 whats_open/assets/
 static/admin/
 data
-whats-open/api/migrations
 .vscode

.gitlab-ci.yml

 services:
-  - mysql:latest
+  - mysql:5.7
 
 variables:
   MYSQL_DATABASE: wopen
@@ -10,10 +10,13 @@ types:
 
 before_script:
   - apt-get update -qy
-  - apt-get install -y mysql-client libmysqlclient-dev python-mysqldb libgdal1h libproj-dev proj-data proj-bin
-  - pip install -r requirements/test.txt
+  - apt-get install -y mysql-client default-libmysqlclient-dev python-mysqldb
+    gdal-bin libproj-dev proj-data proj-bin binutils
   - 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)
+  - pip install pipenv
+  - pipenv install --system --deploy
+  - 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"
@@ -21,21 +24,16 @@ before_script:
   - export WOPEN_DB_HOST="mysql"
   - export WOPEN_DB_PORT=3306
   - export WOPEN_SUPERUSER=admin
+  - export WOPEN_ENV=dev
   - python manage.py makemigrations
   - python manage.py makemigrations api
   - 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
+  - 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-py3.5:
-  image: library/python:3.5
+whats-open-py3.7:
+  image: library/python:3.7
   type: test
   script:
-    - python manage.py test
-
-whats-open-py3.6:
-  image: library/python:3.6
-  type: test
-  script:
-    # - if pip list --outdated --format=legacy | grep "Latest" | wc -l > 0; then echo "Please update your dependecies!" && pip list --outdated --format=legacy && exit 1; else exit 0; fi
-    - coverage run --source=api --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;}'
+    - echo "Done 😄"

CHANGELOG.md

@@ -5,6 +5,30 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
 and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
 
+## [2.2] - 2019-01-29
+
+## Fixed
+
+- Default owner now assigned automatically to the current logged in user / field hidden
+- Path buggy schedule checking timezone utilization
+- Schedules may now have N open times
+
+## Added
+
+- Admin action to bulk apply schedules to facilities
+- Changed default image
+- Alert model refactored to support URLs, subjects, and bodies
+- Add front royal location as an option
+
+## Removed
+
+- Mason Korea support dropped
+- Deprecated previous Alert model
+- Drop label support
+- Drop Sodoxo classifier
+- Drop schedule promotion
+- Drop schedule deletion
+
 ## [2.1.1] - 2017-01-13
 
 ## Fixed
@@ -31,4 +55,4 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 - Special Schedules can start at a specific time on a date
 
 [2.1.0]: https://git.gmu.edu/srct/whats-open/compare/2.0...2.1
-[2.1.1]: https://git.gmu.edu/srct/whats-open/compare/2.1...2.1.1
\ No newline at end of file
+[2.1.1]: https://git.gmu.edu/srct/whats-open/compare/2.1...2.1.1

CONTRIBUTING.md

 # Contributing to What's Open
 
-We would love for you to contribute to What's Open and help make it even better 
+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)
+- [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 
+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 
+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 
+[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
+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.
+- 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 
+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. 
+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 
+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)
@@ -63,97 +63,99 @@ You can file new issues by filling out our [new issue form][new-issue].
 
 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.
+- 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
+- Pull the latest commits from GitLab
 
-    ```sh
-    git pull
-    ```
+  ```sh
+  git pull
+  ```
 
-* Check into the current development branch:
+- 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
-    ```
+  All new commits are merged into this development branch before going live on
+  the site in a tagged release (merge into master branch).
 
-* Create a new git branch:
+  ```sh
+  git checkout consolidation
+  ```
 
-    ```sh
-    git checkout -B ##-shortdescription
-    # Example 
-    git checkout -B 31-contibution-guidelines-proposal
-    ```
+- Create a new git branch:
 
-    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
-    ```
+  ```sh
+  git checkout -B ##-shortdescription
+  # Example
+  git checkout -B 31-contibution-guidelines-proposal
+  ```
 
-    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
-    ```
+  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
 
-* 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.
+- 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.
 
-     ```sh
-     git add --all
-     git commit # first line is title, two newlines is description
-     ```
+- 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**.
 
-* 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.
+  For example if I compose the following function:
 
-* Push your branch to GitLab:
+  ```python
+  # file.py
+  def oneplus(num):
+      return num + 1
+  ```
 
-    ```sh
-    git push origin ##-shortdescription
-    # ex.
-    git push origin 31-contibution-guidelines-proposal
-    ```
+  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
+  ```
 
-* In GitLab, send a merge request to the current development branch.
+- 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.
 
-* 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
+- 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
@@ -165,45 +167,45 @@ 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 
+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:
+- 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
-    ```
+  ```sh
+  git push origin --delete ##-shortdescription
+  # ex.
+  git push origin --delete 31-contibution-guidelines-proposal
+  ```
 
-* Check out the current development branch:
+- Check out the current development branch:
 
-    ```sh
-    git checkout consolidation -f
-    ```
+  ```sh
+  git checkout consolidation -f
+  ```
 
-* Delete the local branch:
+- Delete the local branch:
 
-    ```sh
-    git branch -D ##-shortdescription
-    # ex. 
-    git branch -D 31-contibution-guidelines-proposal
-    ```
+  ```sh
+  git branch -D ##-shortdescription
+  # ex.
+  git branch -D 31-contibution-guidelines-proposal
+  ```
 
-* Update your current development branch with the latest upstream version:
+- Update your current development branch with the latest upstream version:
 
-    ```sh
-    git l --ff upstream consolidation
-    ```
+  ```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].
+- 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
 
@@ -212,7 +214,7 @@ history**.
 
 ### Commit Message Format
 
-Each commit message consists of a **header**, a **body** and a **footer**.  The 
+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.
 
@@ -226,29 +228,31 @@ Layout:
 <footer>
 ```
 
-Sample headers: 
+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
+- **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
 
@@ -274,20 +278,22 @@ Sample Body:
 
 ### Footer
 
-The footer should contain any information about **Breaking Changes** (**Breaking 
+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 
+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 
+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.
@@ -298,6 +304,6 @@ 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
+[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

@@ -3,12 +3,19 @@
 ############################################################
 
 # Set the base image to Ubuntu
-FROM python:3.6
+FROM python:3.7
 ENV PYTHONUNBUFFERED 1
 
-# Update the sources list
-RUN apt-get update
-RUN apt-get install netcat libgdal1h libproj-dev proj-data proj-bin -y
+# Update the sources list and install all packages
+# See: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#run
+RUN apt-get update && apt-get install -y \
+    netcat \
+    libproj-dev \
+    proj-data \
+    proj-bin \
+    binutils \ 
+    gdal-bin \ 
+    && rm -rf /var/lib/apt/lists/*
 
 # Copy over all project files into /whats_open
 RUN mkdir /whats-open/
@@ -16,4 +23,5 @@ WORKDIR /whats-open/
 ADD . /whats-open/
 
 # Pip install all required dependecies
-RUN pip install -r /whats-open/requirements/base.txt
+RUN pip install pipenv
+RUN pipenv install --system --deploy
\ No newline at end of file

LICENSE

@@ -186,7 +186,7 @@ Apache License
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2017 George Mason University Student-Run Computing and Technology
+   Copyright 2018 George Mason University Student-Run Computing and Technology
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

Pipfile

+[[source]]
+name = "pypi"
+url = "https://pypi.org/simple"
+verify_ssl = true
+
+[dev-packages]
+black = "*"
+pylint = "*"
+pylint-django = "*"
+
+[packages]
+django-autoslug-iplweb = "*"
+django-cas-client = "==1.3.0"
+djangorestframework = "==3.7.7"
+django-model-utils = "==3.0.0"
+mysqlclient = "==1.3.12"
+django-taggit = "==0.22.2"
+django-taggit-serializer = "==0.1.5"
+djangorestframework-gis = "==0.12.0"
+django-filter = "==1.0.4"
+django-crispy-forms = "==1.7.0"
+coreapi = "==2.3.3"
+urllib3 = "==1.22"
+docutils = "==0.13.1"
+gunicorn = "*"
+Django = "<2.1,>=2.0"
+Markdown = "==2.6.10"
+
+[requires]
+python_version = "3.7"
+
+[pipenv]
+allow_prereleases = true

Pipfile.lock

+{
+    "_meta": {
+        "hash": {
+            "sha256": "465820099b95b54e0ceaa9975f59da0a88605cb2dc3edb3630d513d8afb550ba"
+        },
+        "pipfile-spec": 6,
+        "requires": {
+            "python_version": "3.7"
+        },
+        "sources": [
+            {
+                "name": "pypi",
+                "url": "https://pypi.org/simple",
+                "verify_ssl": true
+            }
+        ]
+    },
+    "default": {
+        "certifi": {
+            "hashes": [
+                "sha256:47f9c83ef4c0c621eaef743f133f09fa8a74a9b75f037e8624f83bd1b6626cb7",
+                "sha256:993f830721089fef441cdfeb4b2c8c9df86f0c63239f06bd025a76a7daddb033"
+            ],
+            "version": "==2018.11.29"
+        },
+        "chardet": {
+            "hashes": [
+                "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae",
+                "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691"
+            ],
+            "version": "==3.0.4"
+        },
+        "coreapi": {
+            "hashes": [
+                "sha256:46145fcc1f7017c076a2ef684969b641d18a2991051fddec9458ad3f78ffc1cb",
+                "sha256:bf39d118d6d3e171f10df9ede5666f63ad80bba9a29a8ec17726a66cf52ee6f3"
+            ],
+            "index": "pypi",
+            "version": "==2.3.3"
+        },
+        "coreschema": {
+            "hashes": [
+                "sha256:5e6ef7bf38c1525d5e55a895934ab4273548629f16aed5c0a6caa74ebf45551f",
+                "sha256:9503506007d482ab0867ba14724b93c18a33b22b6d19fb419ef2d239dd4a1607"
+            ],
+            "version": "==0.0.4"
+        },
+        "django": {
+            "hashes": [
+                "sha256:0292a7ad7d8ffc9cfc6a77f043d2e81f5bbc360c0c4a1686e130ef3432437d23",
+                "sha256:e89f613e3c1f7ff245ffee3560472f9fa9c07060b11f65e1de3cb763f8dcd4b9"
+            ],
+            "index": "pypi",