Skip to content

GitLab

Commit be8d80f4 authored by David Haynes's avatar David Haynes 🙆
Browse files

Merge branch '2.2-dev' into 'master' 

2.2

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

See merge request srct/whats-open!50
parents ec5b0b71 06ec7ed1
Pipeline #3761 passed with stage
in 1 minute and 6 seconds
Hide whitespace changes
Inline Side-by-side
.gitignore
View file @ be8d80f4
......@@ -13,5 +13,4 @@ whats_open/secret_key.py
whats_open/assets/
static/admin/
data
whats-open/api/migrations
.vscode
.gitlab-ci.yml
View file @ be8d80f4
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
View file @ be8d80f4
......@@ -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
View file @ be8d80f4
# 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
View file @ be8d80f4
......@@ -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
View file @ be8d80f4
......@@ -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 0 → 100644
View file @ be8d80f4
[[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 0 → 100644
View file @ be8d80f4
{
"_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",
"version": "==2.0.10"
},
"django-autoslug-iplweb": {
"hashes": [