Make WordPress Core

Opened 13 years ago

Closed 10 years ago

#16705 closed defect (bug) (fixed)

Unclear wording: "An administrator must always approve the comment "

Reported by: joewoidpress's profile joe.woidpress Owned by: sergeybiryukov's profile 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)

16705-edit_comment_3.3.patch (543 bytes) - added by kevinB 13 years ago.
map_meta_cap(): for 'edit_comment', append 'moderate_comments' to 'edit_post' caps
16705.patch (956 bytes) - added by RyanMurphy 12 years ago.
patch based off Jane's wording
16705.2.diff (957 bytes) - added by MikeHansenMe 11 years ago.
refreshed, the file has changed since last revision.
16705.diff (937 bytes) - added by DrewAPicture 11 years ago.
'Comment must be manually approved

Download all attachments as: .zip

Change History (37)

#1 @scribu
13 years ago

  • Keywords ux-feedback added

I believe the intention is something like this:

"Someone who can edit the comment must always approve it before it is displayed"

#2 follow-up: @linuxologos
13 years ago

Related #6286 ?

#3 in reply to: ↑ 2 @joe.woidpress
13 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: @shacker
13 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 @joe.woidpress
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...

Last edited 13 years ago by joe.woidpress (previous) (diff)

#6 @shacker
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 @kevinB
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.

Last edited 13 years ago by kevinB (previous) (diff)

@kevinB
13 years ago

map_meta_cap(): for 'edit_comment', append 'moderate_comments' to 'edit_post' caps

#8 @kevinB
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 @scribu
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.

Version 0, edited 13 years ago by scribu (next)

#10 @scribu
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".

#11 @scribu
13 years ago

  • Milestone changed from Awaiting Review to 3.3

#12 @kevinB
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.

#13 @jane
12 years ago

"Comments will not be published until manually approved."

#14 @scribu
12 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

@RyanMurphy
12 years ago

patch based off Jane's wording

#15 @RyanMurphy
12 years ago

  • Keywords has-patch added

Attached patch changes the "An administrator must always approve the comment" to Jane's wording.

#16 @Ipstenu
12 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.

#17 @edwardw
12 years ago

  • Keywords tested dev-feedback added

Tested on r19236, works fine.

#18 @jane
12 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.

#19 @jane
12 years ago

  • Component changed from General to UI

@MikeHansenMe
11 years ago

refreshed, the file has changed since last revision.

#20 @MikeHansenMe
11 years ago

  • Cc mdhansen@… added

#21 @SergeyBiryukov
11 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.

#22 @SergeyBiryukov
11 years ago

  • Component changed from UI to Text Changes

#23 @wonderboymusic
11 years ago

  • Milestone changed from Future Release to 3.6

#24 @ericlewis
11 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.

@DrewAPicture
11 years ago

'Comment must be manually approved

#25 @DrewAPicture
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.

#26 @ryan
11 years ago

  • Milestone changed from 3.6 to Future Release

#27 @SergeyBiryukov
11 years ago

  • Milestone changed from Future Release to 3.7

#28 @SergeyBiryukov
11 years ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 25295:

Clarify a string in discussion settings. props Ipstenu, DrewAPicture. fixes #16705.

#29 @nacin
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for final UX review.

#30 follow-up: @ericlewis
10 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.

Last edited 10 years ago by ericlewis (previous) (diff)

#31 in reply to: ↑ 30 @SergeyBiryukov
10 years ago

Replying to ericlewis:

Although this discussion may be off-topic for this ticket, feel free to tell me to make a new one.

See #23233.

#32 @johnbillion
10 years ago

  • Keywords ux-feedback added; 3.4-early removed

UXers: any feedback?

#33 @helen
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

I definitely think we can/should continue in #23233, but the new string seems better to me when I look at the admin screen. Good for 3.7.

Note: See TracTickets for help on using tickets.