Completely based on [snippet 2729](http://djangosnippets.org/snippets/2729/) (see that snippet for useful comments!). The above snippet did not work for me (something with MemoryError), so I looked at the Drula source code and reimplemented...
Sample usage for using decorator `@json_response(ajax_required=True, login_required=True)` `def subscribe(request):` ` return {"status":"success"}` Converts a function returning dict into json response. Does is_ajax check and user authenticated check if set in flags. When function returns HttpResponse does nothing.
See docstring
When saving an edit to an object from a filtered list view you are, by default, returned to list view without any of your filters applied. This solves that problem, keeping the filtered view in a session variable until you reach a point where the session key is deleted. This solution doesn't require changes to template code...this is completely self contained within your own admin.py files. The solution presented here is a revision of a previous patch, which has been modified for Django 1.4. The Django 1.3 version exists at: http://djangosnippets.org/snippets/2531/ From chronosllc: The advantage to our solution over the above linked solution is that under different use cases the user may or may not be redirected to the filtered list_view. For example, if you edit an object and click the save and continue button, then you would lose the filter when you finally finished editing the object and clicked save. Added on here is a delete of the session key when users add objects, the reasoning we're going this route is we don't want to return users to filtered views when they just added a new object. Your mileage may vary and if so, it's easy enough to fit your own needs.
This will hide the scrolling output from the development server so you can ssh and run the server in peace, for those of us with only one SSH session active developing on a remote server.
This is an updated snippet based on http://djangosnippets.org/snippets/2260/ The updated snippet can limit the filtering options for a foreign key field to only those entries that are related to the current model. I.e. if you have an Author model with a FK to Institution model, you can configure Author's changelist to include a filter on Institution, but only allow you to select institutions that have authors. Institutions that do not have authors won't show up on the list. To enable this, in your model's ModelAdmin class, set <fieldname>_fk_filter_related_only=True <fieldname>_fk_filter_name_field=<display this field of the related model in filter list> For example, in your AuthorAdmin class, you can do institution_fk_filter_related_only=True institution_fk_filter_name_field='name' Note that for the effect described above to work, you just need the last few lines of the big else clause in __init__, so if you don't care about filtering by FK property, you can just grab those few lines and create a simpler FilterSpec.
This code allows you to register a model to Django that is only used for unit testing. It will not exist in the regular Django workflow. After the tests executed, the Django settings are restored. Usage: 1. Change `tests.py` into a `tests` package. 2. Place a `models.py` in the `tests` package. 3. Use the following code below to enable it. Example: class MyTest(CustomSettingsTestCase): new_settings = dict( INSTALLED_APPS=( 'django.contrib.contenttypes', 'django.contrib.auth', 'app_to_test', 'app_to_test.tests', ) ) Based on http://djangosnippets.org/snippets/1011/ as Django 1.4 version
An email address obfuscation template filter based on the ROT13 Encryption function in Textmate's HTML bundle. The filter should be applied to a string representing an email address. You can optionally pass the filter an argument that will be used as the email link text (otherwise it will simply use the email address itself). Example usage: {{ email_address|obfuscate:"Contact me!" }} or {{ email_address|obfuscate }} Of course, you can also use this on hardcoded email addresses, like this: {{ "[email protected]"|obfuscate }}
A helper.
qurl is a tag to append, remove or replace query string parameters from an url (preserve order)
**I've since made a better snippet for this: [#2995](http://djangosnippets.org/snippets/2995/)** based on [#1697](http://djangosnippets.org/snippets/1697/) This one is even more generic since you can specify which fields to include or exclude, a custom description text for the drop-down menu and whether to output the header row.
Simple contact form, using a javascript form checker which you can use any you want to you can just modify the form in the way you want to. The form checker I use I include in the 'base.html' page before the </head> section end. You can use it freely. http://media.xorl.de/form.js . A lot of this code is comprised of other peoples forms that didn't suit the simple purpose of a *really* basic contact form which I wanted, so I rebuilt it up from bits and pieces to make a simple basic form.
These generic views extend default views so that they also do permission checking on per-object basis. * detail, update and delete - check access for user * create - create permissions for user on object * list - narrow object list with permissions Classes prefixed with Owned are example implementation where user has access to object if designed object attribute references him. Example: `create_article = OwnedCreateView.as_view(owner='creator', model=Article, form_class=ArticleForm, success_url='/articles/article/%(id)d')`
Ever tried to unit test custom fields or abstract models? If so, you probably used a solution like [this one](http://djangosnippets.org/snippets/2843/). It surely works, but it has some issues: 1. Runs 'syncdb' several times. 2. It's not automatic. You must add the mixin or copy the code to each of the TestCases. This test runner adds to INSTALLED_APPS the 'app.tests' package for **each of the specified** apps, **before the 'syncdb' happens**. This has the [discovery runner](https://pypi.python.org/pypi/django-discover-runner) as a dependency (for 1.5 only, it will be the default in 1.6). However, it comes as a mixin so it should be easily pluggable to other test runners. If you intend to use the mixin with other runners, note that it imports 'app.tests.models' so it won't work with tests modules (tests.py). Your runner must "use" test packages (like discovery runner). # USAGE # in your settings.py: TESTAPPS_INSTALL = ( 'app1', 'app2', # ... ) TEST_RUNNER = 'testapp_runner.DiscoverTestAppRunner' # example import path # extra apps in command line. # run test for apps 'app1' to 'app4', adding 'app3' and 'app4' to the TESTAPPS_INSTALL setting. manage.py test app1 app2 app3 app4 --with-test-app=app3 --with-test-app=app4
This is a authentication backend for Django, to authenticate via Active Directory. This pulls all group information out of Active Directory and allows for multiple group memberships.