Is it wrong to disable a lot of the core django features?

[John Rodkey]

We are evaluating django for a new internal CRM project and have issues using many of the built in features including: the base user, permissions, and authentication.

We do not wish to use the built-in admin...  The level of complexity for our permissions will be based on the employees job function/role.  While django does offer "Groups" under permissions, we have many subsidiaries which may name their own groups, this is our reasoning for dumping the built-in permissions.

What we are trying to accomplish -

1. User registration and authorization based on users email address. (We believe this could be created with the "Custom User" information found in the docs.)

2. Depending on the users email domain (the subsidiary) they work for, they will only have access to that data (We do not believe django offers this, and will be building it)

3. Each company (subsidiary) will have their own permission roles/groups (We do not believe this is available in django, please correct if wrong).

4. Each user will be assigned role(s)/permission(s) for their company (We believe this will need to be a custom tool)

Is there a simple solution to altering the built-in authentication and permission to fit our needs?  

[Carl Meyer]

Hi John,

I'll start with answering the question in your subject: no. There's
nothing at all wrong with using the parts of Django that are useful to
you, and not using the ones that aren't.

In particular, auth and admin are part of "contrib"; that is, useful
applications built on top of Django and shipped with it. They aren't
even part of Django core. All of contrib is meant to be entirely optional.

On 11/21/2014 01:18 PM, John Rodkey wrote:
> We are evaluating django for a new internal CRM project and have issues
> using many of the built in features including: the base user, permissions,
> and authentication.
>
> We do not wish to use the built-in admin... The level of complexity for
> our permissions will be based on the employees job function/role. While
> django does offer "Groups" under permissions, we have many subsidiaries
> which may name their own groups, this is our reasoning for dumping the
> built-in permissions.
>
> What we are trying to accomplish -
>
> 1. User registration and authorization based on users email address. (We
> believe this could be created with the "Custom User" information found in
> the docs.)

Yes, that's right.

> 2. Depending on the users email domain (the subsidiary) they work for, they
> will only have access to that data (We do not believe django offers this,
> and will be building it)
>
> 3. Each company (subsidiary) will have their own permission roles/groups
> (We do not believe this is available in django, please correct if wrong).
>
> 4. Each user will be assigned role(s)/permission(s) for their company (We
> believe this will need to be a custom tool)
>
>
> Is there a simple solution to altering the built-in authentication and
> permission to fit our needs?

The built in groups/permissions system is fairly limited: based on your
needs, I think you may be better off building that yourself.

If I were you, I would use the built-in auth system (but with a custom
User model) -- it's pretty flexible these days, and using it will give
you better interoperability with many parts of the Django ecosystem. If
your custom User model inherits from AbstractBaseUser (not AbstractUser)
it won't have the many-to-many relationships with Permission and Group,
and you can just ignore them and build your own permission/roles system
instead.

Carl

[John Rodkey]

Hi Carl,

Thank you for the quick answer.  Using your recommendation, can we simply disable the admin, groups and permissions, but still use the Authentication (login/sessions)?  

We will create our own authorization module for permissions/roles and groups.

Best,

John

[Carl Meyer]

Hi John,

On 11/21/2014 02:33 PM, John Rodkey wrote:
> Thank you for the quick answer. Using your recommendation, can we simply
> disable the admin, groups and permissions, but still use the Authentication
> (login/sessions)?

The admin is already separate from auth, so that's easy to turn off.

With the built-in groups and permissions, you will still have tables for
them in the database, but they don't need to be linked to your custom
User class (as I described in my last mail), so you can basically just
ignore them and use your own authorization module instead.

Carl

[John Rodkey]

Perfect.  That answers my question.  I was trying to avoid having the two tables in the db -- but we will just disregard them.

Thank you for all of the input and quick replies.  Django appears to have a great community and we are excited to get started.

[Gabriel - Iulian Dumbrava]

Hello!

I would suggest to not drop the use of the built in auth module. You have many template and view tags, decorators, etc which are very helpful.

You may, for example create a group for each company/branch then add each user to their respective groups upon registration.

Each groups may have custom permissions, so you are not stuck with the built in add/edit/delete rights. You may create any type of permission and check for it in verious places.

[John Rodkey]

Gabriel,

How would you store groups for each company within the default "groups" database?  Our current database design is

Company

CustomUser belongs to Company

Roles belongs to Company (replacing default "Groups" with "Roles")

Roles has many Authorities (replacing default "Permissions" with "Authorities")

*additional tables will be configured for assigning Roles to CustomUsers most likely through a many to many - join

Using our very limited design above, what would you recommend approach be for using the providing "Grouping/Perms"?

[Collin Anderson]

Hi all,

I agree that it's perfectly fine to not use the built in auth and admin apps, and people do it all the time. But, I wanted to give a quick proof of concept of using the admin with custom permissions.

# models.py
from django.contrib.auth.models import AbstractBaseUser
from django.db import models

class Company(models.Model):
    name = models.CharField(max_length=255)

class Authority(models.Model):  # Permission
    company = models.ForeignKey(Company)
    name = models.CharField(max_length=255)

class Role(models.Model):  # Group
    name = models.CharField(max_length=255)
    authorities = models.ManyToManyField(Authority, blank=True)

class EmailUserManager(models.Manager):
    def get_by_natural_key(self, email):
        return self.get(email=email)

class CustomUser(AbstractBaseUser):
    company = models.ForeignKey(Company)
    email = models.EmailField('Email', unique=True)
    roles = models.ManyToManyField(Role, related_name='users', blank=True)
    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = ['company']
    is_staff = True  # all users can login to the admin
    objects = EmailUserManager()

    def get_short_name(self):
        return self.email

    @property
    def authorities(self):
        return Authority.objects.filter(role__users=self)

# admin.py

from django.contrib.auth.models import Group

from django.contrib import admin

from .models import Company, Role, Authority, CustomUser

admin.site.unregister(Group)

class PermAdmin(admin.ModelAdmin):

    def has_add_permission(self, request):
        permission_name = 'can_add_%s' % self.model._meta.model_name
        return request.user.authorities.filter(name=permission_name).exists()

    def has_change_permission(self, request, obj=None):
        permission_name = 'can_change_%s' % self.model._meta.model_name
        return request.user.authorities.filter(name=permission_name).exists()

    def has_delete_permission(self, request, obj=None):
        permission_name = 'can_delete_%s' % self.model._meta.model_name
        return request.user.authorities.filter(name=permission_name).exists()

    def has_module_permission(self, request):
        add = 'can_add_%s' % self.model._meta.model_name
        change = 'can_change_%s' % self.model._meta.model_name
        delete = 'can_delete_%s' % self.model._meta.model_name
        return request.user.authorities.filter(name__in=(add, change, delete)).exists()

admin.site.register(Role, PermAdmin)
admin.site.register(Company, PermAdmin)
admin.site.register(Authority, PermAdmin)
admin.site.register(CustomUser, PermAdmin)

Or it may be better to do the permission checking in user.has_perm() which the default has_change_permission() will call.

Collin

[Gabriel - Iulian Dumbrava]

Hi John,

I don't know if this would work for you as you indeed have an extra level.
I'll do it this way

Authorities are the permissions from Django, for example you may have custom permissions (authorities in your case): "can_add_employee", "can_edit_employee", "can_view_employee"
Roles would be the groups from Django, for example you might have:
"HR" with "can_add_employee", "can_edit_employee", "can_view_employee"
"Employee" with "can_view_employee"

Then you have companies, a different model, where you assign different Roles. I believe that in order to use the auth system, upon registration and company assignment you would have to also add the user to the custom Roles that the company has available. In this way you have a relation:
CustomUser -> Roles (groups in Django) -> Authorities (perms in Django)
Then of course you can assign CustomUser -> Authorities separately.

Check the custom permissions doc.

I don't know if this is ok for you, but I think it might help.

If you want to drop this functionality you may of course create your own decorators and template tags to help you with a parallel auth system
Gabriel