nnseva/django-access

Django-Access - the application introducing dynamic evaluation-based instance-level (row-level) access rights control for Django

django-access's Issues

django-extentions autocomplete admin

The Django-extensions autocomplete admin doesn't take into account the access rules.

Create a Django-extensions autocomplete admin taking access rules into account.

---

Filter truth values from plugin callbacks

Happens frequently that the plugin method returns truth value instead of a dictionary from check_ calls. The SimpleCheckPlugin now filters such a return.

It is useful to filter such truth values everywhere allowing users to return simple value from the plugin to exclude frequent misusing of the package.

Django REST Framework plugin

It is useful to create a Django REST Framework plugin to use django-access in the framework environment.

django-select2 widget

The standard Django-select2 widget doesn't take access rules into account.

Create a widget set inherited from Django-select2 to take access rules into account.

Constant instead of callable check

The simplest way to check rights is to return constant value, f.e. True, False, or {}. In case of constant grant type, the code should be allowed to look like:

        ApplyAblePlugin(
            changeable=False,
            deleteable=False,
        ),

instead of

        ApplyAblePlugin(
            changeable=lambda queryset, request: False,
            deleteable=lambda queryset, request: False,
        ),

A new validate check before create or update

Existent checks for create and update doesn't concern to the new attribute values.

It may be important especially for the foreign key values when the only selected person can link the created or updated instance to the object which is visible, but readonly for others.

It is proposed to create a check like verify_appendable() and verify_updateable() with parameters:

• model to be verified
• instance (?) to be verified (for updateable)
• dictionary of new attribute values

Fix standard has_perm calls

Fix standard has_perm calls to be compatible with packages checking permissions using has_perm call.

There may be a package using calls to the User.has_perm

Probably the own authentication backend should be implemented.

permission_required decorator for pages requiring permissions as a whole

django.contrib.auth.decorators.permission_required replacement

Log evaluation of access rules

It's sometimes useful to log evaluation details for the access rules.

Decorators to create abilities from callable

Decorators to create abilities from callable (instead of direct AccessManager call)

---

Template tools to check permissions inside the template

Template variables like {{ perms }} or something to check particular permissions for the whole model, or for the particular instance or for the instance set.

Create appropriate ability checking tools

Create appropriate ability checking tools like permission checking in standard Django environment and Django-Rules package:

• decorators to create abilities from callable
• decorators to check against abilities for views
• class-based view mixin to check against abilities for views
• template tags to get or check against abilities

---