Update TokenAdmin to respect USERNAME_FIELD of the user model.

[m000]

Description

TokenAdmin assumed a fixed username field for the model specified by settings.AUTH_USER_MODEL. However, django allows using some other field as the username, and this is specified by overriding the USERNAME_FIELD property. See [1].

Also, switched default ordering to also use the username, and added filter for creation date.

[1] https://docs.djangoproject.com/en/5.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD

[p-r-a-v-i-n]

i think we should keep this ordering = ('-created',) ? what's your thoughts

[m000]

I think default ordering by username combined with a creation date filter makes more sense for several reasons:

• You usually know which user's token you are looking for. So when you search for part of the username, it's easier to scan the search results if they are ordered by username.
• When you have a date in mind, it is usually in the recent past (which is covered by the options of the created filter).
• Manually ordering by created is always possible if desired.
• created is not indexed while the username field typically should be. So, if anyone deals with a lot of tokens, loading the page should be slower.

But no hard opinion on this. We can stick with -created ordering if you find that better.

[p-r-a-v-i-n]

Also, created is not indexed while the username field typically should be

this make sense to me, and if this is the case then i don't have any problem.

[m000]

Ok. Marking as resolved.

Source reference for the fields:

# rest_framework/authtoken/models.py::Token
    created = models.DateTimeField(_("Created"), auto_now_add=True)

# django/contrib/auth/models.py::AbstractUser
    username = models.CharField(
        _("username"),
        max_length=150,
        unique=True,  # --> adds index
        help_text=_(
            "Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only."
        ),
        validators=[username_validator],
        error_messages={
            "unique": _("A user with that username already exists."),
        },
    )

[browniebroke]

Sorry I'm late to the party here, but one thing that comes to mind is how this will look in the UI. The ordering is by username but AFAIK the username isn't displayed on the page. If the email field is configured as username, the values could be quite different from the user display, making the ordering looks almost random.

Not sure if that's a big problem, though. And the point you raised about the lack of index is a good one.

[p-r-a-v-i-n]

If the email field is configured as username, the values could be quite different from the user display, making the ordering looks almost random.

Yes that sorting might create confusion in user mind. This will be surprise for the users.
if there is a performance problem then they can override the indexing and if require we can create seperate PR for adding index on created_at field if we have strong use case in future ( my opinion).

[m000]

@browniebroke The user is displayed. Here is a reference screenshot after the changes.

Apart from the indexing issue, I would prefer ordering by username because if you do a partial match search (e.g. adam in the screenshot), it is easier to scan through the result list if it is ordered by username.

OTOH, if tokens are long-lived, the creation date soon becomes irrelevant: Created at Sept. 2022 vs Oct. 2022 is pretty much the same thing in 2025.

But I think we have already spent more energy on this than its worth. Let me know of your final decision on ordering and I'll roll with it.

I can also follow-up with adding indexing to created_at, if you feel this is needed. Anecdotally, for the ~500 tokens in our app, the admin loading difference is not noticeable. But I don't know how many tokens other apps may have.

[browniebroke]

Ok I see, the default __str__ for the user uses username:

https://github.com/django/django/blob/bd7940982d6cab386dae7698ab097b91e5d8145e/django/contrib/auth/base_user.py#L58-L59

I can see some apps where it might be customised as first_name last_name but that's perhaps fine

[Copilot]

Pull request overview

This PR updates the TokenAdmin class to properly support custom user models with different username fields. Django allows projects to customize the username field via USERNAME_FIELD, and the admin interface previously hardcoded 'username' instead of respecting this setting.

Key changes:

• Updated search_fields and ordering to dynamically use User.USERNAME_FIELD instead of hardcoded 'username'
• Added list_filter for the 'created' field
• Changed default ordering from descending creation date to ascending username field

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The changes to use USERNAME_FIELD instead of hardcoded 'username' lack test coverage. Consider adding tests that verify the admin configuration works correctly with a custom user model that uses a different USERNAME_FIELD (e.g., 'email'), ensuring search and ordering function as expected.

[p-r-a-v-i-n]

@m000 it would be great to add test coverage for the changes.

[m000]

Added. It took a while to figure it out. Admin tests are a major PITA because modules include code that runs on load.

[p-r-a-v-i-n]

Thanks for adding test coverage.

Admin tests are a major PITA because modules include code that runs on load.

😄 I'm happy you did it. Nice work :) . well this part of test and code also new for me.

other than this everything looks good to me , I think the precommit hook is failing fix it and lets wait for Bruno and Auvi for feedback.

[m000]

Thanks for adding test coverage.

Admin tests are a major PITA because modules include code that runs on load.

😄 I'm happy you did it. Nice work :) . well this part of test and code also new for me.

other than this everything looks good to me , I think the precommit hook is failing fix it and lets wait for Bruno and Auvi for feedback.

Thanks for the hint. I had missed the existence of the pre-commit hooks.

I had chomped an extra line and isort complained. It should be good now.