This avoids the frustrating step of having to set up a new admin user every time you re-initialize your database. Put this in any `models` module. In this example I use `common.models`. Adapted from http://stackoverflow.com/questions/1466827/
**How to use:** 1. puts this code at the end of the `models.py` file who haves the User Profile class declared; 2. verify if your User Profile class has the name 'UserProfile'. If not, change the code to the right name. **About:** this snippet makes the ORM create a profile each time an user is created (or updated, if the user profile lost), including 'admin' user.
An "if-style" template tag that checks to see if a user belongs to a specific group (by name).
Using this method you can combine form for standart django.contrib.auth.models.User model and for your project profile model. As now, ProfileForm can be used as usual, and it will also contain UserForm fields.
This is a ModelAdmin base class you can use to make foreign key references to User a bit nicer in admin. In addition to showing a user's username, it also shows their full name too (if they have one and it differs from the username). **2009-08-14**: updated to handle many to many fields and easily configure whether to always show the username (if it differs from full name)
Based loosely on [Eric's middleware](http://ericholscher.com/blog/2009/sep/5/debugging-django-production-revisited/), this middleware will show the technical 500 page (which you'd get if DEBUG == True) to any user who is (1) superuser and (2) a member of the settings.TECHNICAL_500_GROUP_NAME group. (If no setting exists, 'Technical Errors' is the presumed group name. I agreed with the comments that caching should be unnecessary given the (presumptive) edge case of exception + superuser. Assuming you don't have tons of superusers, this code is a good bit simpler.
Rather than requiring a dummy backend (which I have seen some people do), use this method to log in a user without requiring their credentials.
Many models are tightly coupled to the default Django `User` model (`django.contrib.auth.models.User`). Sometimes this user model just doesn't fit everyone's needs. By using `UserForeignKey` it is possible to make the `User` model configurable, encouraging loose coupling. Additionally, this can help to prevent circular imports between `User` and another model. Use it like a standard `ForeignKey`... it accepts all the same arguments. If you want to use a `User` model other than the default, just add `USER_MODEL` to your settings file.... it uses dotted notation (`app_label.model_name`). Example: class BlogPost(models.Model): user = UserForeignKey(related_name="blog_posts") title = models.CharField(...) content = models.TextField(...)
Staff can log in as a user, from a url to help with customer support or debugging.
This tag builds on top of the [ifusergroup/else tag](http://www.djangosnippets.org/snippets/390/), fixes a small bug and introduces support for else blocks. This adds a way to provide multiple groups via group1|group2|group3
This blog post outlined how to get the user from the session key: http://scottbarnham.com/blog/2008/12/04/get-user-from-session-key-in-django/ Unfortunately, it assumes DB-backed session and auth backends. This isn't required, so this snippet provides a backend-agnostic way to do the same thing. >>> skey = 'ea0ed02d35d43aeaf20b3ef516f51396' >>> user_from_session_key(skey) <User: jeremyd>
An "if-style" template tag that checks to see if a user belongs to a one or mores groups (by name). Usage: `{% ifusergroup Admins %} ... {% endifusergroup %} or {% ifusergroup Admins Clients Programmers Managers %} ... {% else %} ... {% endifusergroup %}`
Simple password validation for user registration - requires that password be 7 or more characters and contain both letters and numbers. Original validation with regex approach developed by kurtis. Optimized no-regex version based on code from watchedman ran as fast or significantly faster on all systems on which we tested it.
If you have a model with foreign key to User, you can use this manager to show (i.e. in admin interface) only objects, that are related to currently logged-in user. Superuser sees all objects, not only his. Requires: [ThreadlocalsMiddleware](http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser)
This is another foreign key to User model. User is automatically associated before save. Requires: [ThreadlocalsMiddleware](http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser) Inspired by: [snippet 509](http://www.djangosnippets.org/snippets/509/)