Merge pull request #94 from pretendWhale/2.0.7

Update for v2.0.7

.git-blame-ignore-revs

@@ -0,0 +1,2 @@
+# Initial pre-commit hooks, markdownlint
+dc5879c9500befb7f97b588d23f1086f15c8fcf2

.gitignore

@@ -1 +1 @@
-*.db
+*.db

.markdownlint.yml

@@ -0,0 +1,37 @@
+default: true
+
+# MD004/ul-style - Unordered list style
+MD004:
+  # List style
+  style: "dash"
+
+# MD007/ul-indent - Unordered list indentation
+MD007:
+  # Spaces for indent
+  indent: 4
+
+# MD013/line-length - Line length
+MD013: false
+
+# MD024/no-duplicate-heading/no-duplicate-header - Multiple headings with the same content
+MD024:
+  # Only check sibling headings
+  siblings_only: true
+
+# MD028/no-blanks-blockquote - Blank line inside blockquote
+MD028: false
+
+# MD046/code-block-style - Code block style
+MD046:
+  # Block style
+  style: "fenced"
+
+# MD049/emphasis-style - Emphasis style should be consistent
+MD049:
+  # Emphasis style should be consistent
+  style: "asterisk"
+
+# MD050/strong-style - Strong style should be consistent
+MD050:
+  # Strong style should be consistent
+  style: "asterisk"

.pre-commit-config.yaml

@@ -0,0 +1,14 @@
+repos:
+  -   repo: https://github.com/pre-commit/pre-commit-hooks
+      rev: v4.1.0
+      hooks:
+        -   id: end-of-file-fixer
+        -   id: trailing-whitespace
+  -   repo: https://github.com/igorshubovych/markdownlint-cli
+      rev: v0.31.1
+      hooks:
+        -   id: markdownlint
+            args: ["--fix"]
+
+ci:
+  autoupdate_schedule: monthly

About.md

@@ -1,4 +1,4 @@
-## About MarkUs
+# About MarkUs
 
 MarkUs is a web application for the submission and grading of student programming assignments. The primary purpose of MarkUs is to provide TAs with simple tools that will help them to give high quality feedback to students. MarkUs also provides a straight-forward interface for students to submit their work, form groups, and receive feedback. The administrative interface allows instructors to manage groups, organize the grading, and release grades to students.
 

Configuration.md

@@ -1,12 +1,9 @@
 # Configuration Settings
 
-_new in version 1.12.0_
-
-Custom configuration settings for MarkUs can be set by adding a `config/settings.local.yml` file.
+*new in version 1.12.0*: Custom configuration settings for MarkUs can be set by adding a `config/settings.local.yml` file.
 Values in this file are described below and will override any default values in the `config/settings.yml` or the environment specific files in `config/settings`.
 
-
-#### Default Values
+## Default Values
 
 To show the default values for your environment, run the following command in the root directory of the installed MarkUs instance:
 
@@ -16,9 +13,9 @@ echo 'puts JSON.parse(Settings.to_json).to_yaml' | NO_SCHEMA_VALIDATE=1 bundle e
 
 By specifying `NO_SCHEMA_VALIDATE` an error will not be raised if a required key is missing.
 
-#### Settings
+## Settings
 
-##### Rails Specific Settings
+### Rails Specific Settings
 
 All values under the `rails:` key are used to set the `Rails.configuration` object when the app starts.
 
@@ -61,7 +58,7 @@ rails:
      perform_caching: # boolean indicating whether to enable fragment caching (enable this for production only)
 ```
 
-##### MarkUs settings
+### MarkUs settings
 
 ```yaml
 queues:
@@ -113,7 +110,7 @@ python:
 pandoc: # path to the pandoc executable
 ```
 
-#### Additional queue names
+## Additional queue names
 
 By default, background jobs will be run using the queue specified by the
 
@@ -135,14 +132,13 @@ queue:
 
 Will run all background jobs using a queue named "default" except for `AutotestSpectsJob` which will use a queue named "specs_queue" and `SplitPdfJob` which will use a queue named "some_other_one".
 
-
-#### Student Tests
+## Student Tests
 
 Students are only allowed to run one test at a time. This means that a student must wait until the results from a previous test have returned before they can run another one. If a test result never returns (because of an unexpected error) a student will instead have to wait `student_test_buffer_minutes` before they can run a new test.
 
-#### User Authentication Options
+## User Authentication Options
 
-When a user logs in to MarkUs they can be authenticated in one of two ways: 
+When a user logs in to MarkUs they can be authenticated in one of two ways:
 
 1. Local authentication: their username, password, and (optionally) their IP address are sent to the stdin pipe of a script file on disk. If that script exits with a 0, the user is authenticated.
 2. Remote authentication: some other service (such as a Single Sign-on provider) authenticates the user's user name and password for MarkUs. If the user is authenticated by this service, the user's user name should be sent in the request header as the value of the "HTTP_X_FORWARDED_USER" key (see Installation instructions for more details).
@@ -178,15 +174,15 @@ validate_custom_status_message:
 local_auth_login_name: shibboleth
 ```
 
-**Logout redirect**
+### Logout redirect
 
-The `logout_redirect` setting determines where the user will be redirected when they logout of MarkUs. It can be one of `DEFAULT`, `NONE`, or a URL. 
+The `logout_redirect` setting determines where the user will be redirected when they logout of MarkUs. It can be one of `DEFAULT`, `NONE`, or a URL.
 
 - `DEFAULT`: the user will be redirected to MarkUs' login page
 - `NONE`: MarkUs will render a 404 error page
 - URL: MarkUs will redirect the user to this URL
 
-#### Environment variables
+## Environment variables
 
 All of the settings described above can also be set using environment variables. Environment variables start with `MARKUS__` followed by each nested yaml key separated by `__`. For example,
 

Developer-Guide--Action-Policy-Style-Guide.md

@@ -20,21 +20,19 @@ Rspec tests can be found under: `spec/policies`
 
 ## Guidelines for writing policies
 
-#### All controller routes must have a corresponding policy
+### All controller routes must have a corresponding policy
 
 If you create or rename a route, you *must* create or rename the corresponding policy. In the `ApplicationController` class there is the [`verify_authorized`](https://actionpolicy.evilmartians.io/#/rails?id=verify_authorized-hooks) hook which will raise an error if a user tries to access a route and a policy is not checked.
 
-
-#### Controllers must all have an implicit_authorization_target
+### Controllers must all have an implicit_authorization_target
 
 MarkUs tries to use [resourceless authorization](https://actionpolicy.evilmartians.io/#/rails?id=resource-less-authorize) whenever possible. This means that every time ActionPolicy authorizes a route, we do not need to specify which policy it needs to use.
 
 Instead, we can define an [`implicit_authorization_target`](https://actionpolicy.evilmartians.io/#/behaviour?id=implicit-authorization-target) method for each controller.
 
 By default, controllers will inherit this method from `ApplicationController` but in some cases it may be necessary to override this method for a subclass. For example, if a controller does not have a corresponding model, the default `implicit_authorization_target` will need to be overwritten since it assumes the existance of that model.
 
-
-#### Policy names should reflect their purpose
+### Policy names should reflect their purpose
 
 Policy classes should be named the same as the corresponding controller, except the policy class name should be singular (not plural) and "Controller" should be replaced with "Policy".
 
@@ -58,18 +56,15 @@ For example, a policy that checks whether a student is allowed to work alone in
 
 "Is this user allowed to \_\_\_\_\_\_?"
 
-
-#### All policy functions must have a failure reason
+### All policy functions must have a failure reason
 
 If you create or rename a policy function, make sure to create or update the internationalization strings for that policy function (in `config/locales/policies`)
 
-
-#### Use `allowed_to?` and `check?` in different contexts
+### Use `allowed_to?` and `check?` in different contexts
 
 The `allowed_to?` function has an alias `check?`. However, to improve clarity of code, `check?` should be only used in policy classes and `allowed_to?` should only be used outside of policy classes (in controllers or views).
 
-
-#### Be purposeful about calling `check?`
+### Be purposeful about calling `check?`
 
 When a policy fails (returns false), the [failure reasons](https://actionpolicy.evilmartians.io/#/reasons?id=failure-reasons) are collected in the policy's `result` attribute.
 
@@ -119,7 +114,6 @@ end
 
 If the `index?` policy fails the error messages will be: `["You don't have access to the index route."]` because only the `index?` policy is called.
 
-
 Note that failure reasons will only be added if `check?` or `allowed_to?` is called in the original policy class. For example:
 
 ```ruby
@@ -139,10 +133,10 @@ class OtherPolicy < ApplicationPolicy
     end
 end
 ```
-If the `index?` policy fails, the error messages will be: `["You don't have access to the index route.", "You are still not an instructor user"]`. It will not include `"You are not a TA or a student"` because the `check?` function was called in a policy class different to the one that `index?` is in.
 
+If the `index?` policy fails, the error messages will be: `["You don't have access to the index route.", "You are still not an instructor user"]`. It will not include `"You are not a TA or a student"` because the `check?` function was called in a policy class different to the one that `index?` is in.
 
-#### Include additional context for policies if needed
+### Include additional context for policies if needed
 
 If a policy requires additional context that can be provided using [explicit additional context](https://actionpolicy.evilmartians.io/#/authorization_context?id=explicit-context).
 
@@ -164,13 +158,12 @@ In the example above, the `index?` policy needs to check a submission object. Th
 allowed_to?(:index?, context: { submission: Submission.find(10) })
 ```
 
-#### Writing Tests
+### Writing Tests
 
 Rspec tests written for policies should use [Action Policies' Rspec DSL](https://actionpolicy.evilmartians.io/#/testing?id=rspec-dsl).
 
 For clarity, we prefer to not nest `succeed` or `failed` blocks within each other. For example, the following two test classes are functionally equivalent but the second one is preferred:
 
-
 ```ruby
 describe NotePolicy do
     let(:context) { { user: user } }

Developer-Guide--Guidelines.md

@@ -18,18 +18,18 @@ When developing MarkUs, make sure to follow the following steps (where appropria
 
 ### DOs
 
--  **Do** use Rails tools (such as [generators](http://wiki.rubyonrails.org/rails/pages/AvailableGenerators)) when appropriate in order to have code-stubs generated and for [migrations](http://guides.rubyonrails.org/migrations.html)
--  **Do** use the [debugger](http://guides.rubyonrails.org/debugging_rails_applications.html).
--  **Do** document your code appropriately. Add or update method-level and class-level docstrings as required. You can assume that the reader is familiar with Ruby and Rails. If your code requires more extensive documentation, you may wish to add or update a Wiki page. Remember, once you are done with your work and you leave the project, new developers should be able to use what you have contributed without a lot of effort.
--  **Do** ask for help. Ask questions commenting on your pull requests, emailing or in talking to the maintainers in person (if you can). But don't wait until the project is almost finished; problems can often be resolved quickly by sharing your code and asking questions.
--  **Do** write tests! (see the [guides](#guides) for testing guides)
+- **Do** use Rails tools (such as [generators](http://wiki.rubyonrails.org/rails/pages/AvailableGenerators)) when appropriate in order to have code-stubs generated and for [migrations](http://guides.rubyonrails.org/migrations.html)
+- **Do** use the [debugger](http://guides.rubyonrails.org/debugging_rails_applications.html).
+- **Do** document your code appropriately. Add or update method-level and class-level docstrings as required. You can assume that the reader is familiar with Ruby and Rails. If your code requires more extensive documentation, you may wish to add or update a Wiki page. Remember, once you are done with your work and you leave the project, new developers should be able to use what you have contributed without a lot of effort.
+- **Do** ask for help. Ask questions commenting on your pull requests, emailing or in talking to the maintainers in person (if you can). But don't wait until the project is almost finished; problems can often be resolved quickly by sharing your code and asking questions.
+- **Do** write tests! (see the [guides](#guides) for testing guides)
 
 ### DON'Ts
 
-1.  **Don't** mark your pull request as "Ready for review" until you're entirely happy with it. Go, have a break and come back to your code after a while. Questions you should ask yourself are: Is my controller code really controller code, or should it be moved to a model? Is there a simpler solution? Can Rails help with what I am trying to achieve?
-2.  **Don't** mull over problems alone for hours/days. Sometimes it's better to consult somebody else: two pairs of eyes see more than one. Maybe somebody else has had a similar problem, etc. Go ask questions!
-3.  **Don't** fight Rails (it'll beat you). Sometimes Rails' "magic" is irritating. However, you are better off *using* rather then fighting it!
-4.  **Don't** use absolute paths/url's in any code (use `url_for` instead). *Always* let Rails generate URLs. You have to assume that there are more than one MarkUs applications running on a server, once deployed. Rails does a really good job on this, so use it.
+1. **Don't** mark your pull request as "Ready for review" until you're entirely happy with it. Go, have a break and come back to your code after a while. Questions you should ask yourself are: Is my controller code really controller code, or should it be moved to a model? Is there a simpler solution? Can Rails help with what I am trying to achieve?
+2. **Don't** mull over problems alone for hours/days. Sometimes it's better to consult somebody else: two pairs of eyes see more than one. Maybe somebody else has had a similar problem, etc. Go ask questions!
+3. **Don't** fight Rails (it'll beat you). Sometimes Rails' "magic" is irritating. However, you are better off *using* rather then fighting it!
+4. **Don't** use absolute paths/url's in any code (use `url_for` instead). *Always* let Rails generate URLs. You have to assume that there are more than one MarkUs applications running on a server, once deployed. Rails does a really good job on this, so use it.
 
 ## Code Styleguide
 
@@ -40,14 +40,14 @@ When developing MarkUs, make sure to follow the following steps (where appropria
 
 Rails:
 
-- http://guides.rubyonrails.org/
-- http://www.caliban.org/ruby/rubyguide.shtml
+- <http://guides.rubyonrails.org/>
+- <http://www.caliban.org/ruby/rubyguide.shtml>
 
 Rspec:
 
-- https://www.rubyguides.com/2018/07/rspec-tutorial/
-- https://www.betterspecs.org/
+- <https://www.rubyguides.com/2018/07/rspec-tutorial/>
+- <https://www.betterspecs.org/>
 
 Action Policy:
 
-- https://actionpolicy.evilmartians.io
+- <https://actionpolicy.evilmartians.io>

Developer-Guide--Release-Instructions.md

@@ -1,14 +1,16 @@
 # Release Instructions
 
-#### When reviewing a pull request (PR):
-* decide whether the changes made PR should be released with the next *minor* or *major* version (see below)
-* if a PR should be released with the next major version no additional steps need to be taken. However, please ensure that the PR targets the `master` branch.
-* if a PR should be released with the next minor version:
-    * make sure the current PR targets the `master` branch.
-    * make an identical (or as close as possible) PR that also target the release candidate branch for the upcoming release.
-    * add the PR that targets the release candidate branch to the milestone for the upcoming release.
-
-#### When making a major release:
+## When reviewing a pull request (PR)
+
+- decide whether the changes made PR should be released with the next *minor* or *major* version (see below)
+- if a PR should be released with the next major version no additional steps need to be taken. However, please ensure that the PR targets the `master` branch.
+- if a PR should be released with the next minor version:
+    - make sure the current PR targets the `master` branch.
+    - make an identical (or as close as possible) PR that also target the release candidate branch for the upcoming release.
+    - add the PR that targets the release candidate branch to the milestone for the upcoming release.
+
+## When making a major release
+
 1. merge the `master` branch into the `release` branch and resolve all conflicts.
 2. update the Changelog.md files in both the `release` and `master` branches by replacing the `[unreleased]` section with the new release's version number.
 3. fully test the `release` branch in development.
@@ -17,11 +19,13 @@
 6. deploy the new release to a test instance on a production server and test the instance there as well.
 7. un-mark the new release as a pre-release
 
-#### When making a minor release:
+## When making a minor release
+
 1. merge the current release candidate branch into the `release` branch (there should be no conflicts).
 2. update the Changelog.md file in the both the `release` and `master` branches by creating a new section for the new release and moving all relevant lines from the `[unreleased]` section to this new section.
 3. do steps 3-7 from the [major release](#when-making-a-major-release) section above
 
-#### After making any release:
+## After making any release
+
 1. close any existing milestones and create a new milestone for the next minor release. For example, if you just released version 1.9.5, make a new milestone named `v1.9.6`.
 2. delete the old release candidate branch (if it exists) and create a new release candidate branch based off of the current `release` branch. For example, if you just released version 1.9.5, delete the branch named `v1.9.5.rc` and create a branch named `v1.9.6.rc`