[wp-trac] [WordPress Trac] #42658: Customize: Heartbeat doesn't refresh changeset lock when branching is enabled

[WordPress Trac]

#42658: Customize: Heartbeat doesn't refresh changeset lock when branching is
enabled
--------------------------+------------------------
 Reporter:  dlh           |       Owner:  dlh
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  4.9.3
Component:  Customize     |     Version:  4.9
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------
Changes (by westonruter):

 * keywords:  has-patch => needs-patch
 * owner:  westonruter => dlh


Comment:

 @dlh one thing that I think needs to be improved with
 [attachment:42658.diff]: it's checking if `current_user_can( 'customize'
 )` but it's not checking whether the current user can actually edit the
 specific `$changeset_post_id`. In other words, I think it needs to include
 a condition like: `current_user_can( get_post_type_object(
 'customize_changeset' )->cap->edit_post, $changeset_post_id )`.

 It's too bad that merely `data.changeset_uuid =
 api.settings.changeset.uuid` doesn't cause the Customizer to initialize
 with the UUID supplied there. The reason is that `_wp_customize_include()`
 is looking for a `customize_changeset_uuid` or `changeset_uuid` input var,
 but Heartbeat sends it as `data[changeset_uuid]`. The only way to get
 around that would be to opt to inject the `customize_changeset_uuid` param
 by some other means, such as by `jQuery.ajaxPrefilter`, which we are
 currently doing to add the `customize_preview_nonce`:
 https://github.com/WordPress/wordpress-develop/blob/026cd70/src/wp-
 admin/js/customize-controls.js#L7784-L7792

 I don't know if that's better than just improving the cap checking for
 locking as it exists in core today.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42658#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform