Question

Our app sets the is_active field in User Model to False to represent a deleted user.
What’s the best practice for excluding the deleted users (where is_active=False) from each and every access to the user table?
Please consider the following:
1. The app is already written, so we’d appreciate as minimum code changes as possible.
2. The app uses: request.user, get_object_or_404() and of course User.objects, so the solution has to take all of them into account.

From the research I’ve done, I found:
1. Proxy model: will force me to make a lot of changes in the code; I don’t know how it works with request and get_object_or_404().
2. contribute_to_class: Can it be used to override objects manager or to just to add a new one? Is it safe?
3. Middleware changes: I don’t want to get into this. Too risky for me.

Is there an elegant way for doing this?

Answer 1

There’s no way to do this, nor should you try. The only way to limit every action to a selection of model instances is to limit the default queryset, which then effectively orphans the excluded instances, providing no way to access them ever again. The Django docs explicitly warn against this behavior.

If you override the get_query_set() method and filter out any rows, Django will return incorrect results. Don’t do that. A manager that filters results in get_query_set() is not appropriate for use as an automatic manager. (emphasis mine)

“Automatic” managers are basically the same as the default manager. It’s what’s used for related fields, in the Django admin, and in countless other areas of the Django machinery. If you limit the default manager, you limit everything across the board.

Now, there’s other options for quickly accessing the limited queryset; they simply aren’t “automatic”, meaning you still must make a point of using them instead of just having everything happen by magic. However, “magic” violates one of the core Python tenants in this respect: explicit is better than implicit. Limiting the User queryset by default is an implicit action. Filtering the queryset manually, referencing a custom manager method, or using a subclass of User are all explicit actions, and preferable as a result.