I24 permission protection + metadata on course-evaluation page

[frinzekt]

Closes #24, Closes #71

Includes:

• permission protection for the backend
• change frontend that needs coordinators/reviewer details to use only the couse-evalution service
• server console log linting

[frinzekt]

One of the things I realized while I was doing this

change frontend that needs coordinators/reviewer details to use only the couse-evalution service (WIP)

is that if I bind details of coordinators/reviewers in the course-evaluation state, we lose the ability for instant interface change effect. We have a couple of options to address this problem:

• reupdate the entire course-evaluation state everytime you modify user information (costly in terms of loading the entire course-evaluation)
• update how the sockets onCreate/onPatch works... by identifying whether we need to modify courseEvaluation data (how it would work is that we have a function in the onCreate/onPatch to see get all permission for the course and compare whether it is still the same. If it is not the same, then do update the courseEvaluation state by dispatch ... [this is some complexity because we have never ever done a dispatch towards a feathersService state before).

What do you think @MouseAndKeyboard ?

[frinzekt]

Note: this needs to be thoroughly tested. Mistakes in this pull request will prevent any reviewer or coordinator from doing what they are supposed to do. Ideally, no existing features will be affected.

You have to check this in the frontend by using an account that only has "just enough" permission to do the task. Eg. if you are doing a review, you should be able to do it with just the reviewer permission... and so on for other roles except administrator

[frinzekt]

I have raised #115 to address changing interface state when updating user permission using "event-based" sockets

[MouseAndKeyboard]

Looks good!

[MouseAndKeyboard]

Tested and working

[MouseAndKeyboard]

Is this supposed to be:
patch: [authenticate('jwt'), roleBasedRestrictions(['Coordinator', 'Administrator'])],

[MouseAndKeyboard]

Nvm, I can see that the in role-based-restrictions.js it short-circuits for anyone with administrator

[MouseAndKeyboard]

Currently just finalising testing, will merge when complete

[frinzekt]

automated regression testing would have been great for this kind of things. However, I just got busy from setting it up. There are a couple of hurdles such as:

• how do I test using google Oauth. My thoughts at the moment is to implement local username/password as a backup feature. It exist, but shouldn't be used idk

[frinzekt]

for future reference, use squash merge for feature branches to develop @MouseAndKeyboard