oAuth2

We should have an automated release process. It should handle all the steps until we get to a PR for the release branch. From there, users will review and test as necessary. When that PR is merged, the build happens without further intervention.

.. that initially implements the specs described here http://docs.ccxcon.apiary.io/

Provide a mechanism for server to server authentication.

We need a way to notify teacher's portal that things exist.

At minimum, we need the ability to get the uuid and title, plus the same for all submodules.

This should probably use some known header that we could verify on the teacher's portal side, so theoretically multiple consumers could take that incoming webhook.

They break on the dredd step. Not sure why. Happy to help someone debug, but I don't have a mac. If you want to pair on it, let me know.

We currently only have support for fetching individual records or all the records. We should have a filtering mechanism in place, which will be used by TP to get a list of courses to display that are purchasable.

Steps:

• Fresh install of ccxcon from master.
• Create superuser at commandline (got the error there too, but it worked)
• Log into admin
• Add user (form loads properly)
• Fill out form and click save.

See error below.

ProgrammingError at /admin/auth/user/add/
relation "courses_userinfo" does not exist
LINE 1: INSERT INTO "courses_userinfo" ("user_id", "edx_instance") V...
                    ^
Request Method: POST
Request URL:    https://192.168.99.101:8077/admin/auth/user/add/
Django Version: 1.9
Exception Type: ProgrammingError
Exception Value:    
relation "courses_userinfo" does not exist
LINE 1: INSERT INTO "courses_userinfo" ("user_id", "edx_instance") V...
                    ^
Exception Location: /usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py in execute, line 64
Python Executable:  /usr/bin/python
Python Version: 2.7.6
Python Path:    
['/src',
 '/usr/lib/python2.7',
 '/usr/lib/python2.7/plat-x86_64-linux-gnu',
 '/usr/lib/python2.7/lib-tk',
 '/usr/lib/python2.7/lib-old',
 '/usr/lib/python2.7/lib-dynload',
 '/usr/local/lib/python2.7/dist-packages',
 '/usr/local/lib/python2.7/dist-packages/newrelic-2.54.0.41',
 '/usr/lib/python2.7/dist-packages',
 '/src']
Server time:    Fri, 11 Dec 2015 19:45:21 +0000

This way, @giocalitri doesn't need to figure out how to get access to the edx instances from edx instances themselves. We'll already know who they are anyway.

modues should be modules at https://github.com/mitodl/ccxcon/blob/master/apiary.apib#L283

Use Saif's 8.05x course

Should also host that image on s3 or similar.

so we can create them in prod.

This will be used for user validation as part of mitodl/teachersportal#26

Subtask of #10 .

This would provide a way to run the tests, pylint and pep8 checks locally at the same time. In LORE we use pytest-pylint and pytest-pep8 for this.

Modules appear to be ordered on the course detail page, so the API should support ordering thereof.

based on LORE docs

We should have an endpoint to create ccx's which is proxied back to edx. See Giovanni's PR at mitocw/edx-platform#145

There are two places where a version is stated: ccxcon/settings.py and setup.py. We can store the version in a VERSION file and have that be the source of truth for the version, as a simple solution.

This also has the benefit of making updating the version as trivial as it can be with a release script (echo "$major.$minor.$patch" > VERSION)

But also, is there a reason we should keep setup.py? I'm cool with having it even just for onlookers who want to see some useful metadata, but I'm not sure if people will want to run CCXCon by installing it into a python environment (always possible, though). Thoughts?

We should consider disabling PATCH/PUT/DELETE on courses and also POST for modules, if no client has a reasonable use for them, so we don't have to worry about handling those cases.

Subtask of #10 .

I'm getting these messages when running docker-compose up:

WARNING: There is a boolean value in the 'environment' key.
Environment variables can only be strings.
Please add quotes to any boolean values to make them string (eg, 'True', 'yes', 'N').
This warning will become an error in a future release. 

WARNING: There is a boolean value in the 'environment' key.
Environment variables can only be strings.
Please add quotes to any boolean values to make them string (eg, 'True', 'yes', 'N').
This warning will become an error in a future release. 

Log to:

• Loglevel to syslog
• Loglevel to console
• Email all error-level logs

And have the loglevel be environment configurable.

Subtask of #10.

Verify that the API used to pull the course structure from ex-platform does not return hidden modules.

.. that implement the following schema.

CCXCon has descriptions for courses. This comes from edX.
Users can update these descriptions.
If the user publishes their course again, it will overwrite.

How do we want to fix this? Maybe store updated descriptions in teacher's portal?

Some changes are needed for POST requests to the endpoint /api/v1/coursexs/

• image_url needs to support just a path
• edx_instance should not be provided by the client
• author_name should accept null values
• course_id needs to be added to the list of fields: course_id is a string representation of a course locator on EDX and it is unique

Make sure logging works properly
Make everything environment-variable-friendly

This will prevent the tests from clobbering your actual db.
Additionally, we can remove the explicit dredd step from our travis file, which should speed up the build.

A portal (like the teachers portal) needs to securely communicate with the ccxcon in order to query courses for the catalog and to create new custom courses.

Let's keep track of things that can affect the code base when moving to 1.9.

Here's one:

• We should remove the django.request config when we upgrade: https://docs.djangoproject.com/en/1.9/releases/1.9/#changes-to-the-default-logging-configuration (thanks for spotting @justinabrahms)

It would be nice if we could hit an endpoint (or it was written into the base template or admin or something) to get the current version deployed. This would help with validating that a particular change was on ccxcon-ci, for instance.

I think there is native support for this in django 1.9

Environment vars > Defaults

Subtask of #10.

We need the ability to purchase 1 or more modules inside a course in edx. Dependent upon mitocw/edx-platform#173

List resources should be paginated and support an offset and limit query param.

This is now done in tox

The initial pre-release rc/0.0.0 should work out any kinks in our release process and open the road for all of our future releases.

We should add in some release process documentation and adhere to that, similar to lore. Thoughts @pwilkins ?

Subtask of #10

We shouldn't rely on hotlinking from edx.

As a teacher/coach/customer I'd like to be able to see the names of modules/chapters in a course and purchase them.

When the CCXCon token is added to a course in an edX instance, edX will POST to the CCXcon and create a master course record. The CCXCon will then make a request back to edX to get a list of modules/chapters which it can make available to the Teachers Portal.

We should have an application-level heartbeat route which can be used for health checking by monitoring services.

The body of the response should be machine readable and contain:

1. The status of each connected component of the application (databases, external application APIs, etc).
2. The elapsed time for each component health check to complete.

Return status of the health check request:

• 200 if everything is fine.
• 500 if one or more components is in a known degraded state (e.g. connection timed out).

Not strictly required for, but related to #10.

and maybe other envs?