Opened 13 years ago
Closed 9 years ago
#17981 closed defect (bug) (fixed)
XML-RPC wp.getComments should work for non-admins
Reported by: | koke | Owned by: | wonderboymusic |
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | 3.2 |
Component: | XML-RPC | Keywords: | has-patch needs-unit-tests |
Focuses: | Cc: |
Description
Right now, if the caller doesn't have the moderate_comments permission, the XML-RPC call returns a 401 error.
A more graceful alternative would be to return the approved comments. The user may not be able to moderate, but still should be able to read/reply
Attachments (7)
Change History (28)
#2
@
13 years ago
I should have done a trac search before writing a second patch but I feel it's better ;)
Dashboard also shows unapproved comments to authors, so we check for (edit_posts
OR moderate_comments
) instead of just moderate_comments
. The current checks for edit_comment
should take care of the rest.
Also, added better error descriptions.
#9
@
13 years ago
Added a new patch (sorry about the wrong one). Tested with an Author user:
- wp.getComments shows every comment (as dashboard does)
- Added a new field 'can_edit' to show if the user has permission to edit/delete that specific comment. That'll allow to customize the UI for it
- Can edit/delete comments in own posts
- Can't edit/delete comments in others posts
I think this also solves #19916. Some questions about it:
- Should wp.deleteComment error be "You are not allowed to delete..." instead of moderate?
- I was going to change the error in wp.getComments to match wp.getComment, but it's a different error code (401 and 403) and could break something
#11
@
13 years ago
Before we commit these changes I would like us to have some unit tests around the expected behaviour here.
Highest priority are tests for all the cap checks to ensure we have expected behaviour - writing the tests out makes you think a lot about this :)
Second priority are tests for the data returned especially datatypes so we can ensure continuing consistency over time.
I asked koke to see if he could write some of these in IRC today.
#14
follow-up:
↓ 15
@
11 years ago
Not sure why you remove the mobile keyword. It's used by the mobile team.
#15
in reply to:
↑ 14
;
follow-up:
↓ 16
@
11 years ago
- Keywords mobile added
Replying to markoheijnen:
Not sure why you remove the mobile keyword. It's used by the mobile team.
Since it's not a 'supported' keyword in the drop down, non-privledged users can't set it, so I expect it's probably getting removed without the users intention.
#16
in reply to:
↑ 15
;
follow-up:
↓ 17
@
11 years ago
I'm fine with this patch — anything to make it more like how edit-comments.php actually works.
Replying to dd32:
Since it's not a 'supported' keyword in the drop down, non-privledged users can't set it, so I expect it's probably getting removed without the users intention.
Anyone can click "manual" and set additional keywords, but since it isn't listed, gardeners might not realize it is a pseudo-official keyword and remove it. I'll look into getting it listed.
#17
in reply to:
↑ 16
@
11 years ago
Replying to nacin:
Anyone can click "manual" and set additional keywords, but since it isn't listed, gardeners might not realize it is a pseudo-official keyword and remove it. I'll look into getting it listed.
That's my fault. Assumed that mobile was an old tag. :)
#18
@
11 years ago
Anyone can click "manual" and set additional keywords, but since it isn't listed, gardeners might not realize it is a pseudo-official keyword and remove it. I'll look into getting it listed.
oops, I thought the Manual was limited to gardeners. Ignore me :)
Added patch for wp.getComments and wp.getComment. If user can't moderate comments, in only returns approved comments for wp.getComments, and returns an error if comment isn't approved for wp.getComment