Helper function which adds some niceties to the auth/user admin views. Needs django 1.2 to work. ### Usage Define a UserProfile class and set `AUTH_PROFILE_MODULE` as per the [django docs](http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users) In your admin.py file (or anywhere else) add the following: from models import UserProfile from [path to snippet] import upgrade_user_admin upgrade_user_admin(UserProfile)
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/
If you are an admin of a django site and many times it feels to visualize or experience how a normal website user actually sees different pages of your website. So to get this done, we create a normal user (just for testing purposes) and check the same, which is good. But sometimes we need to actually login as the same person to resolve a issue or to trace a particular exception which only one user or a specific set of users are experiencing. Usage:login_using_email(request, "[email protected]") I have mentioned only the helper or core method which is responsible for the actual user "logging-in" simulation. Proper view permissions(remember I mentioned only admins should use this) can be wrapped around it. Any thoughts on improving it? Always invited.... Public Clone Url: [git://gist.github.com/242439.git](git://gist.github.com/242439.git)
We often need to use a Profile form and we want to be able to modify the first_name, last_name and sometimes the email address. Here is how I do it. In this case I want to check the email so I did a specific form for it. But it is quite easy to add it.
UPDATE: 'ORDER BY' in de regex is now optional If enabled while coding just keep track of your console output for: <<< WARNING >>> Query execution without ownership clause, called from "process_response" Happy coding Regards, Gerard.
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.
This is a username field that matches (and slightly tightens) the constraints on usernames in Django's `User` model. Most people use RegexField, which is totally fine -- but it can't provide the fine-grained and user friendly messages that come from this field.
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)
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/)
Suppose you want a decorator which takes multiple permissions. You can use permission_required which takes a single value.
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
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.
This code monkey-patches the default User model to rather use a primary key of UUIDField (see http://www.djangosnippets.org/snippets/1496/). This code also makes the email field required. This code is wildly dangerous, not completely future proof, and probably not advisable to use. If you do wish to use it, it will be easiest to implement on a fresh db with a syncdb. If you need to migrate existing user data the onus is on you to figure out an appropriate db migration plan. I placed this code in a models.py, but it is probably more reliably placed in urls.py
My problem was that I needed user names with fullstops in them (eg dodgy.ville), but the slugfield on the admin form was rejecting them. This small snippet overrides the validation field on the admin form, To use it: place it in your admin.py
44 snippets posted so far.