Initialise Backend with Certain Dedicated Features

[MouseAndKeyboard]

Change Summary

• minimal initialisation of the frontend for reviewer listing
• additional models:
  - CourseEvaluationJustification
  - Documents
  - Review
  - ReviewEocSpecific
  - ReviewDocument
• permissions
  - initial permission for a reviewer
  - permission that can be applied to anything that has course_evaluation attribute (see CourseEvaluationIsCoordinatorAllowAllViaObjectReference)
• tests for document creation
• ModelViewSet for Documents

Change Form

Fill this up (NA if not available). If a certain criteria is not met, can you please give a reason.

• The pull request title has an issue number
• The change works by "Smoke testing" or quick testing
• The change has tests
• The change has documentation

Other Information

This has a lot of changes... and it is going so much... I need to split this changes now

The things that have been completed as a feature are:

• creation documents

The things that are not complete:

• review + the etc models endpoints attached to it
• course evaluations (coordinators + justification endpoints)

Flush Database

You will need to flush your database here, as I have done a lot of not reverse incompatible migrations

[frinzekt]

Something that was not discussed before is the structure of the endpoints... Here is what I have decided

/api/v1/course-evaluations/ - anything related to one course-evaluation
/api/v1/course-evaluations/{id}/document/ - resource group specifically for the course-evaluation documents (this is where to do CRUD operations for a document)
/api/v1/course-evaluations/{id}/justifications/ - resource group specifically for the course-evaluation justification (this is where to do CRUD operations for justifications in the course evaluation)
/api/v1/course-evaluations/{id}/coordinators/ - resource group specifically for the course-evaluation justification (this is where to do CRUD operations for coordinators in the course evaluation. Usecase: hey I wanna add a co-coordinator or I want to remove access)

/api/v1/review/ - CRUD operation related to review (coordinators can create, the specific reviewer can edit)
/api/v1/review/{id}/document - resource group for CRUD operations in document
/api/v1/review/{id}/eoc

Be aware @uwasystemhealth/redbacks... this is important to know for both a backend and frontend... Please feel free to question any of these if it doesnt make sense...

If later on in the future, the endpoint becomes too big for

/api/v1/course-evaluations/ 

we can open up endpoints like

/api/v1/course-evaluations/{id}/eoc - to just have the static information of eoc
/api/v1/course-evaluations/{id}/reviews - to see all the reviews data

[frinzekt]

I'll be merging this with or without a review by tomorrow to progress more tickets that have dependency on this

[frinzekt]

looks good, just remove the unuse comment for now

[frinzekt]

i have not checked the review page as much (frontend)... I'll continue it in the #14 issue... However, for now, I don't think we'll implement archiving simply because we don't have it as part of the #36 .

This is not really a problem though because archiving (as a feature) only is needed for when there is too much course evaluation assigned to a particular user. Realistically speaking, this will only grow by atmost 4 course evaluation per year for a user. (need to check with @mhodki), but as part of MVP, it is not required

[frinzekt]

looks good to me

[frinzekt]

damn... i didnt notice this broke the build... i really need the #50 to start doing builds alone