Context Navigation

Here's the beginning of my initial brain dump from our meeting. More to come....

Developer: What are you doing? You're supposed to be providing a useful hook for package designers!auth.User: It's hard. I'll do it in the next release.Developer: Come on man, it's your job!auth.User: Ehh, not really feelin' it. Hey, could you provide a username and password? You're totally blocking my .save() method.Developer: Uncle Adrian, this model has a bad motivator!

Introduction

This document seeks to identify resolutions and design propositions that will correct quite the foul attitude we've all experienced when trying to deal with django.contrib.auth.User. Unfortunately auth.User thinks it can just make all sorts of decisions for you and expects you to be happy with your hackish attempt to integrate it into your codebase. I bet you were stoked when you first learned that you had to have an "is_staff" field on your entire project's User model. You thought, "Well, thanks auth.User, but I don't really think this field is necessary for my totally awesome, real-time, Redis 'roided, GeoDjango packed, Pink Pony web app." See, little did you know that was auth.User just giving you the middle finger. But do not fear! We're looking out for you. Ya see, there's a better way....

Philosophy and Some Good Motivation

We think auth.User should have a much different perspective when it comes to your Django app. First and foremost, it is worthwhile to view your application from the perspective of an auth.User since after all, its all about your users, right?