We have an implementation of both annotations in
list_display and adding an aggregates for the entire list (which we call
list_summary and what you are calling here
list_aggregates) and there are a bunch of subtleties in the interaction due to Admin's built in support for pagination and filtering
To demonstrate, let's use a simplified use case
assume models such as Author -< Book >- Genre (Book has FKs to both Author and Genre)
class AuthorAdmin(admin.ModelAdmin):
list_display = ('author_name', 'book_count', 'book_sum_price')
list_filters = ('book__genre__name', )
list_summary = (('Total Books', Sum('book_count'), ),
('Total Book Price', Sum('book_sum_price'), ))
def get_queryset(self, request):
return super(BookAdmin, self).get_queryset(request).annotate(
books_count=Count('books__name'),
books_sum_price=Sum('books__price'))
With regards to list_summary (or list_aggregates in the PR) our implementation summarizes the entire QuerySet not just a single page (my quick read of the patch seems to indicate that list_aggregates only aggregates a single page of the qs). From my perspective summarizing a single page doesn't provide as much value summarizing the entire QS. If one agrees with that then feature will would have to support a user friendly name for the field (implemented here as a tuple - as suggested by Jim). Additionally, if the feature summarizes the entire qs then the output should likely go above the table rather than as summary below (if it were below and the results were paginated, it would likely confuse the users)
With regards to extending list_display to support annotations there are subtle interactions between admin, annotated query sets and filters.
The qs that Django executes when the user has a filter looks like
Author.objects.annotate(...).filter(...)
In the code shown above this will produce the correct result set, but because annotate and filter aren't commutative, the generated SQL ends up joining the Books table twice. Additionally, there are probably some cases where complex filters will give unexpected results.
Give that the user really wants
Author.objects.filter(...).annotate(...)
we ended up adding a modelAdmin.get_annotations(...) method and subclassing ChangeList to implement this feature.
One additional note is that annotations require implementing a method on the modelAdmin class for each annotations which seems very boilerplate-ish. We have extended list_display to automatically handle the boilerplate as well.
Since we use this extensively these features in our applications, we would be excited to see them implemented as part of admin. We'd be happy to contribute here and if this seems like its worth pursuing I'll ask our team to look into refactoring the work we've done so that it could live in core rather than as sub-classes.