Ah good catch.

Done! Curious, what is the code pattern here? Noticed that there are some signals with 2 lines in between and some with 1 in this file?

To give an example here, today you can do:

from django.db.models.signals import post_delete
from reviewboard.reviews.models import ReviewRequest


post_delete.connect(my_callback, sender=ReviewRequest)

Thanks for the feedback Christian, we felt that it would be helpful to extend the current set of common signals (we have a fair number of admins due to org size) to abstract the need to identify the appropriate models but feel free to close this one out if you believe that should be the recommended practice!

In this particular case, I think the built-in one is sufficient. Deletion is already an uncommon operation only allowed by superusers (and generally shouldn't be used in place of discard for most things, hence superuser only), and since we have a signal today, I don't want to risk confusion as to which signal should be used.
There are cases that Django's signal will handle that ours cannot not. post_delete will be called when doing something like:

ReviewRequest.objects.filter(submitter__username='somespammer').delete()


Those will make their way to post_delete, but not ours. Which is maybe okay, but it means the built-in one is going to be more accurate anyway.