Opened 12 years ago
Closed 12 years ago
#19781 closed New feature (wontfix)
Documentation on Django Comments moderation emails doesn't match actual behavior
Reported by: | Mike Shultz | Owned by: | nobody |
---|---|---|---|
Component: | contrib.comments | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
django.contrib.comments.moderation(ln:239) currently uses settings.MANAGERS to decide who the recipients of the moderation e-mails are. This isn't mentioned in the documentation.
However, I'd like to request this to change to sending to all users with the Can moderate comments
permission. If this would be to resource intensive(querying users every comment post), then I'd like to suggest adding settings.MODERATORS
that would trump settings.MANAGERS
if it exists.
I don't have a good idea for the former, but the latter, a simple change to something like this would help:
recipient_list = [manager_tuple[1] for manager_tuple in getattr(settings, 'MODERATORS', None) or settings.MANAGERS]
Change History (2)
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
django.contrib.comments
has been deprecated and is no longer supported, so I'm closing this ticket. We're encouraging users to transition to a custom solution, or to a hosted solution like Disqus.
The code itself has moved to https://github.com/django/django-contrib-comments; if you want to keep using it, you could move this bug over there.
Thanks for the report! The title here says the behavior contradicts the documentation; I don't think that's true, the documentations says the email will be sent "to site staff", which is an accurate description of
settings.MANAGERS
, if not very specific.I think it's reasonable to be able to control who gets these emails at a level specific to
contrib.comments
, though I doubt that we'd want to query the database for this information.On a different not, I really think
contrib.comments
is a prime candidate for spinning out into a standalone project. There's nothing about it that requires being in contrib, and it's not all that well cared for there.