django-projector is all about making life easier for project’s members. Thus, we try to implement the best practices in this area, and new proposals are always welcome!


Most of the times within Django project we use django.contrib.auth application to store and manage users (auth.User) and groups (auth.Group).


Note that we refer to model using standard notation applabel.ModelName which is used around django community. We prefer that over typing full python path to the specific class.

Those are very simply models and give developers ability to wrap them around they own classes. We use them too and this section describes how we do it at django-projector.

Most important model within application is Project. We connect it with users by Membership model. Moreover, we also use Team - it provides connection between Project, auth.User and auth.Group models.


Each user is related with project by Membership instance.


Membership for the author of the project is created automatically, and is given all available permissions and thus it’s member is referenced as project’s administrator.

Project’s adminstrator can add new member, change permissions of existing ones or remove members if necessary. Project owner’s permissions cannot be changed.

Admin can also manage teams.

Other members

User may be project’s member without associated Membership instance if he or she is member of a auth.Group (by the instance of Team - see below for more detail).

AnonymousUser member

Since Django 1.2 authentication backends may support anonymous user and django-guardian implements this functionality (see more at it’s documentation). As so, it is possible to add auth.AnonymousUser as a project’s member and manage it’s permissions as with any other user.


It is possible to give out administration privileges to anonymous user this way. Some views (like task creation or project edition) requires user to be logged in but project’s owner should be careful about anonymous user’s permission management.

Convert to Team

Any user may be converted into Team instance. Well, this is not totally true - in fact, by conversion to Team we mean set a team flag on the user’s profile. Conversion is available if user profile’s is_team attribute is False and there is no auth.Group instance named same as the user.

Conversion is done within user’s dashboard and each step of conversion is described below:

  1. User clicks on Convert to Team button at his or her dashboard.
  2. If there is auth.Group named as the user, ValidationError is raised.
  3. User confirms conversion.
  4. auth.Group instance named same as the user is created. This group is automatically added to User.groups.
  5. UserProfile.is_team attribute is set to True. From now on, accessing would return auth.Group instance created in previous step.

Conversion’s api is provided by Team manager’s method projector.managers.TeamManager.convert_from_user().


Any auth.Group may be used to create Team instance which bounds auth.Group and Project. Normally, one would create group using account conversion.

One user may be member of many teams. Single project may be managed by many users and many teams. It may be confusing but it’s really simple.

Table Of Contents

Previous topic

Example projector-based project

Next topic

Projects documentation

This Page