When working in the Django admin with a lot of users, you might sometimes want to offer the functionality to users to choose which columns they want to see in the changelist page. For some users some columns might be more relevant than to others.

One way to achieve this is by putting a button in the top right corner that will lead you to a intermediary page like this:

Using the FilteredSelectMultiple widget

For this you need a special django form, that will show the so called FilteredSelectMultiple widget that is shown above. This widget takes quite some effort to get working properly, as normally this only works out-of-the-box by using filter_horizontal = [...] or filter_vertical = [...] in a ModelAdmin.

The trick here is to add the class Media which will ensure that the correct javascript is loaded to make this widget work. As you see in the Gist below in filter_columns.html , you also need to include a stylesheet for the form.css or it will not look as nice.

from django import forms
from django.contrib.admin.widgets import FilteredSelectMultiple


class FilterColumnsForm(forms.Form):
    """Form with only one field to filter the columns.
    Django widget for horizontal selection, works only in the admin and only with media included.
    """
    filter_columns = forms.MultipleChoiceField(
        label=False,
        widget=FilteredSelectMultiple('columns', is_stacked=False)
    )

    class Media:
        js = ('/admin/jsi18n',)

This setup allows you to use FilteredSelectMultiple basically everywhere outside the regular admin configuration for if you want to customize the use or options.

ModelAdmin mixin to create an intermediary page

In get_urls() you want to append a new path that for the intermediary page for when you click on the "Columns" button. Based on the list_display parameter you can create some

def filter_columns(self, request):
    """View for intermediary page when clicking on the "Columns" button.
    Will render an admin view with standard context, showing the `FilterColumnsForm`.
    """
    cl = self.get_changelist_instance(request)

    # Determine which to display in the form and which are already selected
    display = []
    selected = []
    all_fields = type(self).list_display
    for field_name in all_fields:
        text = label_for_field(field_name, cl.model, model_admin=cl.model_admin, return_attr=False)
        display.append((field_name, text))
        if field_name in cl.list_display:
            selected.append(field_name)

    # Initialize form with selected and set the available choices
    form = FilterColumnsForm(initial={'filter_columns': selected})
    form['filter_columns'].field.choices = display

    # Add context for showing the menu and bars
    context = self.admin_site.each_context(request)
    context['title'] = _('Choose which columns to show')
    context['form'] = form
    context['opts'] = self.model._meta  # pylint: disable=protected-access
    request.current_app = self.admin_site.name
    return TemplateResponse(request, 'admin/filter_columns.html', context)

The whole code can be found here on Github:

Use this structure as it matters where the templates are placed, replace app by your own name:

app/admin.py
app/forms.py
app/templates/admin/filter_columns.html
app/templates/admin/change_list.html

Staff users and super users

Superuser is a powerful feature but if you have other staff users, e.g. employees of your company that also log into the admin, this can be a problem:

1. Staff users can change their own user and set superuser for themselves or others, even if they are not supposed to.

2. Users with superuser permissions can see every admin page and automatically have permissions to view, create, update and delete. Even if you've set certain group and user permissions, these will be overruled by superuser authority.

So from a security and usability perspective, the best thing to do is create dedicated groups for certain employees, with their own permissions. This will also ensure that they will only be bothered with the models that are relevant to them.

There will also be a group of developers and system admins who will be the actual superusers of the system. If appropriate all available permissions can be assigned to this group, you are in control what is off-limits. The superuser feature however will only be used for special elevated occasions, just like the root user.

Making the superuser expire

From experience, people who have superuser access will keep that access. But just like the Linux root user, you should reserve the use of this power for certain (destructive) operations. You don't want people deleting the contents of an entire model by accident. Therefore, it's best to have superuser permission that expires by itself after a while.

Below is a gist of a mixin to change the superuser checkbox into a datetime field. The next time the permission for superuser will be evaluated, the field will be checked set empty if the datetime has expired.

Apply the mixin like this:

class User(ExpiringSuperuserMixin, AbstractUser):
    ...

And don't forget to set AUTH_USER_MODEL = 'yourapp.User' in your settings.py

Special privilege for assigning superuser

At this point, any user that has the "Can change user" permission can also still elevate a user to superuser. To prevent this a can_assign_superuser permission is created that will be checked in UserAdmin.get_readonly_fields(). If the user does not have this permission it will just show the superuser field as read-only.

You probably also want to make the user's "Groups" and "User permission" fields also read-only this way so they cannot assign themselves to things they are not allowed to.

Go ahead and try the code:

€100 * 0.21 VAT = € 82.644628099

When you save this to the database it will round to 2 decimal places. If you then reapply the same VAT again you notice you've lost a cent:

€ 82.64 * 1.21 VAT = € 99.9944 = € 99.99

However, when your field allows for 4 decimal places to be stored in the database, you will have enough information to round exactly to what you started with:

€ 82.6446 * 1.21 VAT = € 99.999966 = € 100.00

The calculation above is done in Python this way:

Decimal('99.999966').quantize(Decimal('0.00'), rounding='ROUND_HALF_EVEN')

The first argument of quantize determines how many decimals you want to round to.

ROUND_HALF_EVEN is called Banker's rounding and is considered today's standard for rounding monetary values since it's the least biased form of rounding. Though it has to be said that there does not seem to be one uniform standard way for dealing with money, local legislation might be different.

Putting it in a custom DecimalField

This subclass of DecimalField will enforce all fields that process money to have the same 4-decimal accuracy in the database. Meanwhile, when the field is read-only, it will show 2 decimals for representation.

Note that it will still show 4 decimals when editing in a form, if you'd round this to 2 the same problem will start happening. So it's imperative to keep the decimals in the database as-is and only round them when in the end representing it to the user.

For our situation 4 decimals will always be enough, it could be that your calculations or use-case would require an even higher accuracy. This can be set with db_decimals.

Bonus: serializing currency with Django Rest Framework

When not editing, CurrencyField will show 2 decimals in the admin forms. However, when you use Django Rest Framework the serialized output in APIs will still show 4 decimals. This might not be what you want, therefore you can use this customized DRF field:

To show two decimals for a field in the API, use it like this:

class ArticleSerializer(serializers.ModelSerializer):
    sales_price = CurrencySerializerField(required=False)

Feel free to modify these examples to your needs.

However, you don't necessarily need to store this information in the database, as you can also copy the original data before changing the object. I've made a simple mixin that will copy the original from the database and stores it on the object itself:

class SomeModel(DiffMixin, models.Model):
    some_attribute = models.IntegerField()

instance = SomeModel()
instance.some_attribute = 1
instance.save()

instance.some_attribute = 2
instance.is_changed('some_attribute')

The mixin copies the original just before saving and deleting and keeps the latest around as long as the object lives as _original .

You can expand on the mixin by for example providing more advanced comparison over all fields. When serializing the current and the original to a dictionary, dictdiffer.diff() could be a tool to establish a diff between the two.

Feel free to use and tweak my DiffMixin to your own needs:

The problem had already been raised with some solutions already been provided, but these mainly focus on providing a filter to make them visible. The Gist below adds a new history page on the model's change list page. The benefit here is that you can override the BaseHistoryAdmin to add for example filters or search functionality, that you would not have normally.

For example, to combine Django Simple History with DjangoQL you can add advanced searching like this:

from django.contrib import admin
from djangoql.admin import DjangoQLSearchMixin


class SomeHistoryAdmin(DjangoQLSearchMixin, BaseHistoryAdmin):
    # Add your specific DjangoQL settings here
    ...

class SomeModelAdmin(WMSimpleHistoryAdmin):
    history_admin = SomeHistoryAdmin
    # The rest of your model settings
    ...

admin.site.register(SomeModel, SomeModelAdmin)

For adding additional filters to the history admin you could do something similar by specifying SomeHistoryAdmin.list_filter, by default it's already filtered on history_type so you can quickly identify which objects were added, changed or deleted.

This example shows how to use DjangoQL to query orders that were deleted. By adding templates/admin/change_list.html a button will be created on all model change list pages just before the regular Add button, it will refer to the history page. Beware that this also adds a button on admin pages that are not based on WMSimpleHistoryAdmin.

Go ahead and tweak the Gist to your own needs:

jwt_auth = JWTAuth(
    auth_url='https://endpoint.example/api/v1/auth',
    api_payload={
        'api_key': '<API_KEY>',
        'api_secret': '<API_SECRET>',
    }
)
# Using it directly
requests.get('some-url', auth=jwt_auth)

# Or when applied to a session for all requests:
session = requests.Session()
session.auth = jwt_auth

JWTAuth needs to know your auth_url and api_payload to be able to authenticate with the server on your first request. It will only work when you receive back an access and refresh token. Based on your situation and API response, you might need to change this a little to make it work.

ForeignKeys in the Django admin show as a select-box (<select>) by default. This will result in a query for every item in the select, only to get the name. This is not a problem if the model you're referencing will always be small. But growing models with significant rows will become a problem soon. Having 3 times the same select-box with 1000 items will result in 3000 queries. It will also make the select unusable.

Instead, you could use the ModelAdmin.raw_id_fields which turns it into an input widget with a search icon. It will only query the name of the selected item:

Prefetching in inlines

raw_id_fields can also be used in ModelAdmin inlines. However, when you have a lot of these inlines on a page, it's gonna hurt. Having 180 items will result in at least that amount of queries, and usually even double or more.

Less queries = faster load, so to cope with this you can use prefetch_related which I wrote about earlier. Apply the same get_queryset technique on the ModelAdmin, this cached prefetch data will also be available to your inlines.

This should reduce the number of queries to just a few for the entire page. But unfortunately there is a caveat...

The bug in ForeignKeyRawIdWidget

Unfortunately, there is currently a bug in the Django issue tracker that prevents the widget used byraw_id_fields in inlines from using the prefetched values.

TL;DR: in the Django code the relatedForeignKeyIdWidget has to do a QuerySet.get() to get the name of the item. By doing so, the already cached prefetch_related values are ignored. In the said bug issue I proposed a solution, but it proved to be changing too much Django code in other places as well to be accepted.

To work around this problem some code needs to be patched, a snippet with a mixin can be found lower on this page. The example below shows how to implement the patched RawIdWidgetAdminMixin in your code. Note that the mixin should precede ModelAdmin to work. Thanks to the mixin and prefetch_related your page will now consume way fewer queries!

class CustomAdmin(RawIdWidgetAdminMixin, ..., ModelAdmin):
    inlines = ('some-inline',)

    def get_queryset(self, request):
        return (
            super().get_queryset(request)
            .prefetch_related('your-inline-model')
        )

The patched ForeignKeyRawIdWidget can be found in this Github Gist I posted below. Perhaps the most important line is 56 where an object is returned (instead of a plain value). This ultimately prevents the get() as on line 30, we can get the attributes from the object instead of having to query them for each item.

The patch cannot be much smaller than this, as one change triggers another down the line. It can probably be smaller by monkey-patching the classes, but I prefer to keep it clean by subclassing.

Benchmark

A change-view page with 180 inline items with relations:

1. Using no raw_id_fields: 1658 queries

2. With raw_id_fields and prefetching in Django 3.1: 384 queries

3. Patched raw_id_fields and prefetching: 18 queries

This proves that if you have a many inline items on a page, the mixin can reduce the amount of queries. Using raw_id_fields already drastically improves queries compared to having select-boxes. The unpatched raw_id_fields still produces an unacceptable high number of queries, because prefetching is not working due to the bug. This number of queries can still cause serious query times, resulting in your page to be very slow.

Maybe in the future this bug will be fixed in Django, so this patch will not be necessary anymore.