KITPraktomatTeam / Praktomat

quality control for programming assignments
http://pp.ipd.kit.edu/projects/praktomat/praktomat.php
GNU General Public License v2.0
46 stars 22 forks source link

Default permissions: Trainer + Tutor: (using own defined roles) : using pypi/django-permission + pypi/django-admin-view-permission #241

Open ifrh opened 8 years ago

ifrh commented 8 years ago

can somebody confirm, that there exists no active default permissions for Trainer + Tutor?

I think the following should be as default: Trainer: can create, delete or modify a task can add, delete or modify a checker for a task can add or exchange a "model solution" for a task can create, delete or modify an attestation can annotate a solutionfile can modify or delete a annotation of a solutionfile can watch solutions (befor timeover or run allcheckers) Tutor:
can watch solutions (befor timeover or run allcheckers) can annotate a solutionfile can modify or delete a annotation of a solutionfile

But I am unsure about putting permissions from accounts, admin, attestation, auth, checker, configuration, contenttypes, sessions, solutions, tasks together to archive my recomendet default permissions for trainer and tutor.

mhecker commented 7 years ago

i'm not quite sure what you mean by

active default permissions

if by that you mean permissions defined by something like https://pypi.python.org/pypi/django-permission/ then in that sense, there really are no "active default permissions".

Permissions are currently checked in the corresponding views, either by annations such as @staff_member_required, or in the view code itself, with checks like

    if not (request.user.is_trainer or request.user.is_superuser):
        return access_denied(request)

Acces to files is also restricted in urls.py, via uses of utilities.views.serve_unrestricted and the like.

Yes, this is all somewhat messy.

ifrh commented 7 years ago

I thought about a permission setup , using "Permissions and Authorization" mentioned at https://docs.djangoproject.com/en/1.8/topics/auth/default/#permissions-and-authorization and https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#custom-permissions so that a Praktomat-Admin could generate via Admin-Page new kind of user categories and can apply permissions to these without changing template or view code.

That means: refactor view and template code to just obey "Permissions" and not (only) relay on is_trainer or is_superuser Best regards, Robert

ifrh commented 6 years ago

For Django 1.8 and later there could be an interesting permission-Addon for using on praktomats admin-page: https://pypi.python.org/pypi/django-admin-view-permission With that we could allow Tutors having read-only access to all Solutions while upload-time is active

ifrh commented 6 years ago

If we would define Permissions and relay on them, one could use Permissions like that:

perm = Permission.objects.get(codename='solutionanalyst')
allowedusers = User.objects.filter(Q(groups__permissions=perm) | Q(user_permissions=perm) ).distinct()

https://stackoverflow.com/questions/10252332/how-to-add-permissions-in-django-to-models-and-test-it-using-the-shell

Edit: Where solutionanalyst could be an own defined role or group, which should have access to admin-page and is only allowed to see and analyse all students uploads but is not tutor nor trainer nor superuser.

ifrh commented 6 years ago

In https://stackoverflow.com/a/52041938 there is an example given how "Groups" with "permissions" can be created via migrate. If I understand the stackoverflow example right, than for every app (like solution, checker, task) the permission could be set, so trainers must not be superusers. That should also fix https://github.com/KITPraktomatTeam/Praktomat/issues/213

ifrh commented 6 years ago

An other way for adding permissions while migrating is written here: https://stackoverflow.com/a/31735043

ifrh commented 6 years ago

writing data migrations is documented here : https://docs.djangoproject.com/en/1.11/topics/migrations/#data-migrations I'll try it.