Parse all useful information from dataporten

[JakobGM]

API: from dataporten.groups import active_courses

[JakobGM]

Should use a json dump for test driving

[JakobGM]

Use proxy model? https://docs.djangoproject.com/en/dev/topics/db/models/#proxy-models

Probably not, as we would want access to user.dataporten.active_courses in the templates. Middleware?

EDIT: Actually both, see below!

[JakobGM]

Solution: dataporten.middleware.DataportenGroupsMiddleware should use a proxy model in order to replace request.user. It is very important that the middleware is placed after any authentication backend middleware, but before any app middleware.

Here is how to replace the class type of request.user with the proxy class: stack overflow. This is the way to go!

Use class based middleware.

The monkey patch needs to be applied before the view is called, i.e. before self.get_repsonse(request) is invoked.

[JakobGM]

So the middleware uses a proxy model which expands request.user with a dataporten property. The dataporten property is class based (or something else that establishes a namespace), with a cached group-api request in __init__. Further json parsing should be lazely evaluated and saved to a dict. The proper models in semesterpage should implement __in__ for membership evaluation.

[JakobGM]

This api will often be used in order to retrieve a set of course codes of particular interest. Such a course code will then be used like this: semesterpage.models.Course.objects.get(course_code=course_code). We should therefore consider setting db_index=True on the Course model. See chapter 7.6 in Two Scoops of Django.

[JakobGM]

If a large chunk of the dataporten groups data ends up only being used in templates, rather than in view logic, it might be worth considering pulling this logic into a custom context processor.

[JakobGM]

Should create a class which receives the JSON from the groups API, and delegates the respective groups to their respective parsers. For instance Course, StudyProgram, and University. This class is also responsible for splitting the courses based on if they are active or not.

[JakobGM]

Should be easy to add an extra predicate to semesterpage.rules which grants contribution access if the student is enrolled in the course. Add it as an OR predicate, and all the legacy logic can be left alone (and continually offer more detailed access control).

[JakobGM]

A Semester class can be written which handles:

• Year, i.e. 2017
• Spring / Autumn, i.e. V / H
• School year, i.e. 2016-2017
• Subtraction: H2017 - V2016 = 3

It should be initialized with a Datetime object, and will allow us to grant access to courses which are taken in the same school year, within the last x semesters, etc.

[hambro]

Maybe look at Django REST framework to parse the JSON objects. A lot of built-in functionality, maybe overkill tho.

[hambro]

Spring/year implementation is interesting: https://stackoverflow.com/questions/7727801/how-to-define-range-of-months-for-any-year-on-django-model .

[JakobGM]

For caching we can use: from django.utils.functional imported cached_property.

[JakobGM]

Now we are only missing:

• Parsing of org and orgunit types, i.e. university and faculty, respectively.
• DataportenGroupManager should be able to return Course-instances from the last n semesters.

And then we are done!

[JakobGM]

Parents should also be linked by the GroupManager.