Users, Groups and Permissions

Because you’re logged in as a superuser, you have access to create, edit, and delete any object. Naturally, different environments require different permission systems – not everybody can or should be a superuser.

Django’s admin site uses a permissions system that you can use to give specific users access only to the portions of the interface that they need. These user accounts are meant to be generic enough to be used outside of the admin interface, but we’ll just treat them as admin user accounts for now. In Chapter 11, we’ll cover how to manage users site-wide (i.e. not just the admin site) with Django’s authentication system.

You can edit users and permissions through the admin interface just like any other object. We saw this earlier in this chapter, when we played around with the User and Group sections of the admin. User objects have the standard username, password, e-mail and real name fields you might expect, along with a set of fields that define what the user is allowed to do in the admin interface.

First, there’s a set of three boolean flags:

  • The active flag controls whether the user is active at all. If this flag is off and the user tries to log in, they won’t be allowed in, even with a valid password.
  • The staff flag controls whether the user is allowed to log in to the admin interface (i.e., whether that user is considered a staff member in your organization). Since this same user system can be used to control access to public (i.e., non-admin) sites (see Chapter 11), this flag differentiates between public users and administrators.
  • The superuser flag gives the user full access to add, create and delete any item in the admin interface. If a user has this flag set, then all regular permissions (or lack thereof) are ignored for that user.

Normal admin users – that is, active, non-superuser staff members – are granted admin access through assigned permissions. Each object editable through the admin interface (e.g., books, authors, publishers) has three permissions: a create permission, an edit permission and a delete permission.

Assigning permissions to a user grants the user access to do what is described by those permissions. When you create a user, that user has no permissions, and it’s up to you to give the user specific permissions. For example, you can give a user permission to add and change publishers, but not permission to delete them.

Note that these permissions are defined per-model, not per-object – so they let you say “John can make changes to any book,” but they don’t let you say “John can make changes to any book published by Apress.” The latter functionality, per-object permissions, is a bit more complicated and is outside the scope of this book but is covered in the Django documentation.

You can also assign users to groups. A group is simply a set of permissions to apply to all members of that group. Groups are useful for granting identical permissions to a subset of users.

When and Why to Use the Admin Interface – And When Not to

After having worked through this chapter, you should have a good idea of how to use Django’s admin site. But I want to make a point of covering when and why you might want to use it – and when not to use it.

Django’s admin site shines when nontechnical users need to be able to enter data; that’s the purpose behind the feature, after all. At the newspaper where Django was first developed, development of a typical online feature – say, a special report on water quality in the municipal supply – would go something like this:

  • The reporter responsible for the project meets with one of the developers and describes the available data.
  • The developer designs Django models to fit this data and then opens up the admin site to the reporter.
  • The reporter inspects the admin site to point out any missing or extraneous fields – better now than later. The developer changes the models iteratively.
  • When the models are agreed upon, the reporter begins entering data using the admin site. At the same time, the programmer can focus on developing the publicly accessible views/templates (the fun part!).

In other words, the raison d’etre of Django’s admin interface is facilitating the simultaneous work of content producers and programmers. However, beyond these obvious data entry tasks, the admin site is useful in a few other cases:

  • Inspecting data models. Once you’ve defined a few models, it can be quite useful to call them up in the admin interface and enter some dummy data. In some cases, this might reveal data-modelling mistakes or other problems with your models.
  • Managing acquired data. For applications that rely on data coming from external sources (e.g., users or web crawlers), the admin site gives you an easy way to inspect or edit this data. You can think of it as a less powerful, but more convenient, version of your database’s command-line utility.
  • Quick and dirty data-management apps. You can use the admin site to build yourself a very lightweight data management app – say, to keep track of expenses. If you’re just building something for your own needs, not for public consumption, the admin site can take you a long way. In this sense, you can think of it as a beefed up, relational version of a spreadsheet.

The admin site is not, however, a be-all and end-all. It’s not intended to be a public interface to data, nor is it intended to allow for sophisticated sorting and searching of your data. As I said at the beginning of this chapter, it’s for trusted site administrators. Keeping this sweet spot in mind is the key to effective admin-site usage.

What’s Next?

So far we’ve created a few models and configured a top-notch interface for editing data. In the next chapter we’ll move on to the real meat and potatoes of web development: form creation and processing.

<<< Customizing Change Lists and Forms | Table of Contents | Django Forms >>>