Opened 14 years ago
Closed 11 years ago
#16705 closed defect (bug) (fixed)
Unclear wording: "An administrator must always approve the comment "
Reported by: | joe.woidpress | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 3.7 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | Text Changes | Keywords: | has-patch commit ux-feedback |
Focuses: | Cc: |
Description
I'm not certain if I should classify this as a bug or as a need to revise wording in the options menu, or if I should put in a feature request for a refined option...
...but...
If, under Settings->Discussion you have "An administrator must always approve the comment" checked, if the author of the post receiving the comment has the "edit_comment" capability, they will receive an email notification to moderate the comment in the queue.
After viewing the wp_notify_moderator function for 3.1 in pluggable.php (and comparing it to 3.0.5's version) I can see this functionality seems to be coded in by design.
What's confusing is that the option reads "An administrator must always approve the comment" and it's difficult to discern if that means the user role of "Administrator" or anyone who can be an "administrator" of the comments.
It's also hard to tell from the reading of the option text whether or not this means that the function is implemented incorrectly, or if the option is simply poorly worded.
In either case, it would be useful to be able to have more granular control over who is getting these email notifications for comment moderation.
Failing that, if the "An administrator must always approve the comment" is checked, that should mean that only users with the "Administrator" role should be able to approve the comment.
...depending on what the expected behavior of this functionality is meant to be.
Attachments (4)
Change History (37)
#3
in reply to:
↑ 2
@
14 years ago
Replying to linuxologos:
Related #6286 ?
It's certainly related, although I think there's an extra aspect in my ticket relating to who the "administrator" is who needs to approve the comment.
My ticket addresses the "An administrator must always approve the comment" option while the other ticket addresses the email notification options.
#4
follow-up:
↓ 5
@
14 years ago
In the meantime, authors on multi-author sites who have never seen moderation emails before are being hammered with them (and confused by them), and admins are put in an uncomfortable situation trying to tell authors to ignore them. Until this is fixed, is there anything we can do to disable moderation emails to authors?
#5
in reply to:
↑ 4
@
13 years ago
Replying to shacker:
In the meantime, authors on multi-author sites who have never seen moderation emails before are being hammered with them (and confused by them), and admins are put in an uncomfortable situation trying to tell authors to ignore them. Until this is fixed, is there anything we can do to disable moderation emails to authors?
I think the best you could do at this point is to hack wp-includes/pluggable.php and modify line 1121. My guess is if you changed the 'edit_comment' capability so something that only your desired access level can do (check http://codex.wordpress.org/Roles_and_Capabilities for something that might work), that would at least patch things for the time being if this is a huge issue for you. (This whole issue seems to stem from the new 'edit_comment' capability added in WordPress 3.)
...best I could come up with for you.
Hopefully there will be more granularity for selecting who gets emailed in the future...
#6
@
13 years ago
Thanks Joe. I commented out lines 1121-1122, and unfortunately post authors still receive moderation emails. This is puzzling, as it's the only place in that function I can see where the post author's email is obtained. That fix really should work. Any other ideas? Thanks.
#7
@
13 years ago
- Cc kevin@… added
The problem I see is that
user_can($user->ID, 'edit_comment', $comment_id)
is effectively converted to:
user_can($user->ID, 'edit_post', $comment->comment_post_ID)
...but no moderate_comments requirement is ever imposed.
#8
@
13 years ago
- Summary changed from Authors with "edit_comment" capability receive comment moderation emails for their posts when "An administrator must always approve the comment " is checked to Post Authors lacking moderate_comments capability still receive comment moderation emails
To clarify the original ticket description, 'edit_comment' is a meta capability which should not be assigned as part of a role definition. The real issue is non-requirement of the moderate_comments capability.
#9
@
13 years ago
- Summary changed from Post Authors lacking moderate_comments capability still receive comment moderation emails to Unclear wording: "An administrator must always approve the comment "
The patch is no good. It would mean that authors couldn't edit their own comments, since only editors and admins have the 'moderate_comments' capability.
So, again, the problem isn't the capabilities, but the wording of the option.
#10
@
13 years ago
For the discussion on wether it's a good idea for authors to be able to edit any comment on their own posts, please open a new ticket.
Anyway, I believe the option should read "The comment should not be published until it's approved".
#12
@
13 years ago
Replying to scribu:
The patch is no good. It would mean that authors couldn't edit comments on their own posts, since only editors and admins have the 'moderate_comments' capability.
Actually, the patch is just incomplete.
Without needing to discuss whether it's a good idea, let's just be clear that Authors are currently granted an implicit and unrevokable 'moderate_comments' capability.
A more consistent approach would be to explicitly add 'moderate_comments' to both the Author role and the 'edit_comment' cap map. Then let the the site admin decide if it's a good idea, by removing 'moderate_comments' from the role if desired.
Anyway, that would require a more ambitious patch and more deliberation so I'm not going to pursue it any further here. Will work around the issue via plugin code as needed but I thought the observation/idea might benefit others too. Just take it or leave it.
#14
@
13 years ago
That doesn't really work. There's some text before that setting, which looks like this:
Before a comment appears:
- An administrator must always approve the comment
- Comment author must have a previously approved comment
#15
@
13 years ago
- Keywords has-patch added
Attached patch changes the "An administrator must always approve the comment" to Jane's wording.
#16
@
13 years ago
"All comments must be manually approved."
That would fit better with the 'Before a comment appears' header. Or even "Comment must be manually approved", full stop.
#18
@
13 years ago
- Keywords 3.4-early added
- Milestone changed from 3.3 to Future Release
It's too late in the cycle to put this in...didn't get put in early enough to get adequate user testing/feedback. Since we're almost at RC, don't want to mess with it now. Sorry it languished, we can look at it again in 3.4 early.
#21
@
12 years ago
Generally, a refresh is only needed when the patch no longer applies cleanly.
Line numbers may be off, but as long as the content is the same, the patch should still apply cleanly.
#24
@
12 years ago
I agree with scribu - the two comment options in this section sound contradictory. The two have an OR relationship, but that's not visually expressed.
Although the copy change suggested here is an improvement, that's still an issue.
#25
@
11 years ago
- Keywords commit added; ux-feedback tested dev-feedback removed
16705.diff changes the label to 'Comment must be manually approved'
This is consistent with the singular use of 'comment' in other labels on this screen. Also the section label 'Before a comment appears' makes the use of 'will not be published' suggested in comment:13 and 16705.2.diff redundant.
#28
@
11 years ago
- Owner set to SergeyBiryukov
- Resolution set to fixed
- Status changed from new to closed
In 25295:
#29
@
11 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening for final UX review.
#30
follow-up:
↓ 31
@
11 years ago
The presentation is still problematic here.
For example:
[x] Comment must be manually approved
[x] Comment author must have a previously approved comment
The latter setting is ignored, as all comments must always be manually approved. In the case of they are both set, the latter setting has no relevance. Only one should be able to be selected at a time, an interlocking mechanism should be employed, and perhaps visually displayed.
Although this discussion may be off-topic for this ticket, feel free to tell me to make a new one.
I believe the intention is something like this:
"Someone who can edit the comment must always approve it before it is displayed"