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:
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.
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:
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:
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.
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.