Based on:
[View all log entries in the admin](https://djangosnippets.org/snippets/2484/)
Improvements:
* No crash on `object_link` when reverse route missing,
* Filter by users present in the log AND in database currently
* Other filters on users - only superusers / only staff (modify to fit your needs)
EDIT:
Incorporated `action_description` from [django-logentry-admin](https://github.com/yprez/django-logentry-admin).
* The list filter now has human-friendly action names, and the table also.
* Refactored list filter class hierarchy.
Updated a similar snippet by "King" to work with Django 1.6. This is especially useful for overriding the admin templates without having to symlink or copy them into your project. For example {% extends "admin:base.html" %} would extend the admin page base.html.
Based on [#2369](https://djangosnippets.org/snippets/2369/)
Save the snippet as actions.py within your django app, and then add an action on any model you want in it's ModelAdmin definition.
Example usage:
from actions import export_as_csv_action
class YourModelAdmin(admin.ModelAdmin):
list_display = (...)
list_filter = [...]
actions = [export_as_csv_action("CSV Export", fields=[...])]
- Unicode fix (requires unidecode)
Despite warning coming from django developers, I'm still using admin classes to quickly get into reverse engineering databases.
One feature is missing: searching into fields thanks to a regex.
One dirty solution I found is to overwrite get_search_results. But most of the code comes from django itself.
If anyone has a better idea ;)
**Usage:**
1. works since get_search_results is part of ModelAdmin (1.5 if I remember well)
2. Inherit your Admin class from RegexModelAdmin
3. enclose by / the field you want to regex with:
`search_fields = ['/field/', ]`
Official GitHub page: https://github.com/Mimino666/django-admin-autoregister
One call to autoregister_admin() automatically creates and registers admin views for all the models in the specified module with intelligent linking between ForeignKey, OneToOneField and ManyToManyField fields.
My Models has a FK to translations and also a many 2 many to categories which also them are translated
With this code I concatenate the translation of the categories and allow the changelist to order them.
works only on mysql but you can adapt to your DB
SET SESSION is required by mysql.
based on #2020
This one is even more generic than the previous generic ones since you can specify in fields any attribute you will give to the admin interface and not just fields from the model.
You can for example directly export the list_display as a list of fields, including look-ups for related attributes that you may have defined in a function inside the Admin Class
A simple example to show how to manage an history of memo-on-save.
Each time the user saves the model, he must provide a memo message.
The full memos history is shown as a read-only tabular-inline.
For each memo, user and date are also registered
([Django-Admin-Collapsed-Inlines](https://github.com/virajkanwade/Django-Admin-Collapsed-Inlines) could be usefull)
This snippet provides a subclass of admin.ModelAdmin that lets you span foreign key relationships in list_display using '__'. The foreign key columns are sortable and have pretty names, and select_related() is set appropriately so you don't need queries for each line.
EDITS:
* Fixed error when DEBUG=False.
* Broke out `getter_for_related_field` so you can override short_description manually (see example).
* Added regular foreign key fields to select_related(), since this is overriding the code in ChangeList that usually does it.
Based on [#2712](../2712/)
"This snippet creates a simple generic export to csv action that you can specify the fields you want exported and the labels used in the header row for each field. It expands on #2020 by using list comprehensions instead of sets so that you also control the order of the fields as well."
The additions here allow you to span foreign keys in the list of field names, and you can also reference callables.
Having spent ages trying out various admin inline ordering packages and examples I found on here and elsewhere I failed to find a single one that did what I was after in the way I wanted or that worked, so I wrote one!
The general idea for this version was to be done purely in javascript, no additional methods or parameters required on your models, it's designed to be stuck in a js file and included in your admin class Media js parameter:
class Media:
js = ['js/admin/widget_ordering.js', ]
Your model should have an integer column for sorting on, the name of this column should go in the 'sort_column' parameter at line 3 and your model should also obviously specify this in it's Meta 'ordering' class:
class Meta:
ordering = ('rank',)
That's it! This is a pretty basic implementation that adds simple up and down buttons next to the sort order field, if you want to adapt this to use drag and drop or something, please feel free!
1. Create an app and place this in `admin.py`.
2. Add `url(r'^login/$', 'social_auth.views.auth', {'backend': 'google'}, name='login')` to your `urls.py`.
3. Add the app to your `INSTALLED_APPS` after `django.contrib.admin`.
4. Set `USE_SOCIAL_AUTH_AS_ADMIN_LOGIN = True` in your `settings.py`.
5. ...
6. Profit.
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.