jazzband/django-authority

A Django app that provides generic per-object-permissions for Django's auth app and helpers to create custom permission checks.

django-authority's Issues

AttributeError: module 'authority' has no attribute 'register'

Following the documentation, It seems that register is not an attribute of authority:

import authority
from authority import permissions
from django.contrib.flatpages.models import FlatPage

class FlatpagePermission(permissions.BasePermission):
    label = 'flatpage_permission'

authority.register(FlatPage, FlatpagePermission)

This gave me the error:
AttributeError: module 'authority' has no attribute 'register'

I then discovered that there is this, which seems to not throw the error but I'm not sure if this will do the same thing:
authority.utils.register(FlatPage, FlatPagePermission)

Is this correct, or did I not do something correctly?

Django init with haystack autodiscovery fails on direct import of User model

The commit 770e696 (found via git bisect) causes Django initialization to fail with a circular import if Haystack is installed, with its autodiscover init:

Traceback (most recent call last):
  File wsgi.py", line 105, in <module>
    import X.Y.sitemaps
  File X/Y/sitemaps.py", line 5, in <module>
    from X.Y.models import A, B, C
  File X/Y/models.py", line 14, in <module>
    from authority.models import Permission, Group
  File "ext/django-authority/authority/__init__.py", line 2, in <module>
    from authority.sites import site, get_check, get_choices_for, register, unregister
  File "ext/django-authority/authority/sites.py", line 7, in <module>
    from authority.permissions import BasePermission
  File "ext/django-authority/authority/permissions.py", line 9, in <module>
    from authority.models import Permission
  File "ext/django-authority/authority/models.py", line 10, in <module>
    from authority.utils import User
  File "ext/django-authority/authority/utils.py", line 11, in <module>
    User = get_user_class()
  File "ext/django-authority/authority/utils.py", line 6, in get_user_class
    return auth.get_user_model()
  File "pyenv/DJANGO15/lib/python2.7/site-packages/django/contrib/auth/__init__.py", line 127, in get_user_model
    user_model = get_model(app_label, model_name)
  File "pyenv/DJANGO15/lib/python2.7/site-packages/django/db/models/loading.py", line 230, in get_model
    self._populate()
  File "pyenv/DJANGO15/lib/python2.7/site-packages/django/db/models/loading.py", line 72, in _populate
    self.load_app(app_name, True)
  File "pyenv/DJANGO15/lib/python2.7/site-packages/django/db/models/loading.py", line 94, in load_app
    app_module = import_module(app_name)
  File "pyenv/DJANGO15/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
    __import__(name)
  File "pyenv/DJANGO15/lib/python2.7/site-packages/haystack/__init__.py", line 144, in <module>
    handle_registrations()
  File "pyenv/DJANGO15/lib/python2.7/site-packages/haystack/__init__.py", line 140, in handle_registrations
    search_sites_conf = __import__(settings.HAYSTACK_SITECONF)
  File X/search_sites.py", line 2, in <module>
    haystack.autodiscover()
  File "pyenv/DJANGO15/lib/python2.7/site-packages/haystack/__init__.py", line 121, in autodiscover
    importlib.import_module("%s.search_indexes" % app)
  File "pyenv/DJANGO15/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
    __import__(name)
  File X/Y/search_indexes.py", line 2, in <module>
    from X.Y.models import A, D, E
ImportError: cannot import name A

If the change was really made just for readability, then it might be worth reverting to avoid this kind of problem.

Update docs to battle general confusion

This is a pretty cool permissions package but due to some outdated links in both the documentation: http://pythonhosted.org/django-authority/ and on pypi: https://pypi.python.org/pypi/django-authority/ it now looks like the latest verision of this package is the bitbucket version which has not been updated in a over year (and is stuck on 0.4).

Since the bitbucket version is the first result in google it might make sense to tell people the repository has moved to github?

BasePermission.assign overwrites permission if it exists for another group, fails if two exist

In BasePermission.assign, no group parameter is passed to Permission.objects.get and .create. As a result:

1. if a permission instance for a different group exists, it is overwritten instead of assigning a new permission instance for self.group
2. if two permission instances for different groups exist, a MultipleObjectsReturned exception is raised

(Copied from PolicyStat/django-authority#13, originally from https://bitbucket.org/jezdez/django-authority/issue/16/)

Unique together constraints do nothing if user or group are blank.

http://stackoverflow.com/questions/3712222/does-mysql-ignore-null-values-on-unique-constraints

We should change the unique_together to:

        unique_together = (
            ("codename", "object_id", "content_type", "group"),
            ("codename", "object_id", "content_type", "user"),
        )

GenericForeignKeyRawIdWidget with Django 1.11

I am porting an app to Django 1.11 and found that if I look at individual permissions an error occurs. It comes from GenericForeignKeyRawIdWidget. I have had a look at the code in question and I am trying to get understand what is going on, it seems a little confused: https://github.com/jazzband/django-authority/blob/master/authority/widgets.py#L22-L26 The __init__ method in the class is calling the __init__ method of the base class' base class (so it misses a level of initialisation, which I think is not a good idea). However the parameters for GenericForeignKeyRawIdWidget.__init__ are not sufficient to call ForeignKeyRawIdWidget.__init__.

So essentially for a GET against /authority/permission/21852/change/ using Django 1.11.28 results in an AttributeError: 'GenericForeignKeyRawIdWidget' object has no attribute 'rel'
It blows up in /site-packages/django/contrib/admin/widgets.py in get_context, line 139. However though changing the base class of GenericForeignKeyRawIdWidget to forms.TextInput does prevent this error, but is that the right thing to do?

If anyone has any advice or clues of how to have this behave then thank you in advance :)

PyPI Release: version 0.15

Hi @jezdez or current maintainer,

When Django 2.2 LTS reaches end of support April 2022, version 0.14 on PyPi will no longer be compatible with any supported versions of Django. If you have the time, could you please build and release a package with the latest commits from master?

The master branch resolves these features being deprecated in Django 3.0

• django.shortcuts.render_to_response() will be removed.
• django.utils.six was removed (not documented in the log, but the package was removed from the module index. No documentation exists after version 1.11)

AttributeError 'Options' object has no attribute 'get_ordered_objects' in Django 1.6

Hi, I'm using version 0.8 of django-authority and I'm following the documentation to create a per-object permission in Django 1.6. When in the admin I select an object from my class and try to 'Edit permissions for selected 'MyObject'", I get the following error:

AttributeError at /admin/activity/myobject/

'Options' object has no attribute 'get_ordered_objects'

Request Method: POST
Request URL: http://example.com/admin/activity/myobject/
Django Version: 1.6.2
Exception Type: AttributeError
Exception Value:

'Options' object has no attribute 'get_ordered_objects'

Exception Location: .virtualenv/lib/python2.7/site-packages/authority/admin.py in edit_permissions, line 84
Python Executable: /usr/bin/python
Python Version: 2.7.6

I found a ticket about the removal of 'get_ordered_objects' [1] and I can't find it in the source code for 1.6, but I don't know enough of what this function is used for, to comment it or replace it.

[1] https://code.djangoproject.com/ticket/19469

'AdminSite' object has no attribute 'root_path'

with django > 1.4.2, it seems that modeladmin.admin_site.root_path can just be deleted with admin.py – will add further checks and fix this.

Django 3.* not supported

django 2.0 not supported.

django version

Hi,

The Django-Authority Debian package is obsolete. Version 0.5.
The Django version in Debian testing/sid is 1.9.

The last version of Django-Authority (0.10) supports Django 1.9 ?
If so, I will try to upgrade the Debian package.

regards,
Herbert

Latest version not on PyPI?

Hi,

Django 1.10 support was added in version 0.12, but PyPI contains only 0.11: https://pypi.python.org/pypi/django-authority/.

csrf_token missing with permissions_change_form

when trying to edit permissions (via actions), one gets an error because of the missing csrf_token.

Most recent version on PyPi still uses `basestring`.

Although there is a fix in the code to stop using basestring, that has not been pushed to PyPi. Can we get a new version pushed to PyPi?

What is the right way to get permission class by model class?

Hello everyone.

If I called authority.sites.register (ModelClass, PermissionClass), I can later call other methods from authority.sites to retrieve the list of all permission names of PermissionClass and to retrieve the specific check function. But I am sorry, but I can't understand is there a good way to retrieve the PermissionClass itself if I only have the ModelClass. Is there a good way to do it without diving deep into the internal data of authority.sites module?

Thank you.

Alex.

Fix dev version url

Please fix url for dev version.

It is using old bitbucket url: http://bitbucket.org/jezdez/django-authority/get/tip.gz#egg=django-authority-dev

Model creation error in

Hi Guys,

In Django version 2.1.7 and Authority 0.13.2 I get the below error:

The problem

  File "/home/dean/Documents/mycio/mycio-simafrica/mycio-simafrica-env/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 728, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/dean/Documents/mycio/mycio-simafrica/mycio-simafrica-env/lib/python3.7/site-packages/authority/migrations/0001_initial.py", line 9, in <module>
    class Migration(migrations.Migration):
  File "/home/dean/Documents/mycio/mycio-simafrica/mycio-simafrica-env/lib/python3.7/site-packages/authority/migrations/0001_initial.py", line 30, in Migration
    ('user', models.ForeignKey(related_name='granted_permissions', blank=True, to=settings.AUTH_USER_MODEL, null=True)),
TypeError: __init__() missing 1 required positional argument: 'on_delete'

The fix

I was able to fix in the following files:

models.py:

Added , ondelete.PROTECT to all ForeignKey fields as follows

    content_type = models.ForeignKey(ContentType, related_name="row_permissions", on_delete=models.PROTECT )
    user = models.ForeignKey(
        user_model_label, null=True, blank=True, related_name='granted_permissions', on_delete=models.PROTECT)
    group = models.ForeignKey(Group, null=True, blank=True, on_delete=models.PROTECT)
    creator = models.ForeignKey(
        user_model_label, null=True, blank=True, related_name='created_permissions', on_delete=models.PROTECT)

I also had to update the 00001_initial.py file, but this one could be a per machine thing because that script might have been generated the first time i initialized authority code from my application.

00001_initial.py:

Also added , ondelete.PROTECT to all ForeignKey fields as follows:

                ('content_type', models.ForeignKey(related_name='row_permissions', to='contenttypes.ContentType', on_delete=models.PROTECT)),
                ('creator', models.ForeignKey(related_name='created_permissions', blank=True, to=settings.AUTH_USER_MODEL, null=True, on_delete=models.PROTECT)),
                ('group', models.ForeignKey(blank=True, to='auth.Group', null=True, on_delete=models.PROTECT)),
                ('user', models.ForeignKey(related_name='granted_permissions', blank=True, to=settings.AUTH_USER_MODEL, null=True, on_delete=models.PROTECT)),

Not sure if i should fix, branch out and send a pull request or if this was fixed in another version?

admin template folders

currently, the admin templates are within the folders "admin" and "authority" – if I'm overwriting certain templates (e.g. permission_change_form.html in folder admin), there might be conflicts with other 3rd–party apps.

therefore, shouldn't we move all templates to "authority"? maybe I'm missing something, but what's the reason for splitting templates to different folders anyway?

permission_required decorator does not work with non logged in users

There is an inconstancy between the templatetag ifhasperm and the decorator permission_required in how they treat non logged-in users. ifhasperm always attempts to evaluate the permissions for the user while permission_required shortcuts and return False if the user is not authenticated. As the majority of my conditions are custom, quite a few of them affect non logged-in users(AnonymousUser).