Teamwork¶
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!
Mappings¶
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
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.
Membership¶
Each user is related with project by Membership
instance.
Administration¶
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.
Warning
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:
- User clicks on Convert to Team button at his or her dashboard.
- If there is
auth.Group
named as the user,ValidationError
is raised. - User confirms conversion.
auth.Group
instance named same as the user is created. This group is automatically added toUser.groups
.UserProfile.is_team
attribute is set toTrue
. From now on, accessingUserProfile.group
would returnauth.Group
instance created in previous step.
Conversion’s api is provided by Team
manager’s method
projector.managers.TeamManager.convert_from_user()
.
Team¶
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.