WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 17 months ago

#12104 new defect (bug)

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

Reported by: sillybean Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Comments Keywords: has-patch needs-testing
Focuses: administration Cc:

Description

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.

Attachments (4)

moderate_comments.diff (1.8 KB) - added by sillybean 8 years ago.
this gets the user to the page, but they still can't actually approve a held comment
12104.patch (527 bytes) - added by linuxologos 6 years ago.
12104.diff (1.5 KB) - added by nacin 6 years ago.
12104.2.diff (2.4 KB) - added by Kau-Boy 22 months ago.

Download all attachments as: .zip

Change History (41)

@sillybean
8 years ago

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

#1 follow-up: @nacin
8 years ago

  • Component changed from General to Comments

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.

#2 in reply to: ↑ 1 ; follow-up: @sillybean
8 years ago

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?

#3 in reply to: ↑ 2 @nacin
8 years ago

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.

#4 follow-up: @sillybean
8 years ago

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.

#5 @sillybean
8 years ago

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.

#6 @nacin
8 years ago

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.

#7 @nacin
8 years ago

  • Milestone changed from Unassigned to 3.1

3.1 sounds like a good time for this.

#8 @pbearne
8 years ago

  • Cc pbearne added

#9 in reply to: ↑ 4 @shidouhikari
8 years ago

  • Cc shidouhikari added

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 :)

#10 @scribu
8 years ago

Related: #14520

#11 @nacin
8 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Triage to Future Release
  • Type changed from defect (bug) to enhancement

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.

#12 @azizur
7 years ago

  • Cc azizur added

#13 @scribu
7 years ago

Marked #19287 as dup.

#14 @linuxologos
7 years ago

  • Cc linuxologos@… added

@linuxologos
6 years ago

#15 @linuxologos
6 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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).

#16 @jordash56
6 years ago

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..

#17 @greenshady
6 years ago

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.

#18 @Mamaduka
6 years ago

  • Cc georgemamadashvili@… added

#19 @toscho
6 years ago

  • Cc info@… added

@nacin
6 years ago

#21 @nacin
6 years ago

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?

#22 @scribu
6 years ago

edit_posts OR manage_comments seems very reasonable.

#23 @nprasath002
6 years ago

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

#24 @nprasath002
6 years ago

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?

#25 @scribu
6 years ago

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.

#26 @scribu
6 years ago

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.

#27 @danielbachhuber
6 years ago

  • Cc danielbachhuber added

#28 @johnbillion
5 years ago

#19286 was marked as a duplicate.

#29 @johnbillion
5 years ago

#20050 was marked as a duplicate.

#30 @mariusvetrici
3 years ago

  • Focuses administration added
  • Summary changed from edit-comments.php not available to roles with proper capabilities to 'moderate_comments' capability by itself should grant the user the permission to See/Edit all comments from the Comments menu.
  • Type changed from enhancement to defect (bug)

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.

#31 @rachelbaker
3 years ago

  • Keywords needs-refresh added; needs-testing removed

This ticket was mentioned in Slack in #core-comments by rachelbaker. View the logs.


2 years ago

#33 @lukecavanagh
2 years ago

User role specific comments seems like a good idea.

#34 @Kau-Boy
22 months ago

  • Keywords needs-testing added; needs-refresh removed

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.

Last edited 22 months ago by Kau-Boy (previous) (diff)

@Kau-Boy
22 months ago

This ticket was mentioned in Slack in #core-restapi by websupporter. View the logs.


21 months ago

This ticket was mentioned in Slack in #core-restapi by rachelbaker. View the logs.


17 months ago

#37 @jlambe
17 months ago

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.

Note: See TracTickets for help on using tickets.