'moderate_comments' capability by itself should grant the user the permission to See/Edit all comments from the Comments menu.

[sillybean]

I tried to create a Comment Moderator role today and realized it wouldn't work. My intention was to create a role for people who can't write or edit posts, but can keep an eye on the comment threads. I created the role like so:

add_role('moderator', 'Moderator', array(
            'read' => 1,
            'moderate_comments' => 1,
        ));

... then created a new user with that role. When I logged in as my test user, I realized that it was for all intents and purposes a Subscriber. I couldn't see any admin panels but the Dashboard, my profile, and the Tools. I went poking around in edit-comments.php and discovered that it's checking for another capability altogether:

if ( !current_user_can('edit_posts') )
        wp_die(__('Cheatin’ uh?'));

I double-checked wp-admin/includes/menu.php and it agreed that 'edit_posts' was the minimum capability to see this page, so I tried adding 'edit_posts' to my new role, and I still couldn't get there.

Later on in edit-comments.php, when actually trashing a comment, there is a check for 'moderate_comments', but it's a moot point: this screen doesn't even show up in the admin menu, and if you navigate directly to it, you'll get the "You do not have sufficient permissions to access this page" message.

I thought it was entirely possible I'd missed some finer point of creating roles, so I redid it with Justin Tadlock's excellent Members plugin, and that didn't work either.

This behavior might be intentional, but if so, I'm not following the logic. I know roles are due for an overhaul in the next version or two.

[sillybean]

this gets the user to the page, but they still can't actually approve a held comment

[nacin]

Currently, you need to be able to edit the specific post for which you're moderating a comment. Thus, the whole moderation panel is restricted by edit_posts. (You can possibly hack this for edit-comments.php and comment.php using the filter in map_meta_cap.)

This has come up before, both in general (the hijacking of caps), and moderation in particular. In general, there has been an expansion of capabilities already on 3.0. Specifically, this was discussed on #wordpress-dev after the dev chat on ​January 7. There hasn't been a ticket yet, so I guess this is it.

[sillybean]

Replying to nacin:

Currently, you need to be able to edit the specific post for which you're moderating a comment.

Well, that explains it. But... why?

[nacin]

Replying to sillybean:

Replying to nacin:

Currently, you need to be able to edit the specific post for which you're moderating a comment.

Well, that explains it. But... why?

Because, when it was coded, that's the route they took. Unbundling that will take a lot of work modifying a lot of checks across numerous files. It is something that has been indicated as desirable, so once a patch is created it'll probably make it into core pretty quickly.

On the other hand, the core upgrader currently requires the upgrade_plugins cap. Changing that to something like upgrade_core is four lines (change the cap, populate it, map it for Multisite is_super_admin, update the db version). Just hasn't been done it yet.

It seems the core developers are ready to move forward with an expansion of capabilities. We just need to identify what needs to get changed and change it.

[sillybean]

In this particular instance, I think it would make sense to redo the comment moderation capabilities to look more like posts and pages: one for moderating comments on one's own stuff, and one for moderating all comments.

[sillybean]

I'd take another crack at a patch, but map_meta_cap is a bit over my head at the moment.

There are a number of tickets on the larger role/cap issue, like #2531 and #10201.

[nacin]

I'm thinking about improvements to this while being backwards compatible. If we used moderate_comments as the entrance, then further restricted it by a new meta cap, moderate_comment. moderate_comment is more or less a copy of the edit_post meta cap, which means edit_posts, edit_others_posts, etc. They would be based on their counterparts.

For the moderation role, we'd need to figure out a way to flip moderate_comment to on for all. That could easily be done via a filter on map_meta_cap, or perhaps some other wider cap. Point is, the separation is a start and would allow plugins to control this consistently.

I'm probably missing something. Just figured I'd muse and progress the ticket along ever so slightly. On the other hand, if this seems like a good idea to anyone, I can put it on my to-do list.

[nacin]

3.1 sounds like a good time for this.

[shidouhikari]

Replying to sillybean:

In this particular instance, I think it would make sense to redo the comment moderation capabilities to look more like posts and pages: one for moderating comments on one's own stuff, and one for moderating all comments.

Agreed. Requiring capability to edit a post to be able to edit that post's comments means comments are an extention of their post. That's correct for sites that have few comments and ppl who edit posts also edit comments.

But for a site where comments take post's visibility and look more as a forum, having comment moderators who deal with commentators interaction and don't have access to posts is a logical approach.

As a use case, I've seen some "communities" (in Brasil at least) where they aren't organized and skilled enough to build their forum, so they google for their concerning subjects and start commenting on posts of any site they find that had published a post about that subject.

Some small sites' posts get high ranked on Google because the amount of comments and content about that subject, and comments get much bigger than original post, with many comments with more content and relevance than the post, and it really becomes a discussion forum. Some site owners even get scared with it and they also go to a trolling line of debate, and when comments get closed for that post they restart searching for another site where their discussion/trolling is accepted.

If mini-forum sites would be created using this behavior, with posts offering subjects for visitors debate and it gets popular, site's owner would end up wanting to promote commentators to manage comments. But they wouldn't wanna give moderators access to edit the post, because mods could use post's special highlight to add content owner would want to remain democratically in comments.

Subscribed users also could edit their past comments, and a plugin could be made to resctrict old comments from being edited.

Wordpress should support this comment moderation feature :)

[scribu]

Related: #14520

[nacin]

With edit_comment, we're closer to doing this. Needs patch. If someone wants to ping me at the start of 3.2 I'll take a look again.

[scribu]

Marked #19287 as dup.

[linuxologos]

12104.patch​ should allow a user/role with moderate_comments + edit_posts capabilities to access the Comments screen and moderate all comments. I think this is the most minimalistic and backwards compatible approach.

The only discussion this could raise, which I can think of, is whether such a user/role should have his comments checked upon submission or not (see: ​http://core.trac.wordpress.org/browser/tags/3.3/wp-includes/comment.php#L641).

[jordash56]

I added the patch that linuxologos suggested and it worked great.

My suggestion would be to have multiple roles, something like "Super Moderater -> Can moderate all comments" "Moderator->Can moderate his own comments" etc..

[greenshady]

I just ran into this issue too for a site I was building. I tried to build a small plugin that disallowed post authors to edit comments and have a single role for comment moderation. I've also gotten several questions about this from users that are using my role management plugin.

I'll be more than happy to help out with this.

[nprasath002]

Related #20050

[nacin]

Now that we have the edit_comment meta cap that can be easily tweaked by a plugin to suit ones workflow, the only thing we're really missing here is dual checks for edit-comments.php — allow the page to be accessible with either edit_posts OR manage_comments. 12104.diff​ is entirely untested. What does everyone think?

[scribu]

edit_posts OR manage_comments seems very reasonable.

[nprasath002]

edit_posts will list all the custom post type comments even if the user has no capabilities.

[nprasath002]

Ideally we should get all the custom post types and check whether the user has the capability with that post type or we can run a loop for every comment and check edit_comment capability
I am not sure how to solve this?

[scribu]

But that's no different from what we have now: users with 'edit_posts' cap see all comments, wether they can edit them or not.

With the patch, however, they can at least edit the comments that they're allowed to edit.

[scribu]

What I mean to say is that the current patch is a step in the right direction and should be commited if nothing better comes along.

[johnbillion]

#19286 was marked as a duplicate.

[johnbillion]

#20050 was marked as a duplicate.

[mariusvetrici]

Hello,

I came across a use case that seems related to the ticket:

• I have a custom post type called Tasks
• I have a user role called TaskAssistant that needs to only manage Tasks and comments made on Tasks

Currently there's no possibility to give the TaskAssistant the possibility to:

• Edit Comments (from Comments menu in WPAdmin)

without being able to

• Edit Posts (from Posts menu)

This is because it is not enough to grant the TaskAsssistant with:

• moderate_comments
• edit_comment

I need to grant him the edit_posts capability as well.

But when I grant edit_posts he also receives access to the Posts (including the Posts menu in WPAdmin).

The expected behavior:
In my opinion the TaskAssistant role should be able to edit All Comments by only having 'moderate_comments' capability and without the need for edit_post.

Or to put it the other way around,
the 'moderate_comments' capability by itself should grant the user the permission to See/Edit all comments from the Comments menu.

[lukecavanagh]

User role specific comments seems like a good idea.

[Kau-Boy]

Every time I have an issue, there is already a ticket about. And it's usually more than 5 years old :)

OK, so a refesh is desired. I think I have come up with something that should work. I was in a similar situation as @mariusvetrici and have written a patch against 4.6 which works for me.

As we have two capabilities for comments "edit_comments" and "moderate_comments", both should be taken into account. The menu lacks of the item as an optimization removed it, if a user has not the "edit_posts" capability, to not run the counting. I think "moderate_comments" works better here. So I used all three capabilities, the two comments caps and the old "edit_posts", so it doesn't break any old code/workaround.

[jlambe]

We're really looking at this ticket and hope it will be merged somehow in core.

Another case for comments specific capabilities is that we just want a granular control of what a WP_User can access inside the WordPress admin. We do have projects where people just want to post articles but don't want to activate the comments. From their feedback, it's cumbersome for them to still see or be able to access a "Comments" page from the Admin because we can't remove the "edit_posts" capability from their role but removing the "moderate_comments" cap do not help as it doesn't control the page and menu display for the comments.

[hellofromTonya]

The latest needs a refresh against trunk.

[smub]

We have run into this similar issue specially as WPBeginner has grown. So we created a plugin solution here for anyone who's looking for something that just works until core has a way to do it natively:

​https://wordpress.org/plugins/comment-moderation-role/

[johnjamesjacoby]

Hey everyone 👋 I slid into the hole of refreshing this patch and ran into a 🐇 of a problem.

Once a refreshed patch is applied, the "Comments" admin menu and page are revealed and accessible, but none of the bulk actions work, and no row actions are visible to click on.

This results in what is basically a dead-end for the user with only the moderate_comments capability applied to them.

This is because nearly all of the code used to interact with individual comments uses the edit_comment capability, which maps to edit_post or edit_posts depending on if a parent Post is found or not, which @nacin talked about above just 12 short years ago. ⏳

---

To move forward on this, WordPress needs to decide how much power the moderate_comments capability is intended to grant. For example, here is the array of possible core action IDs:

$actions = array(
	'approve'   => '',
	'unapprove' => '',
	'reply'     => '',
	'quickedit' => '',
	'edit'      => '',
	'spam'      => '',
	'unspam'    => '',
	'trash'     => '',
	'untrash'   => '',
	'delete'    => '',
);

In my opinion, a hypothetical "Comment Moderator" role should be able to do all of those things to every comment. (This would match the intent of the "Moderator" role in bbPress, which is essentially an "Editor" for forum content.)

But I think it is possible that another common use case matches what @smub linked to above, limiting some comment actions to post authors, etc...

The next steps for an updated patch here will require some creativity and decision making.