[wp-trac] [WordPress Trac] #39701: Do not allow editing users from a different site in REST API

[WordPress Trac]

#39701: Do not allow editing users from a different site in REST API
--------------------------------------+------------------------
 Reporter:  flixos90                  |       Owner:  flixos90
     Type:  defect (bug)              |      Status:  accepted
 Priority:  normal                    |   Milestone:  4.7.3
Component:  REST API                  |     Version:  4.7
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  multisite
--------------------------------------+------------------------
Changes (by ocean90):

 * keywords:  has-patch has-unit-tests commit => has-patch has-unit-tests


Comment:

 This type of change reminds me of
 [https://wordpress.slack.com/archives/core/p1479937964003961 a question I
 had asked before the merge].

 > I've one concern/question about the REST API. Is there already a
 document how we deal with future API changes? Does a change mean we've to
 bump it to v2.1 or v3? Do we need a special deprecation policy?

 I don't think this question was ever answered which is kind of a bummer.
 Please point me to a public document if I'm wrong.

 This and [40078] are breaking our back-compat rule. While we did type
 changes in the past we always documented the changes with a changelog
 entry in a `@since` annotation. The patch and [40078] don't include
 anything like that.
 I'm worried about the fact that changes like these are harming the
 reliability of the API. It's no longer a plugin, it's part of core. It's
 not beta, it's a stable version (at least that's my assumption, otherwise
 the API wouldn't be in core).

 At the very least, can we create a page which mentions all the API changes
 at https://developer.wordpress.org/rest-api/changelog (or something
 similar)? Keep in mind that the API allows other services to interact with
 WordPress whose maintainer don't necessarily read our make blogs.

 The REST API already supports `rest_handle_deprecated_function()` and
 `rest_handle_deprecated_argument()` can we use that here or introduce a
 new header which contains a deprecation notice?

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