Timestamped models and auto slug fields

The standard way of using Django Organizations is to use it as an installed app
in your Django project. Django Organizations will need to use a
TimeStampedModel and an auto slug field which are not included. By default it
will try to import these from django-extensions, but you can configure your own
in settings. The defaults:

Registration & invitation backends

You can specify a different invitation backend in your project settings, and
the invitation_backend function will provide the URLs defined by that
backend:

ORGS_INVITATION_BACKEND = 'myapp.backends.MyInvitationBackend'

Usage Overview

For most use cases it should be sufficient to include the app views directly
using the default URL conf file. You can customize their functionality or
access controls by extending the base views.

There are three models:

Organization The group object. This is what you would associate your own
app’s functionality with, e.g. subscriptions, repositories, projects, etc.

OrganizationUser A custom through model for the ManyToMany relationship
between the Organization model and the User model. It stores additional
information about the user specific to the organization and provides a
convenient link for organization ownership.

OrganizationOwner The user with rights over the life and death of the
organization. This is a one to one relationship with the OrganizationUser
model. This allows User objects to own multiple organizations and makes it
easy to enforce ownership from within the organization’s membership.

Custom models

Django-organizations can act as a base library (not installed in your project)
and used to create unique organization model sets using custom tables. See the
Cooking with Django Organizations
section in the documentation for advice on proceeding.

Development & Contributing

Development is on-going. To-do items have been moved to the wiki for the time
being.

The basic functionality should not need much extending. Current dev priorities
for me and contributors should include:

Improving the tests and test coverage (ideally moving them back out of the
main module and executable using the setup.py file)

Improving the backends and backends concept so that additional invitation and
registration backends can be used

Documentation

Ensuring all application text is translatable

Python 3 readiness

Please use the project’s issues tracker to report bugs, doc updates, or other
requests/suggestions.

Targets & testing

The codebase is targeted at tested against:

Django 1.8.x against Python 2.7, 3.4, 3.5

Django 1.9.x against Python 2.7, 3.4, 3.5

To run the tests against all target environments, install tox and then execute the command:

tox

Submitting

These submission guidelines will make it more likely your submissions will be
reviewed and make it into the project:

Ensure they match the project goals and are sufficiently generalized

Please try to follow Django coding style.
The code base style isn’t all up to par, but I’d like it to move in that
direction

Pull requests should include an amount of code and commits that are
reasonable to review, are logically grouped, and based off clean feature
branches.

Code contributions are expected to pass in all target environments, and
pull requests should be made from branches with passing builds on Travis
CI.

Project goals

django-organizations should be backend agnostic:

Authentication agnostic

Registration agnostic

Invitation agnostic

User messaging agnostic

Etc.

License

Anyone is free to use or modify this software under the terms of the BSD
license.

History

0.6.0

Adds Django 1.9 support

Drops support for Django 1.7

Fixes migration issue related to incomplete support for configurable model
fields and base model. If you are upgrading (especially from a fork of the
development version of django-organization) you may have an extra migration,
0002_auto_20151005_1823, which has been removed.