[wp-trac] [WordPress Trac] #7070: users with 'edit_published_posts' can't edit posts without unpublishing them.

[WordPress Trac]

#7070: users with 'edit_published_posts' can't edit posts without unpublishing
them.
--------------------------+-------------------------------------------------
 Reporter:  jeremyclarke  |       Owner:  jeremyclarke
     Type:  defect        |      Status:  new         
 Priority:  high          |   Milestone:  2.5.2       
Component:  General       |     Version:  2.5.1       
 Severity:  major         |    Keywords:  has-patch   
--------------------------+-------------------------------------------------
 Right now the save box display and post edit processing functions don't
 take into account the existence of the 'edit_published_posts' capability
 (since 2.5).

 Effectively both bits of code only check for the 'publish_posts'
 capability and deny publishing rights (hiding it from the pulldown menu
 and changing the status during processing to pending) if the user doesn't
 have it.

 The problem is that users with 'edit_published_posts' (the ability to edit
 your own posts once they have been published, seperate from
 'publish_posts' and 'edit_others_posts'), are only given the option of
 'pending' when they edit their posts. This is not only frustrating, but
 because the screen only shows the 'save' button, it means that loading
 your article, making a change, and saving (without looking at the status
 dropdown) results in unpublishing your article, which you are unlikely to
 even notice potentially forever.

 The solution is to not only check for


 {{{
 current_user_can('publish_posts')
 }}}


 but also for


 {{{
 current_user_can('edit_post', $post->ID)
 }}}


 which automatically checks whether a user is allowed to edit a post based
 on whether they are the author, it is published etc. That way users with
 the 'edit_published_posts' capability are able to use it in those
 situations where it's appropriate.

 The code is affected in two places:

 1) wp-admin/edit-form-advanced.php ~line 94 (which controls whether the
 'published' item displays in the status dropdown menu)


 {{{
 <?php if ( current_user_can('publish_posts') ) :?>
 }}}


 becomes


 {{{
 if ( current_user_can('publish_posts') OR ( $post->post_status ==
 'publish' AND current_user_can('edit_post', $post->ID)) ) :
 }}}



 2) wp-admin/includes/post.php ~line   64  (which controls whether the
 post_status in $_POST is shunted from publish down to 'pending')


 {{{
 if ( 'publish' == $_POST['post_status'] && !current_user_can(
 'publish_posts' ) )
 }}}


 becomes


 {{{
 if ('publish' == $_POST['post_status'] && !current_user_can(
 'publish_posts' ) && !current_user_can( 'edit_post', $_POST['ID'] ))
 }}}


 That way users can 1) choose the publish option when they edit their
 published posts (and it's selected by default) and 2) the posts aren't
 downgraded while being processed after saving (otherwise the post is
 silently unpublished!).

 In 2.6 the second part is in a function called _wp_translate_postdata(),
 whereas in <2.6 its in edit_post(). My personal impression is that if the
 permissions check is going to be moved out of edit_posts it should live in
 wp_insert_post(), which gets called at the same times as
 _wp_translate_postdata() but contains other similar processing (unlike
 _wp_translate_postdata() who's main purpose is validation and cleaning of
 the raw $_POST contents). Ryan Boren said that you want to keep capability
 conditions out of the api, not sure what that means, but figured I'd float
 another idea anyway. The changes will work in their current positions
 either way (the 2.6 patch is for the current location in
 _wp_translate_postdata()).

 I tried to fix the same thing for PAGES but in 2.6 the capability checks
 for pages didn't seem to be working at all (before i changed anything
 anyone could publish pages). i think fixing posts is more urgent either
 way, please let me konw if you want help fixing the pages as well (though
 the exact same changes but with 'edit_page' should work in wp-
 admin/includes/post.php a few lines above and in wp-admin/edit-page-
 form.php).

-- 
Ticket URL: <http://trac.wordpress.org/ticket/7070>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software